Introduction

1. The Birth of an Idea
   

   For my final semester at Villanova, I have decided to create an online real-time automobile auction for my independent study.  This idea is unique in that even though there are many auction sites on the world wide web for automobiles, I failed to find any that offered real time interaction.  My supervisor on this assignment is Dr. John Lewis.  He is highly respected in the Villanova community as well as among the Computing Sciences field and I am sure he will offer excellent guidance as I pursue this topic.
   

2. Why an Auto Auction?
   

   1. My background - I have been fortunate enough to have been involved with the used car industry for many years.  My family operated a used car dealership in Northeast Pennsylvania for over thirty years.  During the times when I worked at the dealership, I was not only involved in dealer preparation, but used car sales and purchasing.  Our inventory was purchased exclusively from various auto auctions in the Pennsylvania and New Jersey areas, specifically from Manhiem Auto Auction in Manhiem, PA.  This knowledge coupled with my computer science experience has led me to believe that incorporating auction technology at the used automobile level is reasonable and appropriate considering the current state of technology.
      
      

   2. Improve Customer Base - I hesitate to suggest that this auction site would "increase" the customer base of an auto auction such as Manhiem because there is already a tremendous amount of diversity within the auction buyers.  Although, obviously a great number of the Manheim's customers are local to the auction itself (most averaging around 60-70 miles away), there are a vast number of dealers that fly in from all over the United States to attend the auction, which occurs every Friday and every other Thursday.  By improving the auction's customer base, I  suggest that dealers that already attend Manhiem on a regular basis would now have the option whether or not to attend the actual sale.  They would be able to purchase autos for their inventory from the comfort of their homes or dealerships.  Sellers would also benefit from more potential bidders on his or her car, which would potentially increase selling prices.  On a more grand scale, one might believe that through this process, you would actually be determining more accurate market values of the automobiles being sold (This is the same concept of an open stock exchange determining market values for shares of companies).
      
      

   3. Industry Growth Management - The wholesale auto auction industry has seen massive growth over the last ten years.  Manhiem alone has seen an annual increase of around 20 percent in units registered for the Friday auction (this doesn't even take into account the additional two auctions per month from the Thursday sales).  Obviously, these automobiles must be on the premises for the auction, which had led to a storage lot that spans for acres and has become almost unmanageable for pre-sale inspections.  Since pre-sale inspections are all but a thing of the past, an online auction seems even more feasible, especially as many wholesalers guarantee their pre-sale claims of an auto's fitness.  At Manhiem, there are approximately 26 auction blocks going on at any given time, thus it has become difficult to track numerous vehicles during a typical day as well as the auction blocks themselves becoming entirely to congested with buyers.  An online auto auction would thus not only benefit those dealers that would rather not deal with this expansive process, but also those dealers who would rather not take part in such online transactions by removing some of the congestion from the auction block.
      
      
      

3. Why Webcasting?
   

   1. Maintain Original Feel - By allowing dealers to view the automobiles they intend to bid on in a live format, you will maintain much of the original feel of the auction.  This provides the buyers with views a specific details of a vehicle such as scratches, body damage, and special features.  This is essential to determining the value of an auto because simply stating that a car need body work does not provide enough information to determine repair costs.  They need to see the other dealers that may be bidding on a particular car, either those at the auction block or those dealers also online.  Bear in mind that this is an open process, so even if it goes online, it must maintain at least some semblance of that openness.  Dealers also would like to know what auctioneer happens to be operating a particular lane.  Some auctioneers run the vehicles faster than others through the lanes and some auctioneers are notorious for "pushing" a car.  "Pushing" is a technique where an auctioneer will take bids that do not exist.  Suppose a seller wishes to get $20 thousand for the vehicle they are selling and the current bidding is only at $15 thousand.  Well, the job of the auctioneer is to get the car sold for as much as possible and under these circumstances, this would be a no sale.  "Pushing" essentially gives the seller a better shot of selling to a buyer that may consider paying much more for a car anyway (assume there was only one bidder).  As you could imagine, buyers want to be aware of this "pushing" because it is often a disadvantage.  Webcasting is the only possible scenario where an online bidder can be exposed to these scenarios. 
      
      
      

   2. Dealers Fear Change - The auction industry, especially with high priced items, hasn't really changed much.  I feel it represents capitalism at its purest form.  That is, it functions much upon the principals of survival of the fittest, which the dealers involved understand.  The majority of the buyers are spending their own money (even owners of larger dealerships enjoy doing their own buying).  Thus, many dealers may not feel entirely in control  with an online auction.  Again, webcasting is the only potential selling point to convince these "old school" dealers.
      
      
      

   3. High Priced Transactions - As one knows, in most situations, the purchase of an automobile is an expensive proposition.  It is quite understandable that buyers would be concerned about spending thousands of dollars over the internet.  In most cases, the only way they might consider such a transactions is if they are from extremely reliable vendors (such as Mercedes-Benz discussed below), guaranteed secure, and maintain the same amount of information needed to make the initial purchase.  As for reliable vendors, this is why I have chosen Mercedes-Benz as our seller.  In addition, the concepts of security will be discussed in much detail throughout this report.
      
      

4. Determining My Audience
   

As I have stated, my background in the used automobile industry and my understanding of used car auctions should hopefully benefit my research on this topic.  When considering an auction of this type, I must first describe my primary audience.  After analyzing popular automobile auctions I decided to choose Dealer Only Wholesale auctions.  They represent the largest percentage of automobile auctions in the United States.  In addition, the largest auction group happens to be Manheim Auto Auctions,  which originated in Manheim, PA.  At a typical dealer only auction, there are basically four major types of sellers:  independent dealers, franchise dealers, wholesalers, and credit/leasing companies. 

 

I have decided to focus this study on the Credit/Leasing companies, specifically manufacturer sponsored auctions (i.e. Mercedes Benz Credit Corporation, Volkswagen Credit VCI, Jaguar of North America).  This was done for numerous reasons.  First of all, they tend to have an organized process of reconditioning their cars, as well as knowing, in advance, exactly which group of cars will be auctioned in a given day.  They also maintain fairly accurate description of specifics on each car, such as previous bodywork, inaccurate odometer readings, and any dealer service history on each car.  Finally, they have detailed policies on purchases regarding arbitration procedures (Note:  These arbitration procedures come into effect when there is a dispute in the description of the auto as compared to the actual car.)  More specifically, my project will focus on the policies of the Mercedes Benz Credit Corporation, who I feel, due to their professionalism in the auction business, will benefit most from the technology model I intend to create. 

By default, since my choice of dealer-only auctions, my end-user audience will be any dealer who is authorized to buy automobiles from Mercedes-Benz Credit Corporation.

5. Initial Issues

As I see it, there are seven major issues regarding the implementation of this technology.  They are primarily:

1. Web Camera Issues
   

   There are a few different variations of how web cameras can be used to enhance this technology.  There are choices on how the camera's will be controlled.  Will the buyer (end-user) have control with camera movement or will there be numerous stationary cameras that will show various angles?  I have decided that I will go with various stationary cameras due to the fact that since only one user could control the movement at any given time, there is little use for a mobile camera when there are numerous bidders.  In addition, there is a cost associated with these cameras and since not only would you require many, but they can become quite expensive as the quality increases.
   
   

2. Real-Time Auction Concerns
   

   Regarding the use of real time auctions, there are many issues that arise.  First of all, as a server is flooded with requests, it may be difficult to maintain actual real time.  The servers will need to be able to handle these requests and the buyers will need adequate bandwidth to accomplish their tasks.  The most cost effective method of having buyers with adequate equipment would be to require the use of cable modems, DSL, etc.  At first glance, one might begin to look at common auction websites and develop a real-time auction from my analysis, but actually I intend to research how many chat rooms on the world wide web function and then build from them.  Chat rooms already contain the real-time communication aspect that users are commonly using.  Obviously, the encoding and decoding of data with a webcast takes time.  I will discuss current technology and how it compensates for this.
   

3. Server Software/Hardware

Obviously, reliability in this auction scenario is of the utmost importance.  Due to the size of these transactions (Mercedes-Benz Credit Corp. has an average selling price of about $35 thousand per unit), it is imperative that they are performed accurately and efficiently.  My discussion of webcasting below will examine potential server implementations as well as performance tests of these.  

4. Networking Technology

   Even with the most powerful servers and a series of sophisticated cameras, a weak and slow network will make your entire process fruitless.  Due to the expansion of broadband applications at reasonable prices, this desire to have adequate networks to handle the massive use of bandwidth for a webcasting auction.  In the report below, I will examine the technology behind these networks and compare cost vs. benefits in the current market.

5. Security Issues

   Obviously, security become one of the most important issues due to the nature of this business. 
   Automobiles are expensive items, especially luxury makes such as Mercedes Benz. Because of this, it
   is important that buyers are legitimately bidding on a particular unit and they are also licensed to bid at
   all. In addition, it is imperative that non-dealers do not have access to the bidding arena nor the
   information being produced. As one could imagine, access to fraudulent information could result to hundreds of thousands of dollars in theft.  I intend to discuss common secure transaction systems used on the web today that ensure proper authentication.

Webcasting Technology

1. General Definition

   With the appropriate equipment to capture, encode, stream and store (if required) audio and video, anyone can create live or on-demand webcasts. On-demand webcasts relate to information that is streamed from stored files on a given Web/Streaming server.  On the other hand, live broadcasts occur when data is streamed directly from its source (camera, microphone, inputted text, etc.).  Only three requirements are necessary to webcast; a PC, a server PC running Windows NT/2000 or UNIX/Linux, and a high speed Internet connection.

   The basic webcast process involves analog or digital video signals traveling via shielded cable from the camera to the encoding PC. At the same time the audio travels via shielded cables either from the camera or from a sound board to the encoding PC.

   The encoding PC converts the analog/video signals to a digital format and then streams the file over an ISDN line to the server. The server will then serve the streams to the people connecting to it. The server can also propagate a stream or streams to other servers, which can feed more end users. The following section describes in detail, the various aspects of webcasting that relate to capturing the video, encoding schemes, server technology, networking protocols and standards, and client viewing needs.  Furthermore, a brief summary of some webcasting standards and political issues and an examination of a case study done for an online webcaster.
   
   

2. Capturing the Video

   1. Features
      
      

      1. Resolution - This describes the clarity or sharpness of an image.
         
         

         1. Analog - the number of video scan lines that cross a screen horizontally.

         2. Digital - Also called capture area, this relates to the number of pixels that would be used to encode a digital signal.
            
            

      2. Contrast - This is the difference between the lightest and darkest points in video.  A high contrast image has well defined edges where as low contrast image would have blurred edges.
         
         

         1. Analog video allows an infinite number of shade between the light and dark points due to the continuous nature of an analog image.

         2. Digital video has a discrete number of shades encoded into it.  This number is called an images luminance, which is the number of shades of gray between the lightest and darkest points.
            
            

      3. Frame Rate - This is the number of images used to provide the illusion of movement in a given amount of time.  Television allows about 25-30 frames per second and currently webcasts run at about 10-20 frames per second.  Obviously, the higher the frame rate, the better quality the image.
         
         

      4. Color - This is measured as chrominance, which involves hue and saturation.  The hue is the color of the image and the saturation is the intensity of the color.
         
         

         1. Analog video encodes and infinite number of colors.

         2. Digital video, on the other hand, encodes only a certain number of color that can range anywhere from 256 to the millions.  In addition, dithering is an effect used in digital video that patterns two colors to mimic third shade.
            
            

      5. Synchronization - This is the correct alignment of sound and video.
         
         

         1. Analog video is synchronized by the use of time codes written in the media itself.  This code was created by the Society of Motion Picture and Television Engineers (SMPTE).

         2. Digital video - The above format is so popular that many digital systems are capable of reading SMPTE.  This allows the data to be resynchronized if necessary in digital form.
            
            

   2. Video Capturing Devices - This consists of a system that focuses an image onto a light transducer called a charge-coupled device (CCD), which then converts the light into an electrical signal.  A camera then "dumps" the electrical signal to an analog or digital output channel, which can be video equipment, computers, etc.
      
      

      1. Analog Camcorders - These are analog recording devices that convert the electrical signal to magnetic tape.  Types include:  VHS, still quite popular but relatively low quality; 8mm, Hi-8, which are slightly of a higher quality, and laser disks.  The big advantage of working with analog video as the primary source is the ease of archiving (ie on video tape vs hard drive). Professional analog video sources are relatively less expensive than professional digital video sources. Analog formats such as Hi-8 and SVHS provide excellent signal strength and resolution for the PC video studio. Although it can be argued that digital sources do not suffer from signal loss, the analog source can be kept clean by using good quality cables. In camcorders, the digital signal within the camera is converted to an analog signal in its output channel.  If one intends to use this signal by a computer, it must then be digitized by either a standard video card or more appropriately, a video capture card.  These video capture skills can range anywhere from under $100 to a few thousand dollars.
         
         

      2. Webcams - Common today, webcam purchases have increased 6 times in the past 3 years.   This form of webcasting is more easily described as a slide show--images are refreshed anywhere from once a day to every second in common image format such as .jpg and .gif. They remain inexpensive because they utilize the computer's processor(s) to process the video signal, thus frame rates and screen sizes depend on processor speed and main memory (RAM).  Frequently, webcams output to parallel ports or USB connections.
         
         

         
         
         
         

      3. Digital Video (DV) Cameras - Sources of digital video include a camcorder, video camera, digital television, and DVD, etc. The camera signals go through analog to a digital converter and the video data is compressed and then recorded on a MiniDV cassette or some other storage media. Digital images are then downloaded to a computer.

         Generally DVC's have sharper shooting then analog camcorders. Digital camcorders record about 500 lines of horizontal resolution compared to SVHS which records about 400 lines. Most DVC's are immune to signal interference and do not deteriorate from copy to copy. The quality of the audio is also good, DVC's can record in 16 bit stereo the same quality as audio CD's. Many DVC's have an IEEE 1394 port that allows them to plug into the back of a PC's parallel port.  High speed video transfer from the DV camcorder can be accomplished using Firewire, which is capable of 100-400 megabits per second transfers.
         
         
         
         
         
         
         

   3. Archiving - The amount of storage space required to store the webcast material depends on the compression ratio used/ achieved by the encoding software. However even compressed video requires large amounts of storage space. Dedicated storage systems are an important component of a webcasting system, especially if an organization will be archiving video on a regular basis.
      
      

      1. Magnetic Tape
         
         

         1. VHS - .5 in. tape in three formats Standard Play (SP), Long Play (LP), and Extended Play (EP) in relatively low quality but great affordability.

         2. Super VHS - .5 in tape that is 70 percent sharper than VHS.  Most Macintosh systems have built in capturing systems for this Super VHS.

         3. Betacam - .75 in tape that benefits from the better larger tape size and tape speed.  This format is not used much in residential applications and has quality that would not be utilized in your standard webcast.

         4. 8mm - This has a high quality sound, but video on par with VHS.

         5. Hi-8 - It is compatible with 8mm, but with 400-500 lines of resolution and similar sound quality.
            
            

      2. Digital Storage Media - See Webcasting Servers hard drive and backups.

       

3. Codecs
   

   Whether producing a live webcast or archiving for on-demand streaming media, video data must be compressed to a file size that can be played back on a computers since digitized video files are very large (10 seconds of uncompressed video can take approximately 15-20 Meg of hard drive space). Codec schemes have been developed to offer a solution to managing these large files. A codec is a term used to describe technology for compressing and decompressing data or more precisely an algorithm that is used to compress a file and then read it again later (zipping and unzipping files is an example of the use of a codec). A compression scheme reduces the incoming and outgoing stream of video to a rate that the PC can manage. Note that in order to go from uncompressed data to a 28.8Kbps modem rate, a compression ratio of about 12,000 to 1 is required.  This is why the use of complicated compression schemes such as lossy compression technology, which saves only the information that changes between each frame of video, is necessary. Although this may slightly degrade the video, hence the name "lossy", the smaller file size makes it much easier for a PC to manage. There are many codecs available, including MPEG, Cinepak and Indeo, and more discussed below.
   

   1. Sorenson Video - has been QuickTime's primary video codec since the release of QuickTime.  The Sorenson Video Codec is a lossy compression technique that produces Web video suitable for playback on most PCs and provides high quality video using a small amount of bandwidth for streaming over the Internet. Sorenson video looks great at 320x240 pixels, but only if streamed at rates higher than 100Kbs, which is only available with more expensive broadband connections. The Developer Edition of the Sorenson Codec allows for temporal scalability in which video plays at a high frame rate on fast broadband connections and lower frame rates on slower standard modem connections. One of the biggest drawbacks to using this codec is it takes a long time to encode media, which results in the need for fast encoding PCs. In addition to long compression times, areas on the uncompressed video with highly saturated color tend to look blocky after the encoding.
      
      

   2. Real G2 with SVT - RealSystem uses RealVideo with Scalable Video Technology (SVT) as its primary video codec. This codec has the ability to "scale" its behavior depending on a comparison of connection bit rate to the encoding bit rate.  It does this by dropping the less important detail information at the server side, and decoding as much as it can on the player side. While the quality in this lossy compression is less than would be achieved without any data being dropped, it is substantially better than dropping entire frames or sequences. This scalability is made possible by the nature of the wavelet algorithm, which encodes a signal as a series of successive refinements.  This codec was derived from Intel's Indeo Video Interactive codec.  Compared to most other codecs, G2 encodes faster than the rest, although unfortunately end users are required to have the most recent versions of RealPlayer since it is not backwards compatible.
      
      

   3. MPEG-1 and MPEG-2 - (Moving picture experts group-a working group of ISO-- term also refers to digital video compression standards and file formats developed by the group). MPEG files can be decoded by special hardware or by software. MPEG achieves a high compression rate by storing only the changes from one frame to another. The video information is then encoded using a algorithm called (Discrete Cosine Transform) DCT. MPEG uses a type of lossy compression, since some data is removed. But the diminishment of data is generally imperceptible to the human eye (see Codecs section for more information).

      The most common implementations of the MPEG-1 standard provide a video resolution of 352-by-240 at 30 frames per second (fps). This produces video quality slightly below the quality of conventional VHS cassettes. A newer standard, MPEG-2, offers resolutions of 720x480 and 1280x720 at 60 fps, with full CD-quality audio. This is sufficient for all the major TV standards, including (National Television Standards Committee) NTSC, and even HDTV. MPEG-2 is used by DVD-ROMs. MPEG-2 can compress a 2 hour video into a few gigabytes. Decompressing a MPEG-2 data stream requires only modest computing power, but encoding a video in MPEG-2 format requires significantly more processing power.

   4. MPEG-4 - MPEG is a set of international standards for audio and video compression and MPEG-4 is the newest MPEG standard, designed for the delivery of interactive multimedia across networks. As such, it is more than a single codec, and includes specifications for audio, video, and interactivity. Version 1 of the MPEG-4 spec was approved in 1999. Version 2 is expected to be finalized by the end of 2000.  The image quality has been significantly improved, and optimized for delivery of video at Internet data rates.  One downside is that MPEG-4 tends to be CPU intensive, so it generally requires fast computers.  The MPEG-4 file format is based on QuickTime.
      
      

   5. Windows Media MPEG-4v3 - Microsoft's derivative of the above MPEG-4 standard has advanced rapidly, with the current version 3. It's a simple codec implementation, without a lot of different features. Many users were confused because the Microsoft implementation isn't compatible with standard MPEG-4, so they've just renamed it.
      
      

4. Webcasting Servers - 
   
   
   In order for a webcast to be broadcasted of Internets or Intranets, a server must be must be capable of sending the information over data lines.  To broadcast a webcast a dedicated server is more or less required due to the power needs of today's webcasting. The server used depends on the type of technology used and how many streams are webcast and must be connected to enough bandwidth to handle those streams.  
      
   

   1. Hardware Specifications - Although, in theory, almost any server is capable of hosting a webcast, media servers tend to be much more powerful in order to efficiently support the numerous data requests at once (hundreds to many thousands in some cases).  For simplicity, examine the features of popular server, the Cisco Media Convergence Server 7835, which is priced around $10 thousand.
      
      
      
      
      

      1. Processors - The two major styles of processors include your Intel based Pentium and your RISC (Reduced Instruction Set Computing) architecture found in UNIX and Mac based systems.  Our example contains an Intel Pentium III 733-MHz processor although many media server motherboards support multiple processors.  While 733 MHz may seem average in today's world of GHz processors from Intel, many experts, including many from PC Magazine, suggest that faster processors do not improve performance enough to justify their cost, especially since processing bottlenecks tend to occur with hardware and network I/O.  More so, dual-processor situations tend to provide a better cost vs. benefit ratio.  Below is a benchmark test from PC Magazine that gives insight on how a multiple processor system out performs a single processor.
         
         
         
         
         
         
         Note that this is extremely important in webcasting since the demands on fast encoding and decoding as well as an increasing number of clients viewing a webcasts.  (See detailed benchmark in the footnotes)
         
         

      2. Hard Drive - Hard disks today basically fall into two categories:  IDE and SCSI.  Our example comes standard with dual 18.2 GB Ultra2 SCSI hot plug drives (they may be removed and re-installed without re-booting the system).
         
         

         1. IDE (Integrated Drive Electronics) - Actually most versions are EIDE or Enhanced IDE, and while considerably faster than standard IDE, they offer data access rates of about 16.6 Mb per second and tend to be much cheaper than SCSI interfaces.  This performance is dependent on cache on the drive controller and the speed of the drive (upwards of 15,000 rpm in the latest technology).  Although great for webcasters on a budget, IDE drives tend to lack the burst rate necessary to sustain worthwhile streaming media.
            
            

         2. SCSI (Small Computer Systems Interface) - This is a standard in Macintosh systems and fairly common in PC's and Unix boxes.  The main advantage over an IDE drive is the higher data access rates (up to 80 Mb per second and 320 Mb per second in the latest SCSI technology).  In addition a SCSI port can control up to seven devices rather than only two for IDE interfaces).  SCSI bus mastering lets the drive continue to operate without the help of the processor. In general, SCSI uses less processor time than IDE, which means the system appears to be faster during disk drive processes. This makes SCSI useful for high-performance situations like video editing and webcasting. (See Various SCSI generations).
            
            

         3. RAID (Redundant Array of Independent Disks) -  This uses "disk striping", which interleaves data across different drives and thus allow reads and writes of multiple drives at a time.  This does not describe the internal configuration of the drive, but how drives are configured in an array of multiple drives.  There are various configurations, but RAID arrays tend to reduce error rates and increase redundancies of stored data.
            
            

      3. Backups - Backing up your webcast server, or any server for that matter, is probably a good policy for two reasons:  in case of failure, you limit your data loss and you have the ability to archive all your past webcasts.  There are numerous options when backing up your server.  They include your traditional tape drives, hot-swap plugs, which allow for quick swapping of SCSI drives on a chain, and with increasing popularity today are CD-R and CD-RW disks.  The Cisco Server has an optional internal 12/24 GB DAT drive in order to save critical data.
         
         

      4. Memory  - With the need for extremely fast compression and decompression in today's webcasts, the need for large amounts, and unfortunately expensive, memory is needed.  In our example, the Cisco Media Server can be upgraded to approximately 4GB SDRAM.
         
         

   2. Operating Systems
      
      

      1. UNIX based - Not only are Unix based operating systems the first to support the internet, they are still currently the best for webcasting.  In addition, with the many extremely affordable variations of Linux running on Intel processors, these stable platforms should remain fairly popular for webcasters, especially those on a budget.
         
         

      2. Windows NT/2000 - With significant name recognition and plentiful resources, Microsoft products have a relatively small learning curve, yet less scalable than a UNIX based system.  In general, though, it is thought that if you decide you webcast using an NT system, you will probably require more powerful hardware.
         
         

   3. Standard Web Server - Examples such as Apache, Microsoft Server, and iPlanet account for 60 percent, 20 percent, and 7 percent of the Web server market as of September 2000 according to a Netcraft Web Server Survey. 
      
      

      
      

      1. Posting - The use of streaming media with a standard web server is essentially no more than a downloading and playing a file. This media file is then placed on a standard web server and then a web page containing a link with the media file's URL is placed on the same web server. When the link is activated, the client-side player opens and the media file is downloaded. 
         
         

      2. Progressive Streaming -  In this case, a webcast may be viewed as it is being downloaded but the user cannot access portions of the file that haven’t been transferred yet. Progressive streaming files don’t adjust during transmission to match the bandwidth of the user’s connection like a realtime streaming format. In fact, the user receives data as fast as the web server, network, and client will allow without regard to the encoding bit rate of the stream.  Progressive streaming is often called HTTP streaming because standard HTTP protocols are capable of streaming in this fashion.  Progressive streaming delivery is primarily used for short video clips that you want to be viewed at high quality, such as movie trailers and product advertisements, due to the fact that you will be able to deliver video streams with a higher data rate than your modem could stream with real time streaming. This method guarantees the quality of the final movie because the viewed portion of the file is losslessly downloaded before it is played. This means users may experience a delay before the movie starts, especially with slower connections.  Because progressive streaming material is placed on a standard HTTP or FTP server, it is easier to administer, and generally corporate firewalls permit access through HTTP ports.  Unfortunately, progressive streaming is not a good solution for long movies or videos that you only wish to access specific points, such as lectures, speeches or presentations. In addition, it is appropriate to note that progressive streaming does not work for material that must be broadcast live — it is strictly an on-demand technology.
         
         

      3. HTTP (Hyper Text Transport Protocol) - HTTP operates on top of the Transmission Control Protocol (TCP), which handles all the data transfers. Optimized for non-real-time applications such as file transfer and remote log-in, TCP's goal is to maximize the data transfer rate while ensuring overall stability and high throughput of the entire network. To achieve this, using an algorithm called slow start, TCP first sends data at a low data rate, and then gradually increases the rate until the destination reports packet loss. TCP then assumes it has hit the bandwidth limit or network congestion, and returns to sending data at a low data rate, then gradually increases, repeating the process. TCP achieves reliable data transfer by re-transmitting lost packets. However, it cannot ensure that all resent packets will arrive at the client in time to be played in the media stream.
         
         

      4. Advantages to Web Server - The main advantage to streaming with a Web server rather than with a streaming media server is that it utilizes existing world wide web infrastructure. Thus, no new server software will be required which, in turn, will reduce the incremental costs inherent in learning and managing a more complex streaming media server.

         In addition, there is an increased load that Web server-based streaming puts on existing Web server infrastructure which often results in the need for additional more powerful server hardware to service the client requests. Thus, choosing Web server streaming over a dedicated streaming media server based on increased hardware cost alone usually does not result in any savings, financially speaking.
         
         

   4. Streaming Media Server
      
      

      1. Posting - In the streaming media server approach, the initial steps are similar to the web server approach, except that the media file is copied to a specialized streaming media server  instead of a web server. A web page with a link to the given media file is placed on a web server (not the streaming media server). Note that it is possible to have both the web server and media server running on the same computer.
         
         

      2. RealTime Streaming - This refers to streaming media technology that keeps the bandwidth of the media signal matched to that of the viewer’s connection so that the media is always seen in realtime. This matching technique is in contrast to the burst methodology used in web server streaming.  The word realtime differentiates this type of streaming from your standard HTTP streaming delivery. Dedicated streaming media servers and streaming protocols are required to enable true realtime streaming. Most media servers also supports random access of material, so the user can fast forward to specific portions of a video, which may be useful for presentations and lectures. In theory, realtime streaming movies should never pause once they start playing, but in reality, periodic pauses may occur.  This is caused because information that is lost in the network due to errors is often ignored, so the video quality and totality will suffer from network congestion and failure. Furthermore, realtime streaming movies must match the bandwidth of the viewer’s connection, which means the image quality is generally poor at slow analog modem speeds. In general, when maximum media quality is required, progressive streaming delivery may be a better solution. 
         
         Realtime streaming media requires special servers, such as a QuickTime Streaming Server, a RealServer or a Windows Media Server. These give you a greater level of control over your media delivery but can be more complicated to set up and administer than a standard HTTP servers such as Apache or FrontPage Server. Also, realtime streaming uses special network protocols, such as RTSP (Realtime Streaming Protocol) or UDP (User Datagram Protocol). These protocols can sometimes have trouble with corporate firewalls that disallow the use of protocols on specific network ports, so in certain situations, a user may not be able to view a live webcast.
         
         

      3. UDP (User Datagram Protocol) - RealServer, Windows Media and QuickTime all offer realtime streaming capabilities and use specialized protocols such as UDP (User Datagram Protocol), which is a fast, lightweight protocol that lacks the re-transmission and data rate management functionality of TCP.  This makes UDP an ideal protocol for transmitting realtime streaming video, which can tolerate some lost packets. As a bonus, because of the conservative wait policies implicit in the TCP protocol, UDP traffic gets higher priority than the TCP traffic on the Internet. And instead of the blind retransmission scheme employed by TCP, streaming media servers use an intelligent retransmission schemes on top of UDP that only retransmit lost packets to the client in time for playback.  The only downside to UDP is that many network administrators close their firewalls to UDP traffic, limiting the potential audience of UDP-based streams.
         
         

      4. Advantages of Streaming Media Server
         
         

         1. More Efficient Network Throughput. The TCP-based transfer used in Web server streaming is designed to repeatedly drive the slowest network link (likely the 28.8 Kbps modem link) to packet loss. This wastes bandwidth by: 

            (i) re-transmitting data to replace the lost packets; and 

            (ii) under-utilizing the network link while re-estimating the throughput that can be supported by the network connection.
            
            The UDP protocol allows higher bandwidth to be delivered to the client (resulting in better video quality), even when assuming the same network connectivity between server and client and the same level of congestion on the Internet. By having a specialized streaming media server, we know what rate the data is going to be consumed, based on headers of the compressed media file. Data is sent to the client only at this required bit-rate, and it doesn't drive the bottleneck network link to loss. Thus the network throughput is better, resulting in better quality audio and video for the client.
            
            

         2. Better Audio and Video Quality to the User. Better network throughput is only one of several ways that a Streaming media server delivers superior audio and video quality for users. Since the media server and the media player remain in contact throughout the play interval, the server can dynamically respond to client feedback. If network congestion is allowing only 22 Kbps of data to reach the client (instead of 28.8 Kbps), the server can decide to retain the audio quality but slightly lower the frame rate of the video stream so that it doesn't overshoot the available 22 Kbps. This ability is not possible with the Web server approach. In a Web server scenario, with no feedback from the client and no ability to dynamically prioritize audio over video, the audio/video delivered by a Web server would be stop-and-go at the client, causing the constant "rebuffering" delays common to early implementations of streaming media. In contrast, streaming media servers attempt to provide a continuous, smooth stream with barely perceptible changes in video frame rate during periods of network congestion. Media servers takes advantage of UDP's inherent higher priority over HTTP traffic to give the streaming audio and video data higher priority than file and Web page transfers, which increases the likelihood of uninterrupted viewing. 
            
            

         3. Support for Advanced Features. Most media servers support such advanced features as detailed reporting of streams played, VCR controls (seek, fast-forward, rewind), live video delivery, and delivery of multiple streams to the client. With Web server streaming such features, if they are even possible, are difficult to implement and inefficient to support. 
            
            

         4. Cost Effective Scalability to Large Number of Users. In the early days of streaming media, deployments often needed to serve only a small number of users simultaneously, making Web server streaming an adequate solution. But as delivery of audio and video has increased, sites often serve hundreds or thousands of simultaneous users. In these situations, two key capabilities of most media servers provide increasing advantages over a Web server: Specialization. In the Web server approach, the Web server is used to deliver the media files to the client. Web servers, however, are optimized for delivering lots of small HTML files, not large media files. With high volumes of file requests, these servers greatly improve performance by optimizing how media files are read from the disk, buffered in main memory, and streamed onto the network. Multicast Support (see Multicasting below). One way to get live or stored audio and video to large audiences with minimum network congestion is to use multicast networking technology. Multicast allows a single media stream to be played simultaneously by multiple clients, drastically reducing bandwidth use. 
            
            

         5. Protection of Content Copyright. Because Web server streaming creates a local cached copy of every media file played, there is no way to prevent end users from copying the files to a personal directory for later viewing. This hurts content providers who have a pay-per-view business model, or who have an advertisement-based revenue model, as the end users need not visit their site repeatedly. With a media server, users can only stream data and are prevented from downloading the file directly to their hard disk. As data packets are received over the network, they are delivered directly to the client application with no easy way for the end user to intervene and make a copy.
            
            

         6. Multiple Delivery Options. With a Windows Media server, the media may be streamed with the optimal UDP, RTSP or Multicast protocols when possible, and streamed with the TCP protocol when necessary. This enables corporate users to view Internet content without compromising firewall security and ensures that all users on all networks can access all streaming media content. Powerful media servers today even attempt to utilize HTTP protocols when necessary in order to penetrate corporate firewalls, while still maintaining most of the streaming media server functionality when possible.
            
            

   5. Performance Evaluation

To better understand the benefits of a streaming media server when broadcasting a webcast, testing was done using two separate servers.  A RealServer media server was installed on a Intel Pentium III 500Mhz system as was an Apace Server.  A software package called WebStress 4.0 was used that measures response time of a server at various numbers of simultaneous users.  Below are the results of those tests:

Note above that the error rates even with 100 simultaneous users is actually zero.  This shows the capabilities of the RealServer to ensure that each user (regardless of response time) will have the ability to view a webcast.  Also, the high error rates of the HTML code and the Servlet are more of an issue of hardware.

Let's examine the results of the median response times depending on the number of simultaneous users.  Whereas the HTML code and the Servlet tend to have a gradually increasing response time, the Streaming Media's response time increases dramatically at around 55 users.  This problem can be attributed to numerous reasons, but primarily, the limits of the RealServer (the version used was an evaluation version that has many limitations).

Let's examine the results of the mean response times depending on the number of simultaneous users.  Again, notice that the HTML code and the Servlet response times remain relatively stable as the number of users increases.  The streaming media, on the other hand, has an almost exponential increase in response time as the number of simultaneous users increases.  View this trend in the median and mean results leads to the conclusion that the RealServer, although it will cater to all users, will server a specific number of users until about 55 users, after which, each additional user will sacrifice a great deal in response time.

In this case, when we filter out any responses that create errors, the RealServer seems to perform better, especially when compared to the HTML performance.

Finally, when the mean response times are examined with filtered results (that is, the error responses are removed from the equation), you will notice that both the HTML and the Servlet perform more poorly, overall, but not yet to the point of outperforming the RealServer.

5. Webcasting Networks - 
   
   
   There are numerous options regarding uploading a webcast to a server.  If your webcast involves only On-Demand streaming, uploading at faster speeds will not be as important as uploading for a live broadcast, where the bandwidth of the broadcast dictates the upload speed necessary.  Usually 20Kps is required for each person connecting with a 28.8K and at least 40Kps for each person on a 56K or greater connection. Multiple servers can be used to increase available bandwidth.  
   
   As for use in the future, notice the trend that Forrester research has predicted in the Networking market.
   
   
   
   
   

   1. Delivery Strategies
      
      

      1. Unicasting - Unicasting sends out one copy of each webcast data packet to each viewer. However for a large viewer webcast this would require huge amounts of bandwidth. For example, if 50,000 viewers were simultaneously accessing a 20Kbps stream webcast, 1Gbps of server bandwidth would be required.
         
         
         
         
         
         
         

      2. Multicasting - MBONE - Multicast backBONE network was a protocol form of IP multicasting, which actually began running in 1994.  It works by replicating a webcast to numerous servers, thus reducing the network congestion on the original source.  This form of multicasting has been built on today by the IP multicast Initiative.  Multicast is an extension of the Internet Protocol (IP) that is used on the Internet. With IP Multicast, the server sends out a single data packet and only at points in the Internet where the data needs to go in different directions to reach different viewers (such as routers or switches) is the data packet cloned, and a copy of the packet is sent in each of the different directions.  In other words, Multicasting eliminates the network bottleneck by decentralizing the webcast sending network packets to numerous servers which repeat a webcast.  Furthermore, Multicasting is becoming prevalent on corporate networks, but is still very rare on the Internet due to the need of the specialized multicasting routers.

         Until recently, multicasting was implemented through unicast "tunnels" between the MBONE specially equipped high-speed networks, usually LAN connections. Recently, multicast-capable routers have been deployed by some Internet Service Providers and the hardware that dial-up users call into (known as "access servers" "WAN switches" or "terminal servers") are available with multicast capability.  Note below the bandwidth savings from the webcast source.
         
         
         
         
         
         

          

      3. Edge Technology - This builds on the webcasting situations where multiple users around the world will expect certain information on an ongoing basis.  Large servers with capacities in the range of two or more terabytes are strategically located around the world.  Thus when new information is gathered at the source, it is then output to POP servers in various local areas.  This reduces unnecessary bottlenecks that may occur over long distances on the entire internet.  Furthermore, edge technology, in a sense, caches common data for easy local access.  Obvious, from the design, this form of delivery does not advance realtime streaming, as it is strictly an on-demand delivery technique.
         
         

   2. Standard Internet Access
      
      

      1. 56K modem - These are not particularly effective in live webcasting since you are limited to an upload speed of about 33Kbps.  One bandwidth increase strategy with a standard analog modem is through using multiple modems on separate phone lines and "pooling" the bandwidth.
         
         

      2. Integrated Services Digital Network (ISDN) Connections - Developed in the 70's, ISDN consists of two 64Kbps channels that combine to form a data rate of 128Kbps.  This configuration is not especially popular among consumers due to the fact that special circuitry must be installed by your phone company before you can run a digital ISDN modem.
         
         

   3. Broadband Internet Access - 
      
      

      1. Digital Subscriber Lines (DSL) - Becoming more and more popular today, DSL service provides a speed of approximately 100-1000Kbps, yet bypassing the public phone switches, which allows it to easily be left on continuously.  This lends itself to an ideal condition for web hosting.  The one downside of DSL is that a subscriber must have phone lines running less than 2 miles from the central office and overall bandwidth tends to decrease the further from that office.  Overall, with increased bandwidth and costs less than ISDN, DSL offers a relatively decent cost vs. benefits.
         
         

      2. Cable Modems - Considered direct competition in cost and value with DSL, cable modems offer high speed connections and uploads around 3Mbps (depending on line traffic).  One concern for modem services is that your cable company must provide the service which reduces your options regarding Internet Service Provider choices.
         
         

      3. Leased T1/T3 Lines - These are phone lines with constant open circuits and like ISDN, these circuits must be installed by your phone company.  T1 lines, for example, are quite fast reaching bandwidth levels of around 24 standard analog modems.  Quite expensive and primarily used in corporate settings, leased lines offer around 400Kbps - 2Mbps in bandwidth and upwards of 45Mbps in Full T3 form.  As monthly costs can rise to around $20000 not including your routing equipment, you can see why this network situation is usually left to corporate applications.
         
         

      4. Wireless Connections - Many experts suggest that this is the ultimate destiny for webcasting.  Currently, this technology provides speeds around 128Kbps to 1.5Mbps, depending on whether or not the system is line-of-sight or not (the signals are not allowed to bend around obstacles in a line-of-sight system), and has the advantage of mobility.  Unfortunately, for the mean time, the user areas tend to be based in major metropolitan areas and don't allow access when you leave your area.  In addition, even at the low end of bandwidth, it tends to cost consumers around $60 to $90 per month not including the special modems required for this service which run around $300.
         
         

      Note: Video streams can get bogged down not just at the "last mile" to the home user, where faster broadband modems and digital lines speed streaming, but they also can bottleneck at many other locations on the Internet and at the broadcaster's own server.  Basically, don't assume because you invested in high speed internet access that all webcasts will be high quality. 

Technology	Classification	Symmetrical	Speed(s)	Time to Download 2minute video clip
14.4K Analog modem	Narrowband	Yes	14.4 Kbps	5 hours
56K Analog	Narrowband	Yes	56Kbps	1.25 hours
ISDN	Narrowband	Yes	128Kbps	30 minutes
ADSL	Broadband	NO	128Kbps-384Kbps	20 minutes
Satellite	Broadband	NO	384Kbps	10 minutes
Wireless	Broadband	Yes	128Kbps-1.5Mbps	2.8 minutes
SDSL	Broadband	Yes	384Kbps-8Mbps	30 seconds
Cable Modem	Broadband	Yes	128Kbps-10Mbps	25 seconds

6. Viewing a Webcast
   
   

   1. Equipment Requirements - In order to view a webcast the viewer will need an Internet connection, Browser and a PC with minimum a MMX Pentium with at least 120Mhz, or PowerMac 25MHz or faster, Windows 95, a hard drive and a decent AGP graphics card.
      
      

   2. Video Players - Webcasts can be played through stand alone players such as Quicktime and Real Player which depend on a client having particular software packages.  In addition, there are available browser plug-ins which allow a webcast to be viewed within a browser.  These, of course require additional software for which the client must download rather than a Java Applet that downloads a player directly.  The data stream is in the form of a metafile which uses a specific instructions on how a player must utilize the stream.  
      
      

      1. RealVideo - RealVideo was added with Version 4.0 in 1997. Real has just introduced
         Version 8.0, an incremental, but substantial, upgrade from the major improvements of G2 in 2000. Its big changes are better decoding performance, improved encoding technologies, and a full player makeover as you can see below.   The native file format for RealMedia is a RealMedia file, or .rm.  Secondly, you may recall seeing .ram files, these tell the player where on the media server to find the .rm data. 
         
         
         
         
         
         RealPlayer Version 8.0 is in full release for Win32 and in beta for Mac OS 8.1 or greater. While the original version of G2 had rather poor performance on the Mac (it had difficulty playing broadband content without dropped frames even on a G3/400), the Version 8.0 Mac beta is much better, and is good enough for daily use. Real historically has supported the various UNIX platforms, but doesn't have a more current version than Version 5.0.  Real also has the capabilities of playing some QuickTime and AVI files, but it does not have the capabilities of using Sorensen codecs or .asf for that matter.
         
         

      2. Quicktime - Quicktime is the oldest digital video architecture around and has been doing video on the Web, albeit only as progressive streaming, for many years. QuickTime has actually only supported real streaming since about a year ago.  Current versions of Quicktime support SMIL, the same rich media that's at the core of RealMedia. Second, it now supports streaming through an HTTP connection (in addition to RealTime Streaming Protocol), which makes QuickTime as capable of getting through corporate firewalls as Real and Windows Media. Last, the Mac version has added Apple Script support, which makes it much easier to do automated media creation.  The native QuickTime file format is a QuickTime file, generally .mov, but sometimes .qt or .qti.  Below is a screenshot of their latest version.

         
         
         
         
         
         QuickTime v4.1 runs well on any Win32 system or PowerPC-based Macintosh. The biggest difference among platforms is the lack of MPEG-1 playback on QuickTime for Windows. This isn't generally a big deal because Windows Media Player handles these files fine.  In addition, QuickTime does a fairly decent job of playing AVI files, but fails to play the .asf files created by Windows Media.
         
         

      3. Windows Media - Windows Media, formerly known as NetShow, is Microsoft's entry into the streaming Web video market. The newest of the three, Microsoft is using its endless resources to force this media player onto the webcasting market. Windows Media is a much simpler solution than either QuickTime or Real because Microsoft doesn't position it as a complete platform, but rather the streaming audio and video component of a Web browser. However, it does that quite well. Recent innovation has focused on codec improvement and implementation of pay-per-view and authentication features through the Windows Media Rights Manager.  The native file format of Window Media is the Advanced Streaming Format, or .asf.  Note that Microsofts ASF includes three formats, the video portion is usually compressed to MPEG 4, the audio MPEG 3 and a control file. When the ASF file is streamed to a Windows Media Player the compressed information contained in the file is decompressed by the software and then viewed by the user.  Note below, the screenshot of the Windows Media that is a standard addition to the Windows operating systems.
         

         
         
         
         
         Windows Media runs great on Windows 98/NT/2000. Unfortunately, that's the only viable platform right now since none of the Microsoft beta players for Mac have been stable or high quality enough for even occasional use. Microsoft promises to have complete Mac and UNIX versions available in the future.
         

         View These Players in Action!!
         
         

      4. Note the market use of the three major video players from a Jan. '00 Nielsen/NetRatings survey report:
         
         
         

         Market Use of Media Players
         Player	Unique Audience	Reach
         RealPlayer	8,973,331	12.1 percent
         QuickTime	5,461,303	7.4 percent
         Windows Media	2,376,191	3.2 percent

         
         

7. Webcasting Standards
   
   

   1. SMIL - The growth of webcasting also has an increased need for standards consolidation.  This has been a desire of the World Wide Web Consortium through Synchronized Multimedia Integration Language (SMIL), which is a markup language for streaming media first released in  June 1998.  This is a simple language, which is similar to HTML with an added concept of time, is great for doing two things: assembling simple slide shows from still images and adding "wrappers" or links to existing video and audio sequences.  For example, you can place an ad at the beginning or end of a video sequence that's a link to a site.
      
      

   2. Benchmarking Webcasts - The first effort to set a benchmark in the Webcasting industry comes from the well respected performance measuring company, Keynote Systems.  It works on a 1 to 10 scale and the bar is set high.  No streaming website has reached a solid 10 (DVD quality) and, in fact, the best streaming today would receive around a six, which is around the same quality as a home VHS video.  See below the results of recent tests from Keynote Systems:  Keynote Streaming 20 Streaming Media Performance Index (See Footnotes for more information on the Benchmark).  Note the relative low quality of today's popular webcasting websites.
      
      
      

      	Week of October 29 to November 04
      Category	Best Site	Stream Quality*	Rendering Score*	Availability*
      Index		1.66	82.5%	59.0%
      Audio E-commerce Broadcast Radio Financial Audio Cable Television	Barnes & Noble WUSL Radio ON24 MTV	1.89 2.09 1.89 3.97	99.0 % 100 % 99.0 % 90.0 %	48.4 % 49.1 % 54.1 % 54.4 %
      	Week of October 22 to October 28
      Category	Best Site	Stream Quality*	Rendering Score*	Availability*
      Index		1.74	78.8%	73.6%
      Audio E-commerce Broadcast Radio Financial Audio Cable Television	Barnes & Noble WUSL Radio ON24 MTV	1.89 2.06 1.87 3.55	99.0 % 98.4 % 98.7 % 80.4 %	60.2 % 72.9 % 70.6 % 84.3 %

8. Security Issues 
   

   Virtually all businesses, most government agencies, and many individuals now have web sites. The number of individuals and companies with Internet access is expanding rapidly, and all of these have graphical Web browsers. As a result, businesses are enthusiastic about setting up facilities on the web for electronic commerce. But the reality is that the Internet and the Web are extremely vulnerable to compromises of various sorts. As businesses wake up to this reality, the demand for secure Web services grows.
   
   

   1. Considerations
      

      The Internet is two way. Unlike traditional publishing environments, the web is vulnerable to security attacks on the servers where web sites are stored. The Web is increasingly serving as a highly visible outlet for corporate and product information and as the platform for business transactions. Reputations can be damaged and money can be lost if the Web servers are subverted in any way. The importance of security in an online automobile auction is extraordinarily important due to the level of monetary transactions.  The complex software that runs these online servers and commerce may hide many potential security flaws. We have been shown from reports on yahoo.com be shut down and attacks on e-bay.com, that the internet is filled with examples of websites vulnerable to a variety of security attacks. Once a web server is subverted, an attacker may be able to gain access to data and systems such as user information at the local site. Below are examples of security threats:
      
      

      	Threats	Consequences	Countermeasures
      Integrity	Modification of user data Trojan horse browser Modification of memory Modification of message traffic in transit	Loss of information Compromise of machine Vulnerability to all other threats	Cryptographic checksums
      Confidentiality	Eavesdropping on the Net Theft of info from server Theft of data from client Info about network configuration Info about which client talks to server	Loss of information Loss of privacy	Encryption, Web proxies
      Denial of Service	Killing of user threads Flooding machine with bogus threats Filling up disk or memory Isolating machine by DNS attacks	Disruptive Annoying Prevent user from getting work done	Difficult to prevent
      Authentication	Impersonation of legitimate users Data forgery	Misrepresentation of user Belief that false information is valid	Cryptographic techniques

      
      There are two different ways you can categorize these threats:   one way to group these threats is in terms of passive and active attacks. Passive attacks include eavesdropping on network traffic between browser and server and gaining access to information on a Web site that is supposed to be restricted. Active attacks include impersonating another user, altering messages in transit between client and server, and altering information on a Web site.  Another way to classify Web security threats is in terms of the location of the threat: Web server, Web browser, and network traffic between browser and server. 
      
      
      

   2. Approaches
      

      A number of approaches to providing Web security are possible. The various approaches that have been considered are similar in the services they provide and in the mechanisms that they use, but they differ with respect to their scope of applicability and their relative location within the TCP/IP protocol stack.  Notice the difference:
      
      
      

      
      

       

      One way to provide Web security is to use IP Security at the Network Level. The advantage of using IPSec is that it is transparent to end users and applications and provides a general-purpose solution. Further, IPSec includes a filtering capability so that only selected traffic need incur the overhead of IPSec processing.  Another solution is to implement security just above TCP at the Transport Level. The best example of this approach is the Secure Sockets Layer (SSL) and the follow-on Internet standard of SSL known as Transport Layer Security (TLS). There are two implementation choices at the Transport Level. They are:  SSL provided as transparent to applications and in a less general sense and SSL embedded in specific applications (i.e. Netscape and Microsoft Explorer browsers come equipped with SSL).  Lastly, there can be security services embedded within an application at the Application Level. The advantage of this approach is that the service can be tailored to the specific needs of a given application. In the context of Web security, an important example of this approach is Secure Electronic Transaction (SET), which will also be discussed further below.
      
      

      1. Secure Socket Layer (SSL) - SSL was originated by Netscape. Version 3 of the protocol was designed with public review and input from industry and was published as an Internet draft document. Subsequently, when a consensus was reached to submit the protocol for Internet standardization, the TLS working group was formed within IETF to develop a common standard.  SSL is designed to make use of TCP to provide a reliable end-to-end secure service. SSL is not a single protocol but rather two layers of protocols, as shown below:
         
         
         
         
         

         The SSL Record Protocol provides basic security services to various higher-layer protocols. In particular, the hypertext transfer protocol (HTTP), which provides the transfer service for Web client/server interaction, can operate on top of SSL. Three higher-layer protocols are defined as part of SSL: the Handshake Protocol, the Change Cipher Spec Protocol, and the Alert Protocol. These SSL-specific protocols are used in the management of SSL exchanges and are will be discussed in further below.

         Two important SSL concepts are the SSL session, which is defined as an association between a client and a server that are created by the Handshake Protocol. Sessions define a set of cryptographic security parameters, which can be shared among multiple connections. Sessions are used to avoid the expensive negotiation of new security parameters for each connection. And, in addition, the SSL connection, which is a transport that provides a suitable type of service in a peer-to-peer relationships. The connections are transient and every connection is associated with one session.

         Between any pair of parties (applications such as HTTP on client and server), there may be multiple secure connections. In theory, there may also be multiple simultaneous sessions between parties, but this feature is not used in practice.  There are actually a number of states associated with each session. Once a session is established, there is a current operating state for both read and write (i.e., receive and send). In addition, during the Handshake Protocol, pending read and write states are created. Upon successful conclusion of the Handshake Protocol, the pending states become the current states.
         
         

         1. SSL Record Protocol - Provides two services for SSL connections: Confidentiality, whereby the Handshake Protocol defines a shared secret key that is used for conventional encryption of SSL payloads, and Message integrity, where the Handshake Protocol also defines a shared secret key that is used to form a message authentication code (MAC).
            
            

            
            

            Each upper-layer message is fragmented into blocks of 214 bytes or less. Next, lossless compression is optionally applied and may not increase the content length by more than 1024 bytes.  In SLLv3 (as well as the current version of TLS), no compression algorithm is specified, so the default compression algorithm is null.  The next step in processing is to compute a message authentication code over the compressed data. For this purpose, a shared secret key is used. Then, the compressed message plus the MAC are encrypted using symmetric encryption. Encryption may not increase the content length by more than 1024 bytes.  The final step of SSL Record Protocol processing is to prepend a header, consisting of processing information, SSL version, etc.
            
            

         2. Change Cipher Spec Protocol - is one of the three SSL-specific protocols that use the SSL Record Protocol, and it is the simplest. This protocol consists of a single message, which consists of a single byte with the value 1. The sole purpose of this message is to cause the pending state to be copied into the current state, which updates the cipher suite to be used on this connection.
            
            

         3. Alert Protocol - is used to convey SSL-related alerts to the peer entity. As with other applications that use SSL, alert messages are compressed and encrypted, as specified by the current state.  Each message in this protocol consists of two bytes. The first byte takes the value "warning" or "fatal" to convey the severity of the message. If the level is fatal, SSL immediately terminates the connection. Other connections on the same session may continue, but no new connections on this session may be established. The second byte contains a code that indicates the specific alert.
            
            

         4. Handshake Protocol - The most complex part of SSL is the Handshake Protocol, which allows the server and client to authenticate each other and to negotiate an encryption and MAC algorithm and cryptographic keys to be used to protect data sent in an SSL record. The handshake protocol is used before any application data is transmitted.  The Handshake Protocol consists of a series of messages exchanged by client and server with three fields: type, length, and content. The exchange can be viewed as having four phases:
            
            

            1. Phase 1 - Establish Security Capabilities - This phase is used to initiate a logical connection and to establish the security capabilities that will be associated with it.
               
               

            2. Phase 2 - Server Authentication and Key Exchange - The server begins this phase by sending its certificate, if it needs to be authenticated; the message contains one or a chain of X.509 certificates.
               
               

            3. Phase 3 - Client Authentication and Key Exchange
               
               

            4. Phase 4 - Finish - This phase completes the setting up of a secure connection.  At this point the handshake is complete and the client and server may begin to exchange application layer data.

             

      2. Secure Electronic Transaction (SET) - SET is an open encryption and security specification designed to protect credit card transactions on the Internet. The current version, SETv1, emerged from a call for security standards by MasterCard and Visa in February 1996. A wide range of companies were involved in developing the initial specification, including IBM, Microsoft, Netscape, RSA, Terisa, and VeriSign. Beginning in 1996, there have been numerous tests of the concept, and by 1998 the first wave of SET-compliant products was available.

         SET is not itself a payment system. Rather it is a set of security protocols and formats that enables users to employ the existing credit card payment infrastructure on an open network, such as the Internet, in a secure fashion. In essence, SET provides three services:
         
         

         • Provides a secure communications channel among all parties involved in a transaction 

         • Provides trust by the use of X.509v3 digital certificates 

         • Ensures privacy because the information is only available to parties in a transaction when and where necessary

         SET is a complex specification defined in three books issued in May of 1997:  Book 1 - Business Description, Book 2 - Programmer's Guide, and Book 3 - Formal Protocol Definition.  All of which add up to a much greater amount of specification than SSL provides.
         
         

         1. Business Requirements of SET - Book 1 of the SET specification lists the following business requirements for secure payment processing with credit cards over the Internet and other networks:
            
            

            1. Provide confidentiality of payment and ordering information: It is necessary to assure cardholders that this information is safe and accessible only to the intended recipient. Confidentiality also reduces the risk of fraud by either party to the transaction or by malicious third parties. SET uses encryption to provide confidentiality. 
               
               

            2. Ensure the integrity of all transmitted data: That is, ensure that no changes in content occur during transmission of SET messages. Digital signatures are used to provide integrity. 
               
               

            3. Provide authentication that a cardholder is a legitimate user of a credit card account: A mechanism that links a cardholder to a specific account number reduces the incidence of fraud and the overall cost of payment processing. Digital signatures and certificates are used to verify that a cardholder is a legitimate user of a valid account. Provide authentication that a merchant can accept credit card transactions through its relationship with a financial institution: This is the complement to the preceding requirement. Cardholders need to be able to identify merchants with whom they can conduct secure transactions. Again, digital signatures and certificates are used. 
               
               

            4. Ensure the use of the best security practices and system design techniques to protect all legitimate parties in an electronic commerce transaction: SET is a well-tested specification based on highly secure cryptographic algorithms and protocols. 
               
               

            5. Create a protocol that neither depends on transport security mechanisms nor prevents their use: SET can securely operate over a "raw" TCP/IP stack. However, SET does not interfere with the use of other security mechanisms, such as IPSec and SSL/TLS. 
               
               

            6. Facilitate and encourage interoperability among software and network providers: The SET protocols and formats are independent of hardware platform, operating system, and Web software.
               
               

         2. Key Features of SET
            
            

            1. Confidentiality of information: Cardholder account and payment information is secured as it travels across the network. An interesting and important feature of SET is that it prevents the merchant from learning the cardholder's credit card number; this is only provided to the issuing bank. Conventional encryption by DES is used to provide confidentiality. 
               
               

            2. Integrity of data: Payment information sent from cardholders to merchants includes order information, personal data, and payment instructions. SET guarantees that these message contents are not altered in transit. 
               
               

            3. Cardholder account authentication: SET enables merchants to verify that a cardholder is a legitimate user of a valid card account number. SET uses X.509v3 digital certificates with RSA signatures for this purpose. 
               
               

            4. Merchant authentication: SET enables cardholders to verify that a merchant has a relationship with a financial institution allowing it to accept payment cards. SET uses X.509v3 digital certificates with RSA signatures for this.
               
               

         3. Participants of SET - Below is a figure that represents each of the participants.
            
            

            1. Cardholder: In the electronic environment, consumers and corporate purchasers interact with merchants from personal computers over the Internet. A cardholder is an authorized holder of a payment card (e.g., MasterCard, Visa, or for our purposes, Manhiem Auto Auction) that has been issued by an issuer.
               
               

            2. Merchant: A merchant is a person or organization (Manhiem Auto Auction) that has goods or services to sell to the cardholder. Typically, these goods and services are offered via a Web site or by electronic mail. A merchant that accepts payment cards must have a relationship with an acquirer.
               
               

            3. Issuer: This is a financial institution, such as a bank, that provides the cardholder with the payment card. Typically, accounts are applied for and opened by mail or in person. Ultimately, it is the issuer that is responsible for the payment of the debt of the cardholder.
               
               

            4. Acquirer: This is a financial institution that establishes an account with a merchant and processes payment card authorizations and payments. Merchants will usually accept more than one credit card brand but do not want to deal with multiple bankcard associations or with multiple individual issuers. The acquirer provides authorization to the merchant that a given card account is active and that the proposed purchase does not exceed the credit limit. The acquirer also provides electronic transfer of payments to the merchant's account. Subsequently, the acquirer is reimbursed by the issuer over some sort of payment network for electronic funds transfer.
               
               

            5. Payment Gateway: This is a function operated by the acquirer or a designated third party that processes merchant payment messages. The payment gateway interfaces between SET and the existing bankcard payment networks for authorization and payment functions. The merchant exchanges SET messages with the payment gateway over the Internet, while the payment gateway has some direct or network connection to the acquirer's financial processing system.
               
               

            6. Certification Authority (CA): This is an entity that is trusted to issue X.509v3 public-key certificates for cardholders, merchants, and payment gateways. The success of SET will depend on the existence of a CA infrastructure available for this purpose. A hierarchy of CAs are used so that participants need not be directly certified by a root authority.
               

            
            
            
            
            

         4. Typical Transaction Events
            
            

            1. The customer opens an account. The customer obtains a credit or debit card account, such as MasterCard or Visa, with a bank that supports electronic payment and SET.
               
               

            2. The customer receives a certificate. After suitable verification of identity, the customer receives an X.509v3 digital certificate, which is signed by the bank. The certificate verifies the customer's RSA public key and its expiration date. It also establishes a relationship, guaranteed by the bank, between the customer's key pair and his or her credit/debit card.
               
               

            3. Merchants have their own certificates. A merchant who accepts a certain brand of card must be in possession of two certificates for two public keys owned by the merchant: one for signing messages, and one for key exchange. The merchant also needs a copy of the payment gateway's public-key certificate.
               
               

            4. The customer makes a purchase. This is a process that may involve the customer first browsing through the merchant's Web site to select items and determine the price. The customer then sends a list of the items to be purchased to the merchant, who returns an order form containing the list of items, their price, a total price, and an order number.
               
               

            5. The merchant is verified. In addition to the order form, the merchant sends a copy of its certificate, so that the customer can verify that he or she is dealing with a valid store.
               
               

            6. The order and payment are sent. The customer sends both order and payment information to the merchant, along with the customer's certificate. The order confirms the purchase of the items in the order form. The payment contains credit card details. The payment information is encrypted in such a way that it cannot be read by the merchant. The customer's certificate enables the merchant to verify the customer.
               
               

            7. The merchant requests payment authorization. The merchant sends the payment information to the payment gateway, requesting authorization that the customer's available credit is sufficient for this purchase.
               
               

            8. The merchant confirms the order. The merchant sends confirmation of the order to the customer.
               
               

            9. The merchant provides the goods or service. The merchant ships the goods or provides the service to the customer.
               
               

            10. The merchant requests payment. This request is sent to the payment gateway, which handles all of the payment processing.
                
                

         5. Dual Signature Feature of SET - The purpose of the dual signature is to link two messages that are intended for two different recipients. In this case, the customer want to send the order information to the merchant and the payment information to the bank. The merchant does not need to know the customer's credit card number, and the bank does not need to know the details of the customer's order. The customer is afforded extra protection in terms of privacy by keeping these two items separate. However, the two items must be linked in a way that can be used to resolve disputes if necessary. The link is needed so that the customer can prove that this payment is intended for this order and not for some other goods or service.

            To see the need for the link, suppose that the customer sends the merchant two messages—a signed order and a signed purchase—and the merchant passes the purchase information to the bank. If the merchant can capture another order from this customer, the merchant could claim that this order goes with the purchase rather than the original order. The linkage prevents this.
            
            

         6. Payment Processing
            
            

            1. Purchase Request - The purchase request exchange consists of four messages: Initiate Request, Initiate Response, Purchase Request, and Purchase Response.  In order to send SET messages to the merchant, the cardholder must have a copy of the certificates of the merchant and the payment gateway. The customer requests the certificates in the Initiate Request message, sent to the merchant. This message includes the brand of the credit card that the customer is using. The message also includes an ID assigned to this request/response pair by the customer and a nonce used to ensure timeliness.  The merchant generates a response and signs it with its private signature key. The response includes the nonce from the customer, another nonce for the customer to return in the next message, and a transaction ID for this purchase transaction. In addition to the signed response, the Initiate Response message includes the merchant's signature certificate and the payment gateway's key exchange certificate.  The cardholder verifies the merchant and gateway certificates by means of their respective CA signatures and then creates the order information and purchase information. The transaction ID assigned by the merchant is placed in both the order and purchase. The order does not contain explicit order data such as the number and price of items. Rather, it contains an order reference generated in the exchange between merchant and customer during the shopping phase before the first SET message. Next, the cardholder prepares the Purchase Request message. For this purpose, the cardholder generates a one-time symmetric encryption key.
               
               

            2. Payment Authorization - During the processing of an order from a cardholder, the merchant authorizes the transaction with the payment gateway. The payment authorization ensures that the transaction was approved by the issuer. This authorization guarantees that the merchant will receive payment; the merchant can therefore provide the services or goods to the customer. The payment authorization exchange consists of two messages: Authorization Request and Authorization response.  Having obtained authorization from the issuer, the payment gateway returns an Authorization Response message to the merchant and finally with the authorization from the gateway, the merchant can provide the goods or service to the customer.
               
               

            3. Payment Capture - To obtain payment, the merchant engages the payment gateway in a payment capture transaction, consisting of a capture request and a capture response message.  For the Capture Request message, the merchant generates, signs, and encrypts a capture request block, which includes the payment amount and the transaction ID. The message also includes the encrypted capture token received earlier (in the Authorization Response) for this transaction, as well as the merchant's signature key and key-exchange key certificates.  When the payment gateway receives the capture request message, it decrypts and verifies the capture request block and decrypts and verifies the capture token block. It then checks for consistency between the capture request and capture token. It then creates a clearing request that is sent to the issuer over the private payment network. This request causes funds to be transferred to the merchant's account.  The gateway then notifies the merchant of payment in a Capture Response message. The message includes a capture response block that the gateway signs and encrypts. The message also includes the gateway's signature key certificate. The merchant software stores the capture response to be used for reconciliation with payment received from the acquirer.
               
               

   3. In-House vs. Outsource
      

      The reason that an online auction service, or any web merchant, would consider outsourcing their security is basically that TCP/IP protocols used throughout the internet was never developed with many useful security features. Now that it's the most widespread protocol in the world, it has become the basis network protocol of everything from private LANs to popular e-commerce sites. As an e-commerce or any other online service business website, security is of the utmost importance.  Thus, with such an undertaking, it may be wise to leave it to the professionals outside your organization.
      
      

      1. Outsourcing

         First and foremost by outsourcing your security needs, you move all the arduous tasks of researching, selecting, implementing, and maintaining the firewall hardware and software. This can save your online business in terms of it salaries and training of security administrators you would need. Other expenses include the costs of compiling periodic security status reports, in addition to the testing and implementation of new firewall software upgrades.  The larger your organization is, however, the less likely you are to rely exclusively on outsourcing services for your network's security. In part, this is because a larger company likely has it personnel in place already, and security is one of their ongoing it concerns. If nothing else, an in-house it staff will want to determine which outsourcing service is best for the organization, which requires detailed knowledge of firewalls and how they fit into the company's networking strategy and infrastructure. A security service can help by analyzing the network to determine its security requirements and assist with purchasing and putting the firewall in place.  As for our online auction concerns, although the size of Manheim Auto Auction is quite large, they lack the administration needed to implement a security for their web services.  
         
         

      2. In-House

         As you might expect, there are valid arguments against outsourcing. The main concern is the issue of control. By outsourcing a websites network security, you are placing it in the hands of it people who not only aren't part of your company, but who are, in fact, working with other companies as well (possibly competitors). A related aspect is the diminishment of in-house expertise. For many this relief is a major selling point in favor of outsourcing, but many others feel it remains the responsibility of the organizations IT department.  A final argument against outsourcing is the cost. First of all, as technology continues to drop in price, one should recognize this fact when determining the monthly fees necessary to pay for a security service. Second, once a strong firewall solution is in place, there's not much to do.  There may very well be a balance between the higher initial costs of in-house services versus the continued costs of outsourcing.
         
         

      3. Outsourcing Services

         As the growth of outsourcing companies is explosive, it is no wonder that this pressure on the markets have reduced overall costs while increasing security options.  An example of such company that offers such services are:  IBM Global Services, which has a "Security and Privacy Assessments and Planning" package provides analysis of your network's security needs, workshops on security and privacy, and even ethical hacking (where the outsourcing service simulates intrusion attacks). Another package from IBM, "Security and Privacy Architecture and Design," helps your organization develop security policies and processes and put together a detailed plan for your company's Internet security.  ICS Network Systems, for example, offers network consultation at whatever level you require. The company's firewall service is called Network Sentry, and it's available in three configurations based on the number of simultaneous Internet connections your network handles, uses firewall hardware and software from Cisco, and monthly charges range from $845 for a 36-month, 16-connection contract to $1,970 for a 12-month, 16,000-connection contract. The contract includes monthly security reports and upgrades to the firewall as they become available. ICS offers other services including virus protection, should you want them.  There are also many other choices, including services from Genuity, Sprint, and Verio. 

    

9. Case Study - 
   
   Excerpted from an article by Ken Gordon, a senior producer at Simon & Schuster Interactive in New York.  This is in regards to his study of CNN.com's entrance into the webcasting industry.

CNN is one of the largest purveyors of streaming video on the Web. CNN Interactive's Web sites-which include CNN.com, CNNfn.com, CNNSI.com, and multiple international affiliates-generated over 6.7 billion page impressions last year. CNN Interactive produces between 20 and 25 hours of streaming video content a day, on average-and that number keeps growing.

To find out how CNN Interactive accomplishes this Herculean task, I talked to Bruce Cox, the director of software development for its multimedia division. Cox has been at CNN Interactive since its inception about five years ago-a lifetime in Net years. Back then, CD-ROMs were the king of new media and all the old media and publishing conglomerates were trying to get in on the act, spawning interactive subsidiaries like rabbits. Turner was no exception-he originally launched CNN Interactive to develop and publish CD-ROMs such as the Time Capsule series and Faces of Conflict.

At the time, according to Cox, they "hired one person to sit in the corner and handle this new Internet fad, and we were going to just have him do that until the fad went away. Within six months, he turned into over a hundred people. We realized that there was probably more future in the Internet than in CD-ROMs." They've been growing ever since, and now have some 350 people in the CNN Interactive division, expecting to grow to more than 600 in another year.

Cox is quick to point out that the system CNN Interactive uses to edit and process its streaming video is far from ideal. Parts of it are outdated, while other components are more powerful than necessary and are underutilized. But it works-and when you're as big as CNN, you pretty much have to beat your own path through the woods.

Most streaming video you see on CNN.com starts its journey to your desktop on foot: A CNN Interactive video editor walks over to CNN Media Central at the CNN Broadcast Center in Atlanta and pulls a Beta-format tape off a shelf. Media Central is just what it sounds like-the central tape archive for all of CNN, the mother ship.

Each tape contains one package, a raw or edited piece of video footage pertaining to a particular subject or event. The editor then walks the tape back to CNN Interactive's news center and captures the package on one of several Media 100 editing pods. The package is then edited down to two or three minutes, depending on where on the site it's going to be used. Pretty much every- thing is recut for the Web-even footage from shows such as Larry King Live and Crossfire is tweaked a bit. CNN.com's logo is added, along with new captions in larger fonts that are legible when shrunk and compressed.

Once the video has been edited, information is entered into CNN Interactive's VideoSelect tool, which manages all of its streaming media files. This information includes keywords, a category description, and a slug name-a short identifying tag for the clip. Now the package is complete and ready for encoding, and here's where it gets interesting.

CNN Interactive uses a custom-designed live-capture system that encodes five different streaming media files in a single pass. This is accomplished by taking an analog feed out of the Media 100, then splitting it five ways to separate PCs: two for RealNetworks streams and two for Windows Media at 28kbps and 80kbps data rates. The fifth machine creates an AVI file that's converted separately to QuickTime. All render at a frame size of 176x132 pixels.

For live encoding in Real, says Cox, "We're using a slightly modified version of RealProducer Pro. We required more automation control than the standard product, so we asked RealNetworks to make a few additions for us. For live Windows Media encoding, we're using the standard Microsoft Windows Media Encoder." A custom wrapper is used to enable what Cox describes as a "multicasted CORBA event." By triggering this event, the editor can simultaneously start playback on the Media 100 and record on the five encoding machines. Once the editor stops the live capture, the encoded files are automatically uploaded to CNN Interactive's RealNetworks and Windows Media servers, where they are now available for publishing.

The AVI file takes a slightly more circuitous route in order to get converted to QuickTime and served to the Web editors. As Cox describes it, "After the AVI file is captured at one of our capture stations, it's transferred to what we call our 'mini render farm.' The AVI enters a queue, where it is picked up by one of our custom in-house processing tools. This tool includes automated management features, scene detection capabilities, reporting, and monitoring.

"It also controls the functions of Terran Interactive's Media Cleaner Pro software, which is used to produce a variety of QuickTime formats. Once Media Cleaner has processed the AVI into the multiple versions of streaming QuickTime, our management software transfers the finished movie to InterVu's QuickTime servers. The entire process is completely automated from the moment the video editor stops playing the video to our capture stations." InterVu is a San Diego-based video streaming service provider whose other clients include CNET, Excite@Home, NBC, and Quokka Sports. It was just acquired by Akamai.

Live events are handled slightly differently. CNN Interactive occasionally serves up live streams for big events, which are also outsourced to InterVu. I recently watched Hillary Clinton formally announce her Senate candidacy in a 28kbps Windows Media stream through my dial-up connection-live on CNN.com. Well, it was sort of live, at least lagging three-and-a-half minutes behind what was on CNN television. Through InterVu, CNN Interactive has the capacity to stream up to six live events simultaneously, in the same five media formats and data rates as its video-on-demand offerings.

CNN Interactive also captures live events like the First Lady's announcement directly to the Media 100s, where they can be cut, encoded, and served up later as video-on-demand. Cox says this results in a higher quality video stream than if they merely archived the live streaming versions. It also saves another trip over to CNN Media Central for the tape. Occasionally, Cox says, "If we know the duration of a live event, and it's short enough to process live, we will capture it directly to our RealNetworks and Windows Media live encoders. That way, as soon as the event is through, we can have the media on our Web site. For us, it's all about getting the news out as fast as technology permits." (For QuickTime, the AVI is captured live as well, then processed as described previously.)

It's not the most elegant or state-of-the-art system, but it gets an enormous job done extremely quickly. And in the news business, speed is paramount. CNN's editing pods are staffed in two shifts in order to keep up with demand. Cox offers this assessment: "Overall, it's a great system that was developed in-house by four talented developers. It wasn't our first choice to go from analog to digital, back to analog, and then digital again, but it was the only way at the time to process the video quickly enough."

Once on the servers, the files appear on a custom intranet Web page that shows all the video clips available. From here, Web editors can retrieve a small HTML clip- ping that links directly to a video and embeds it into a story. Often, since it takes longer to produce the videos than it does to create the Web pages, the page will go up first without the video, then the editor will go back and add the video links later.

The video files are also available for a host of other uses, on CNN.com and off. For instance, the internal VideoSelect file management system also lends its name to a part of CNN.com where users can browse a selection of current top stories and clips from shows such as Larry King Live and Crossfire. The files are also used by CNN Interactive's numerous partners, including Apple's QuickTime TV site and RealNetworks' RealGuide channels. Every 15 minutes, in an entirely automated process, a script occurs that creates custom Web pages for these partners. For example, links to the three top stories and maybe the first few minutes of Headline News are pulled and formatted to the appropriate specifications of the given partner's customer profile-SMIL in the case of RealNetworks and Flash for QuickTime TV.

As for archiving, CNN Interactive currently saves only its Windows Media files. A separate page on the site-called the Video Vault-offers the last seven days' worth of Windows Media clips to the public. Beyond that, the files are rarely, if ever, reused. That means that if a story ever comes up again, someone will have to walk back over to CNN Media Central and repeat the encoding process. Fortunately, this is a relatively rare event, according to Cox.

Cox's software development group also maintains something called the Multimedia Showcase, which Cox describes as the technology research section of the site. Here, they test new technologies to see how people react to them-how well they're adopted and how easy they are to use-before incorporating them as regular features of the site. These currently include a few interactive Shockwave and Flash games and presentations, iPix panoramas, and 3D VRML animations, such as "Navigate a Hurricane." It's worth noting that it was in a section like this where CNN.com first started using streaming video.

CNN is also in the midst of developing an ambitious unified digital archive in conjunction with Sony and IBM. Once in place, all of the CNN units, broadcast and online, will draw from the same digital files-which should eliminate many of the redundancies inherent in the current system. (If nothing else, it should save a lot of walking back and forth to Media Central.)

In tandem with CNN's development of a consolidated, digital video archive, CNN Interactive is also in the process of eliminating its analog-to-digital-to-analog-to-digital encoding system. According to Cox, "We're currently in the final stages of redesigning the system so that everything stays digital all the way so we can achieve the best possible quality in a faster-than-realtime process."

Going all-digital is presenting some new challenges, as well. For instance, in spite of its quirks, the current system is very light on CNN's data network. By editing from tape and encoding in realtime on separate machines, the vast bulk of the video data is kept off the servers-only the final, compressed files touch the network. Pushing all of the video through the network is proving to be one of the toughest challenges of the redesign.

Says Cox, "Probably the most difficult task right now is coming up with a high-speed network and storage solution to move these huge files around. Since we're moving away from the live encoding infrastructure and moving to more of a video file-based encoding system, we have a huge infrastructure we need to build for moving giant files around, and so far we seem to be right on the edge of what's possible."

CNN Interactive will also be doing away with its Media 100s. Cox says, "It's a broadcast-level editing system, and it's much more than we need for the Internet. We're investigating moving to a smaller frame size for editing, like 320x240-something between a consumer- level and a professional-level editing system." He adds that a primary goal for the new system, just as it was with the last, is turnaround time. The smaller frame size translates directly to smaller file sizes and faster encoding times.

Another goal for the new system is scalability. CNN.com is already the only news site to serve up streaming video in QuickTime, Real, and Windows Media, but even that isn't enough. Cox says CNN.com is getting special requests weekly from a variety of broadband partners, and he wants the new system to be able to serve whatever needs may arise in the next two years-namely, broadband data rates and frame sizes. "The new rendering system will be capable of producing all of these formats at any frame size or data rate required. We're confident that this will be the most advanced streaming media production system in the broadcast industry." He expects it to be complete by the end of the year.

Scalability doesn't just mean broadband support. CNN Interactive already serves up content to pagers, cell phones, and even touchscreen pay phones at the new Hong Kong International Airport. Right now, this is mostly text, but Cox envisions video turning up in these places as well. "There's a whole new market that's breaking away from traditional broadcast, and the goal of our new system is to be able to produce any format we need in the future at any data rate or frame size, as quickly as possible."

9. Concluding Issues - 
   
   
   As with any emerging technology, webcasting will have many issues as it is implemented in the world wide web and more appropriately as an online auction tool.  In one sense, the current quality of webcasts should increase as PC processors become faster and faster to encode and decode at the necessary speeds.  On the other hand, according to WebVideo.com, we would require a doubling of throughput for cable modems and DSL connections every year for the next seven years to obtain a video quality equal to that of current broadcast standards.  Moreover, there will be major dilemmas when millions of end users attempt to simultaneously log onto a site and create massive bandwidth bottlenecks.  This leads to the conclusion that the future of webcasting, although promising, is yet to be seen.  Although webcasting quality is increasing at a dramatic rate, it may not be up the standard necessary to convince a car dealer to purchase a $35 thousand automobile over the internet.  Whereas the security issue concerning such large transactions is relatively simple to implement, one may have difficulty convincing customers that their transactions are actually secure.  Bear in mind that these considerations do not necessarily mean that the idea of an online webcasting car auction is not viable, it simply presents the long road ahead for webcasting on the large scale.  With the work of webcasters, the intrigue of the automotive industry, and the entrepreneurship of new dealers, though, the concept may only be a few short years away  from substantial implementation.
   
   

10. Bibliography
    
    A detailed bibliography can be found at:
    
    http://www.homepage.villanova.edu/douglas.martindale/bibliography.htm

Footnotes:

SCSI Interfaces

The Three electrical levels of SCSI:
SE = Single Ended
HVD SCSI or Differential SCSI = High voltage differential SCSI, based on EIA485
LVD SCSI = Low voltage differential SCSI

Source: Paul Aloisi, Texas Instruments; March 2000

The storage of preference in Internet servers, Servers, workstations and High end PCs. Ultra320 is only the next step, future steps are planned as the performance of the disk drives improve. SCSI started as a narrow bus (50 pin connector) transferring one byte at a time and grew into a wide bus (68 or 80 pin connector) transferring 2 bytes at a time in SCSI-3 SPI. LVD SCSI was added in SPI-2 allowing high speed transfers with a growth plan. SCSI is basically following the rules of Moore's Law doubling performance with each generation. SPI-3 added packetized SCSI that reduces the protocol overhead. The 80 pin SCA-2 connector integrates power and signal for hot plugging SCSI devices into backplanes. They should only be used on backplane systems. SCSI connects the generations; all 7 generations can run on the same logical bus. Expanders Isolate the high speed LVD SCSI bus from the slower single ended or HVD bus segment. Fibre channel and Infinaband make good connection systems for connecting SCSI RAID (Redundant array of independent disks) boxes or JBODs (Just a box of Disks) to systems. SCSI arrays are used in the SAN. These are not competing interfaces, but ways of improving the connections to the SCSI devices and SCSI arrays. Plan your storage future around SCSI and allow it to grow as the technology grows. SCSI offers the lowest cost interface for the high performance disk drives.

Benchmark Information 

Each server in this roundup had 512MB of RAM and a single Pentium III/733 processor on a dual-processor–capable motherboard. We also asked for at least five hard drives configured in a RAID 5 array (four drives in the RAID array, the other for the OS and pagefile with a 16K stripe size).

WebBench 3.0 lets us measure the performance of Web servers as they handle requests from clients. We used the dynamic test suite running Internet Server API (ISAPI) dynamic link libraries. We set up the WebBench tests by loading the content files onto the four-drive array. We set the performance option and file and print sharing to be optimized for applications. We turned the IIS logging and visit logs and set their performance to 100,000-plus hits a day. The site was not indexed; there was no application protection on static content directory, and the CGI-BiN directory was set as a virtual directory for dynamic content.

NetBench 6.0 measures how well a file server handles file I/O requests from 32-bit Windows systems. The clients pelt the server with requests for network file operations. Each client tallies how many bytes of data it moves to and from the server and how long the process takes. The client uses this information to calculate its throughput for the test mix. NetBench adds all the client throughputs together to produce the server's overall throughput in megabits per second. We set the test program's performance option to background services, with file and print sharing optimized for file sharing.

Understanding the Keynote Streaming Scale

Stream Quality: Stream quality is a combined score that incorporates the playback quality of the audio portion of the stream, the playback quality of video portion of the stream and is weighted based on the type of encoding used on the original content. The higher the quality captured by the original encoding the higher the attainable score will be. This is very similar to a difficulty multiplier in certain sporting events such as diving. Rendering Score: The rendering score is based on playback quality of the stream being measured. The type of encoding is not used in calculating the Rendering Score. Audio and video rendering are equally weighted if both are present. For audio only sites the rendering score is based solely on the rendering of the audio. Availability: Stream availability is measured by dividing the number of streams which were successfully rendered by the Streaming Perspective agents by the number of times the computers attempted to retrieve the stream.

The Keynote Streaming Media Performance Index is the average overall quality rating of streaming media content from important Web Sites as measured Sunday through Saturday for 1 minute every hour between 5 am and 9 pm Pacific time by those Keynote Streaming Perspective measurement computers that are located in 10 metropolitan areas of the United States.

Performance Testing Security Tools - Excerpted from an article in PC Magazine June 5, 2000

We focused our testing on three areas—ability to protect the system successfully and degradation of Internet throughput and system performance caused by the security tool's overhead. To test security, we created a highly vulnerable system that had Windows File Sharing, Personal Web Server, Quake Server, and Symantec's PCAnywhere enabled. We ran WebTrends Security Analyzer (www .webtrends .com) and ag Group's Etherpeek network traffic and protocol analyzer (www.aggroup.com). We were pleased to find that all of the packages in our roundup either properly identified system vulnerabilities during installation or prompted for user interaction when probed.

To test system degradation, we used Ganymede Software's Chariot network performance–testing tool (www.ganymede.com). We configured Chariot to measure throughput and response time using five network protocol scripts: http Text, FTP (Put and Get), File Send—long connection, and SMTP. http Text emulates the traffic of an http text transfer, using buffer-size values found in today's browser/server environments. We used FTP scripts to transfer a 100,000-byte file. Although these scripts include the requests for log-on, password authentication, and "transfer complete" acknowledgement, only file transfers are included in the timing. The File Send, long-connection transaction emulates sending of a file between the two endpoints and waiting for a confirmation using a long connection. A long connection uses a single connection for all transactions in a test script. The smtp script simulates the sending of e-mail messages of 1,000 bytes each, with 20-byte headers.

None of the products showed noticeable performance degradation in Internet throughput. We noticed dramatically different patterns, however, in traffic management with Norton Internet Security. Other products handled the incoming simultaneous mix of protocols the same way our reference machine did, whereas Norton prioritized the protocols and distributed bandwidth accordingly. We saw dramatic increases in bandwidth allocation for File Send and FTP protocols. Since the overall bandwidth wasn't affected, this finding did not influence our overall rating.

The second performance-related concern was overhead introduced to the local system by the tested products. We ran Ziff Davis's Business Winstone 99 as well as WinBench 99 to determine strain on CPU and overall system performance. We saw insignificant variances: 2 percent on CPU mark 99 and 8 percent on Business Winstone 99.