1 / 27

689 Lecture 2

689 Lecture 2. Review of Last Lecture Networking basics TCP/UDP review. Multimedia Applications. Video-on-demand Near-video-on-demand Interactive games Teleconferencing IP Telephony Training/Travel videos. Multimedia Requirements. Guarantees over long periods of time

march
Download Presentation

689 Lecture 2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 689 Lecture 2 • Review of Last Lecture • Networking basics • TCP/UDP review

  2. Multimedia Applications • Video-on-demand • Near-video-on-demand • Interactive games • Teleconferencing • IP Telephony • Training/Travel videos

  3. Multimedia Requirements • Guarantees over long periods of time • Throughput guarantees • Audio requires loss/delay guarantees • Interactive apps. Require low delay • Visual Perception allows adaptivity • Audio not as forgiving as video

  4. Multimedia requirements • CBR • VBR • Variable bit rate places extra burden • Systems/devices/network support harder • Adaptive applications compensate for bandwidth/performance degradation and packet losses.

  5. Typical System

  6. Delivering multimedia • Network transport layers responsible

  7. Transport layers • TCP/UDP

  8. TCP • Transport Control Protocol • Reliable In-order delivery • Flow control • Responds to congestion • “Nice” Protocol

  9. TCP Header

  10. TCP flow control • Window based • Sender cannot send more data than a window without acknowledgements. • Window is a minimum of receiver’s buffer and ‘congestion window’. • After a window of data is transmitted, in steady state, acks control sending rate.

  11. Flow control

  12. Flow control • Congestion window is increased gradually • At the beginning, set cwnd = 1 • For each ack, double the cwnd until a threshold • Increase by 1 for a window of acks after that.

  13. Slow Start

  14. Additive Increase

  15. Reliable delivery • Sender, Receiver keep track of bytes sent and bytes received. • Acks have an indication of next byte expected. • Three duplicate acks considered a packet loss - sender retransmits

  16. Reliable Delivery

  17. Congestion Control • Traffic on the network is constantly changing. • Packets may be lost due to transmission errors, switch buffer overflows, receiver buffer overflows. • Packet loss is taken as an indication of congestion.

  18. Congestion Response • TCP reduces sending rate on packet loss • cwnd is halved on a packet loss • cwnd is set to 1 on a timeout • TCP follows -- Multiplicative Decrease and Additive Increase policy for window adjustments

  19. Congestion Response • Queue length reduction takes qudratic time • Multiplicative decrease allows sufficient time to reduce queue lengths -- Jacobson • Jain -- Multiplicative decrease and additive increase allows ‘fair’ sharing of bandwidth. • TCP -- ‘good’ citizen - allows fair sharing, avoids congestion collapse.

  20. Congestion Response

  21. TCP Congestion Response • TCP responds to congestion. • Increases window size until a packet loss • This allows maximization of utilization. • No Congestion avoidance mechanism • Number of Proposals - TCP Vegas -- includes a rate adjustment mechanism based on observed delay.

  22. DECbit • Indicate congestion by setting a bit in the packet. • Receiver echoes the bit to the sender. • Sender adjusts sending rate based on percentage of marked packets. • Avoids congestion before it happens • Reduces the stair-case affect of TCP.

  23. TCP and multimedia • Reliable delivery not needed for multimedia • Timely delivery more important than in-order delivery. • Late packet can be thrown away • TCP’s reliability gets in the way.

  24. UDP • Unreliable Datagram Protocol

  25. UDP • Provides multiplexing and demultiplexing of sources. • No reliability, flow control, congestion control. • Sends data in a burst. • Most multimedia applications using UDP

  26. UDP and multimedia • Put flow control, congestion control into application. • Retransmit if packet deadline not past • Move on if packet deadline is past • Don’t respond to Congestion • Not a “nice” citizen. • Possible to cause congestion collapse.

  27. Summary • TCP not well suited to multimedia. • TCP is a well understood, ‘nice’ protocol. • Multiplicative decrease/additive increase allows fair sharing of BW and avoids congestion collapse. • UDP is being used by multimedia developers.

More Related