Peter A. Steenkiste, SCS, CMU


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Peter A. Steenkiste, SCS, CMU

  1. 1. Networks and Communication Lecture 11: Endpoint issues Peter Steenkiste School of Computer Science Carnegie Mellon University ECOM, Summer 2000
  2. 2. Outline <ul><li>Other transport protocols. </li></ul><ul><li>Video and audio streaming. </li></ul><ul><li>Application view. </li></ul><ul><li>Endpoint design and performance. </li></ul>
  3. 3. Other Transport Protocols <ul><li>Some applications need a form of reliability, congestion avoidance, or flow control different from that of TCP. </li></ul><ul><ul><li>May not need a 100% reliable transport </li></ul></ul><ul><ul><li>Timeouts or slow down for congestion avoidance may introduce unacceptable delays </li></ul></ul><ul><li>Other transport protocols are often implemented in user space on top of UDP. </li></ul><ul><ul><li>Use the addressing provided by UDP </li></ul></ul><ul><li>Examples: </li></ul><ul><ul><li>Remote procedure calls </li></ul></ul><ul><ul><li>Multimedia </li></ul></ul>
  4. 4. Basic Remote Procedure Call <ul><li>Supports request-response communication model between a client and server. </li></ul><ul><ul><li>Behavior different from streaming data </li></ul></ul><ul><li>Semantics of the well-known procedure call. </li></ul><ul><ul><li>but the procedure is executed on a remote node </li></ul></ul><ul><ul><li>same interface and behavior (when no node failure) </li></ul></ul><ul><li>Properties and design quite different form TCP. </li></ul><ul><ul><li>Reliability is same as TCP but is implemented using simple timeouts </li></ul></ul><ul><ul><li>Flow control is built into the communication model, I.e. one pending request-response at a time </li></ul></ul><ul><ul><li>Congestion control depends on implementation and ranges from none to the use of TCP </li></ul></ul><ul><li>Many variants, asynchronous RPC. </li></ul>
  5. 5. Protocol Properties <ul><li>Response serves as acknowledgement of request. </li></ul><ul><ul><li>probes and busy replies deal with detection of lost requests and responses, and failed servers </li></ul></ul><ul><li>Acknowledgement of response. </li></ul><ul><ul><li>allows server to reclaim resources (buffered response) </li></ul></ul><ul><ul><li>can be piggy backed on next request </li></ul></ul><ul><ul><li>not critical </li></ul></ul><ul><li>Limited amount of data outstanding simplifies protocol processing. </li></ul><ul><ul><li>self-pacing application </li></ul></ul><ul><ul><li>examples: buffer space, congestion control, flow control, .. </li></ul></ul>
  6. 6. RPC Implementation Application Collect Arguments Procedure Execution Receive Unpack Arguments Unpack Result Collect Results Send Application Continues Send Receive Time Space
  7. 7. Streaming Audio and Video Requirements <ul><li>Multimedia applications have real time requirements: samples must arrive in time at the destination to be useful. </li></ul><ul><ul><li>Frames in video stream </li></ul></ul><ul><ul><li>Samples for audio </li></ul></ul><ul><ul><li>Also applies to other data (slides, ..) </li></ul></ul><ul><li>Applies both to stored and live scenarios. </li></ul><ul><ul><li>Stored data is somewhat easier to deal with since it can more easily be “sent ahead” </li></ul></ul><ul><li>Traditionally audio and video have used dedicated networks that provide guaranteed bandwidth. </li></ul><ul><ul><li>Telephone can cable network </li></ul></ul><ul><ul><li>Reservations guarantee timely delivery of data </li></ul></ul>
  8. 8. Playback of Audio/Video <ul><li>Source attaches a timestamp to each sample. </li></ul><ul><li>Receiver uses the timestamp to playback the sample at the right time. </li></ul><ul><li>The playback point corresponds to the delay in the replay relative to the generation of the data. </li></ul><ul><ul><li>Packets that arrive too late have no value and are ignored </li></ul></ul><ul><ul><li>Packets that arrive too early have to be buffered </li></ul></ul>Source Playback
  9. 9. Network Implications <ul><li>What does the data stream look like? </li></ul><ul><ul><li>Constant bit rate: samples of the same size or transmitted periodically, </li></ul></ul><ul><ul><ul><li>audio, uncompressed video </li></ul></ul></ul><ul><ul><li>Variable bit rate: the size of the samples changes over time </li></ul></ul><ul><ul><ul><li>MPEG, motion JPEG, .. </li></ul></ul></ul><ul><li>The samples should be transmitted with predictable delay. </li></ul><ul><ul><li>Change in delay = jitter </li></ul></ul><ul><li>Use of reservations versus making the application adaptive. </li></ul><ul><ul><li>Reservations: next lecture </li></ul></ul>
  10. 10. Transport Protocol Properties <ul><li>Reliability. </li></ul><ul><ul><li>Some lost data is typically acceptable (impact depends on the type of encodingencoding) </li></ul></ul><ul><ul><li>Timeouts typically result in unacceptable delay, and there is often not enough time to retransmit data (live transfers) </li></ul></ul><ul><li>Congestion control. </li></ul><ul><ul><li>Nature of the flow fundamentally limits its bandwidth </li></ul></ul><ul><ul><li>reduction of rate in response to congestion should not be done by sending samples slower but by reduce data size </li></ul></ul><ul><ul><ul><li>E.g. change frame rate or frame size </li></ul></ul></ul><ul><li>Flow control. </li></ul><ul><ul><li>Samples should be paced at the natural rate of the data </li></ul></ul><ul><ul><li>Sending too slow --> underflow and missed deadlines </li></ul></ul><ul><ul><li>Sending too fast --> buffer overflow and lost data </li></ul></ul>
  11. 11. Adaptive Video Streaming Source Playback Feedback <ul><li>Receiver reports dropped packets. </li></ul><ul><li>Sender reduces frame size if loss rate is too high. </li></ul><ul><ul><li>Also uses probing to detect additional bandwidth </li></ul></ul><ul><li>Similar to TCP, except that lost data is typically not retransmitted. </li></ul>
  12. 12. Real-Time Transport Protocol RTP (RFC 1889) <ul><li>Supports the transport of data with real-time characteristics. </li></ul><ul><li>Provides the formatting and synchronization information for the data transfer. </li></ul><ul><ul><li>Data encoding used, timestamps for synchronization, loss rates for used by congestion control protocol, sequence numbers for ordering, ... </li></ul></ul><ul><li>RTP does not guarantee timely data delivery. </li></ul><ul><ul><li>guarantees have to be provided by lower level protocols </li></ul></ul><ul><li>The protocol has two parts. </li></ul><ul><ul><li>Real-time Transport Protocol: carry data </li></ul></ul><ul><ul><li>Real-Time Control protocol: monitor quality, exchange information about participants, .. </li></ul></ul>
  13. 13. Application View <ul><li>Applications send and receive data through sockets. </li></ul><ul><ul><li>Typically: send->write and receive->read </li></ul></ul><ul><ul><li>Socket = large data buffer </li></ul></ul><ul><ul><ul><li>any data written into the buffer socket is then forwarded over the network by the operating system </li></ul></ul></ul><ul><ul><ul><li>any data that is received from the network is placed in the socket buffer where it can be read by the application </li></ul></ul></ul><ul><li>Sockets correspond to the “ports” in the UDP and TCP packet headers. </li></ul><ul><ul><li>The sender has to know the port the receiving application will use to read </li></ul></ul>
  14. 14. Typical Exchange <ul><li>Sender creates and initializes a socket. </li></ul><ul><li>Sender issues an open connection command. </li></ul><ul><ul><li>Specifies destination IP and application port addresses </li></ul></ul><ul><ul><li>Sender blocks while connection is established </li></ul></ul><ul><li>If the connection succeeds, data exchange can start. </li></ul><ul><ul><li>Lots of things can go wrong: wrong addresses, receiver or network down. </li></ul></ul><ul><li>Receiver creates and initializes a socket. </li></ul><ul><li>Receiver listens on the socket for a connection request. </li></ul><ul><ul><li>Can sometimes restrict the type of connection </li></ul></ul><ul><li>If receiver accepts the connection and the connection succeeds, data exchange can start. </li></ul><ul><ul><li>Communication typically uses a different socket </li></ul></ul>
  15. 15. Establishing Communication <ul><li>How does the sender “know” the port of the destination application? Prior agreement. </li></ul><ul><ul><li>Use standardized port numbers (IANA) </li></ul></ul><ul><ul><li>Out of band communication (e.g. telephone call) </li></ul></ul><ul><li>How do servers servers communicate with many applications at the same time? They use separate sockets. </li></ul><ul><ul><li>A new socket is created for every connection </li></ul></ul><ul><ul><li>The original socket is only used for establishing the connection </li></ul></ul><ul><li>How does the operating system know what socket to deliver data to? It keeps a mapping (IP addresses, ports) -> socket. </li></ul>
  16. 16. How Do Hosts Communicate? Hardware Memory Network Interface Disk Controller CPU On-board Device Memory Bus Input/Output Bus Bridge
  17. 17. How Do Hosts Communicate? Software Application Operating System Device Driver Application Presentation Session Transport Network Data link Physical
  18. 18. What Can Limit Endpoint Performance? <ul><li>CPU processing. </li></ul><ul><ul><li>Protocol processing, system calls, interrupts, … </li></ul></ul><ul><ul><li>Also need CPU cycles for the application! </li></ul></ul><ul><ul><li>Most likely to happen for short packets </li></ul></ul><ul><li>Memory bandwidth. </li></ul><ul><ul><li>Packets typically get copied several times, which really stresses the memory system </li></ul></ul><ul><ul><li>Most likely to happen for large packets </li></ul></ul><ul><li>The I/O bus. </li></ul><ul><ul><li>The bandwidth of the I/O bus sometimes limits performance for fast I/O devices </li></ul></ul><ul><ul><li>Many systems today use the PCI bus, which is typically fast enough </li></ul></ul>