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

RTTpP /2.1

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.