1 / 24

EE 627 Lecture 11

EE 627 Lecture 11. Review of Last Lecture UDP & Multimedia TCP & UDP Interaction. UDP. Provides multiplexing and demultiplexing of sources. No reliability, flow control, congestion control. Sends data in a burst. Most multimedia applications using UDP. UDP & Multimedia.

natalie-romero
Download Presentation

EE 627 Lecture 11

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. EE 627 Lecture 11 • Review of Last Lecture • UDP & Multimedia • TCP & UDP Interaction

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

  3. UDP & 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

  4. TCP/UDP 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.

  5. UDP Consequences • Most applications today use TCP • Stability of network relies on congestion response of applications • Large scale use of UDP could lead to problems - no congestion response • Large number of multimedia applications expected - move larger amounts of data

  6. Unfairness • When UDP and TCP compete, UDP wins by pushing TCP into congestion

  7. Unfairness - FIFO

  8. Unfairness - WRR

  9. Loss of goodput -FIFO • Packets dropped later in network

  10. Loss of goodput -WRR

  11. Multimedia Delivery • Even when using UDP, applications should respond to congestion end-to-end. • Need to promote “nice” behavior or “TCP-friendly” behavior. • Emerging applications shouldn’t kill the performance of “nice” applications.

  12. TCP-Friendly • Throughput of a TCP connection • Limit flows to TCP-style BW • Don’t know RTT exactly • Why should everyone follow this exactly? • Monitoring individual flows difficult

  13. Equation-based control • Don’t have to respond to congestion exactly like TCP • As long as steady-state BW is about the same • Design a protocol that claims on an average the same BW as TCP • RTT is available to end-host, try to estimate drop probability • Adjust rate based on the BW using the equation

  14. Drop Probability • Don’t want to use instantaneous drop probability - varies too much, noisy. • Use some kind of averaging • Tends to dampen response to congestion • Important to respond quickly in times of heavy congestion • Uses a limited history -remember last 8 events • Weigh the more recent ones higher

  15. Equation-based control • Shown to work well when competing with TCP • Lower variance in flow’s BW than TCP • Fairer distribution than TCP • A little complicated • Spurred a lot of interest in new protocols.

  16. Binomial congestion control • Generalize congestion response • Showed that these protocols are TCP-friendly if l+k = 1, through analysis • Varying l and k, keeping l+k = 1 -- can get multiple protocols.

  17. Binomial Congestion control • Showed that steady-state analysis did not tell the complete picture • Depending on congestion response, the drop rates could be different for different protocols • Could respond to congestion in a TCP-friendly way, but may force TCP do have more drops • Conjecture: RED is better than droptail to make drop probabilities equal across flows

  18. Open Issues • Much interest in this area of research • Not clear at what time scales, a flow needs to be TCP-friendly • clearly steady state analysis not sufficient. • Instantaneous TCP like response not needed. • Other possible mechanisms simpler?

  19. Other Mechanisms • Multiple connections - seem to respond to congestion, but claim larger BW. • Used in web browsers • Pricing - make user pay more when sending more bits. Adjust pricing based on congestion.

  20. Rate-based adaptation • Have a notion of allowed rate -adjust rate to avoid congestion - reduce rate before packet loss. • Packet-pair: Send a pair of packets, watch the time separation of acks • The delay between acks gives an indication of bottleneck BW

  21. Packet-pair

  22. Packet-pair Technique • Ack compression leads to incorrect BW estimation. • Timestamp packets on receipt - t1, t2 • Inform sender d = t2 - t1, bottleneck BW = (d)/P, P = size of first packet. • Need to send multiple times and use min d. • Hard to get an estimate of available BW

  23. Packet-pair • With parallel transfers, both packets may arrive simultaneously at the receiver -inflating available BW • Can be improved by sending more packets • Possible to decouple rate adaptation and reliable delivery

  24. Hop-by-Hop • Possible to do flow control hop-by-hop • Send backward pressure to reduce rate when queues are building up • Tough to control individual flows • Every network element need to implement -not just endpoints.

More Related