1. 1 EE 689 Lecture 3 Review of Last Lecture UDP & Multimedia TCP & UDP Interaction

2. 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. 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. 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. 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. 6 Unfairness When UDP and TCP compete, UDP wins by pushing TCP into congestion

7. 7 Unfairness - FIFO

8. 8 Unfairness - WRR

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

10. 10 Loss of goodput -WRR

11. 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. 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. 13 Other Mechanisms IP-spoofing - make a single flow appear like multiple flows - flow-based schemes fail. Multiple connections - seem to respond to congestion, but claim larger BW. Pricing - make user pay more when sending more bits. Adjust pricing based on congestion.

14. 14 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

15. 15 Packet-pair

16. 16 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

17. 17 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

18. 18 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.