The Transport Layer: User Datagram Protocol CS7025: Network Technologies and Server Side Programming http://www.scss.tcd.ie/~luzs/t/cs7025/ Lecturer: Saturnino Luz April 4, 2011 The UDP All applications make use of either or both of two protocols existing on the transport layer: TCP UDP We have looked at TCP (Transport Control Protocol) We will now look at UDP (User Datagram Protocol) Application Transport Network (internet) Link Physical Services Provided by Internet Transport Protocols Transmission Control Protocol Service: connection-oriented: setup required between client and server reliable transport between sending and receiving process flow control: sender wont overwhelm receiver congestion control: throttle sender when network overloaded does not provide: timing, minimum bandwidth guarantees We use it for getting web pages, email file transfer reliable transport of data basically where we need 1
Services Provided by Internet Transport Protocols User Datagram Protocol Service: unreliable data transfer between sending and receiving process does not provide: connection setup, reliability, flow control, congestion control, timing, or bandwidth guarantee best effort service, UDP segments may be: lost delivered out of order to application Q: Why bother? Why is there a UDP? A: Basically because its very simple No connection state at sender, receiver No receive/send buffers No Congestion control parameters No Sequence, acknowledgement parameters Useful where real time delivery is required - multimedia Networked Multimedia Well roughly divide the content we send over a network into two types: Static: (we use TCP for these) We have to wait for the file and any interlinked files to download fully before we can use them. i.e. web pages we download including any images, applets and animations we embed in them. Often moderate delays for full download Continuous: (generally we use UDP for these) Real-time audio-visual content - begins to play as soon as it arrives - viewer/listener can issue control commands and stream of content should quickly change accordingly. i.e. Interactive Film/TV, Streaming audio/video, real time games over the Internet Characteristics of Continuous Media Highly sensitive to delay: since they are playing out in real time Packet Loss tolerant: necessary since delay is currently unavoidable on the Internet Sometimes adaptive to network conditions - Real Networks surestream technology Content Delay Sensitive Loss tolerant Adaptive Static No No No Continuous Yes Yes Sometimes 2
3 Types of Continuous Media: 1. Streaming Individual clients request audio/video files from media servers Interactive: user can control operation (similar to VCR: pause, resume, fast forward, rewind, etc.) Delay: from client request to programme starts can be 1 10 seconds Packet delay and packet jitter can be eliminated by buffering 2. Unidirectional Real-Time: Similar to TV and radio stations, but delivered over the network. Non-interactive, just listen/view Packet delay and packet jitter can be eliminated by buffering Typically, many listeners to the same stream Can be efficiently transmitted using multicasting, however this is not widely implemented on the Internet 3. Interactive Real-Time : Challenges I Phone conversation or a video conference More stringent delay requirement than Streaming and Unidirectional because of real-time nature Video: < 150 msec acceptable Audio: < 150 msec good, <400 msec acceptable TCP/UDP/IP suite provides no guarantees on packet delay, or variance of packet delay For Streaming applications a delay of 5 to 10 seconds is typical and has been acceptable, but performance deteriorates if routers are congested. Real-Time Interactive applications have been less successful than stored streamed video Can tolerate only limited packet delay and packet jitter Packet jitter: variability of packet delay within a packet stream - caused by later packets arriving at routers where queues may have built up - earlier packets may have got through without much delay If there is light traffic - jitter and delay is minimal - but as soon as traffic increases - delay and jitter increases 3
Challenges II Recall routers on the internet These are store and forward mechanisms. As each packet arrives in a router, the routers examines the packets destination address, then decides the next hop for the packet. However the packet may need to be put in a queue because other packets may be there before it Challenges III Most router implementations use only First Come First Serve packet processing and transmission scheduling Packets from static applications treated the same as packets from continuous media applications All packets are equal: Join the queue and wait your turn To mitigate the impact of such protocols that provide no guarantees of service, we can: Use UDP to avoid TCP and its congestion control mechanism TCPs congestion control will kill real time interactive application Buffer content at client and control playback to remedy jitter Timestamp packets at the sender so receiver knows when to play them Pre-fetch data during playback Adapt compression level to available bandwidth Send redundant information in order to mitigate packet loss 4
Solution Approaches in IP Networks No Change of Protocol: Just add more bandwidth and enhance caching capabilities (over-provisioning) Major change of protocol Incorporate resource reservation (bandwidth, processing, buffering), and new scheduling policies. Set up service level agreements with applications, monitor and enforce the agreements, charge accordingly Moderate change of protocol ( Differentiated Services ): Use two traffic classes for all packets and differentiate service accordingly Charge based on class of packets Network capacity is provided to ensure first class packets incur no significant delay at routers Streaming Important and growing application due to Reduction of storage costs (Vast amounts of media can be stored centrally on media servers) Increase in high speed network access to homes. Enhancements to caching facilities Introduction of QoS in IP networks (in the US generally) Streaming: Audio/Video file is segmented. Segments encapsulated with headers defined for audio/video traffic Streaming II Public segmentation protocol: Real-Time Protocol (RTP) The RTP segments are then sent over either TCP or UDP; User interactive control is provided, e.g. the public protocol Real Time Streaming Protocol (RTSP) Helper Application: displays content, which is typically requested via a Web browser; eg RealPlayer. Typical functions of helper application: Decompression Jitter removal -uses buffering Error correction: use redundant packets for reconstruction of original stream in case of loss/ or request missing packets GUI for user control 5
Delivering Media from Web Servers I Audio: in files sent as HTTP objects Video (interleaved audio and images in one file, or two separate files and client synchronizes the display) sent as HTTP object(s) A simple architecture is to have the Browser request the object(s) and after their reception pass them to the player for display Full download necessary for playback No streaming Simple Architecture 1. The browser process establishes a TCP connection with the Web server and requests the audio/video file with an HTTP request message 2. The Web server sends the audio/video file to the browser in an HTTP response message 3. The content-type: header line in the HTTP response message indicates a specific audio/video encoding 4. The client browser examines the content-type of the response message, launches the associated media player, and passes the file to the media player 5. The media player then plays the audio/video file Drawback: browser acts as an intermediary and a full download is required before file begins to play Delivering Media From Web Servers II Alternative: set up connection between server and player, then download Web browser requests and receives a Meta File (a file describing the object) instead of receiving the file itself; browser launches the appropriate Player and passes it the Meta File; Player then sets up a TCP connection with Web Server and downloads the file 6
Streaming From a Web Server 1. The user clicks on a hyperlink for an audio/video file 2. The hyperlink points to a meta file. The meta file contains the URL of the actual audio/video file. The HTTP response message that encapsulates the meta file includes a content-type: header line that indicates the specific audio/video application 3. The client browser examines the content-type header line of the response message, launches the associated media player, and passes the entity body of the response message (i.e., the meta file) to the media player 4. The media player sets up a TCP connection directly with the HTTP server. The media player sends an HTTP request message for the audio/video file into the TCP connection. 5. The audio/video file is sent within an HTTP response message to the media player. The media player streams out the audio/video file NOTE: Acquiring the meta file allows the media player contact the server directly HTTP Just Not Suited to Streaming However, we are still using HTTP to send the file The player can start to play back before full download but it is not a robust solution: Doesnt allow client interactivity: pause, stop etc Doesnt allow synchronisation between parallel clips since it doesnt allow feedback to the server The server doesnt receive feedback from the player about changing network conditions so no stream adaptation can take place either Using a Streaming Server This gets us around HTTP, allows a choice of UDP vs. TCP and the application layer protocol can be better tailored to Streaming; many enhancements option are possible (see next slide) Requires two servers - HTTP server and a Streaming Server (The media player and the streaming server could use a public protocol such as RTSP). 7
Using a Streaming Server - Options Use UDP: Server sends at a rate (Compression and Transmission) appropriate for client; sends at a fill rate equal to the client drain rate To reduce jitter, Player buffers initially for 2-5 seconds, then starts playback. Buffered media placed in client buffer. Once the client has pre-fetched a few seconds of the media, it begins to drain the buffer - Again, fill rate equals drain rate, except where packet delay occurs- fill rate drops below drain rate at this point When packet loss is detected - the player may request the lost packet or use error correction mechanisms to fill the gap Streaming Server Options We could also use TCP: Server sends at maximum possible rate under TCP; retransmit when error is encountered; Player uses a much larger buffer to smooth delivery rate of TCP TCPs congestion management mechanism will mean that arrival of TCP packets will drop off suddenly once congestion is encountered on the network. Thus the fill rate will become much smaller than drain rate. And disruption to the playing of the media file will occur Real Networks Example Real Networks use streaming server technology, UDP, TCP and RTSP (Real Time Streaming Protocol) Note: The metafile is downloaded from a separate server process running on Real Server, so we dont need a separate web server. 1. A visitor browses a Web page and clicks a link to a streaming media presentation served by RealServer 2. RealServer creates a small metafile and sends it to the visitor s Web browser 3. The browser downloads the metafile (Ram file) and sends it to the visitor s RealPlayer 4. RealPlayer reads the link in the metafile and requests the presentation directly from RealServer 5. RealServer streams the files in the presentation to the RealPlayer 8
Real Player As the user clicks a link that points to a RealServer presentation, RealPlayer opens a two-way connection with RealServer This connection uses TCP to send control information back and forth between RealPlayer and RealServer Initial TPC Control connection UDP Data Connection Real Time Streaming Protocol (RTSP) Real Networks uses the TCP connection to send control information back and forth between the player and the server The protocol it uses for this is RTSP This control information is separate from the media segments which are being sent on the UDP channel Recall that the address of the media file is given in the meta file which is passed to the player by the browser RTSP - What it Doesnt Do Doesnt define compression schemes Doesnt define how audio and video is encapsulated in packets for transmission over a network - the Real Time Protocol (RTP) does that It does not restrict how the streamed media is transported, it can be transported over UDP or TCP Has nothing to do with buffering specifications 9
Real Time Streaming Protocol (RTSP) It does allow the player control the transmission of the media stream RTSP Protocol defines the messages used to allow user to have real time interaction with playback control playback: rewind, fast forward, pause, resume, etc Out-of-band protocol: control messages are sent in a separate band (channel) whereas the media stream whose packet structure is defined by RTP are sent in another band. As before, meta file is communicated to web browser which then launches the Player Player sets up an RTSP connection for control messages in addition to the connection for the streaming media RTSP Operation Browser requests a meta file from the web server The meta file can have references to several continuous media files The metafile on the following slide has reference to a video file and an audio file which are to be played in synch. The player can choose between a hi-fi or lo-fi option Meta File Example: SMIL XML based markup language: <title>twister</title> <session> <group language=en lipsync> <switch> <track type=audio e="pcmu/8000/1" src=rtsp://audio.example.com/twister/audio.en/lofi"> <track type=audio e = "DVI4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.example.com/twister/audio.en/hifi"> 10
</switch> <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> </group> </session> RTSP Exchange Example Client: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=play Server: RTSP/1.0 200 1 OK Session 4231 Client: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0- Client: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37 Client: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RT- SP/1.0 Session: 4231 Server: 200 3 OK Synchronized Multimedia The metafile example two slides back described synchronized media files The W3 consortium has already produced a simple standard for this using extensible MarkUp Langage (XML) SMIL - Synchronized Multimedia Integration Language Synchronized Multimedia Integration Language files, or SMIL files, are files that coordinate the delivery of several clips. A SMIL file tells the client what clips to play, in what order, and where to show them on the screen. SMIL files can perform basic or sophisticated timing and layout. See tutorials on http://www.w3.org/audiovideo Summary Continuous media are media that are time sensitive HTTP, TCP and IP routing protocols do not provide guarantees for time sensitive media Currently, one solution is to use UDP UDP is a barebones transport layer protocol The media player must be able to deal with delayed and missing packets buffering error correction duplicate packets Streaming involves the real-time delivery and playing out of a media file 11
Streaming server vs Web Server Streaming protocol: RTSP Vs HTTP Synchronized streaming media: SMIL References Comer, D. (2010). Computer networks and internets. Pearson Prentice Hall, 5th edition. Tanenbaum, A. S. and Wetherall, D. J. (2010). Computer Networks. Prentice Hall, Englewood Cliffs, NJ, 5th edition. 12