1 Equation-Based Congestion Control for Unicast Applications Sally Floyd, Mark Handley, Jitendra...

25
1 Equation-Based Congestion Control for Unicast Applications Sally Floyd, Mark Handley, Jitendra Padhye & Jorg Widmer August 2000, ACM SIGCOMM Computer Communication Review, Proceedings of the conference on Applications, Technologies, Architectures, and Protocols for Computer Communication, Volume 30 Issue 4
  • date post

    19-Dec-2015
  • Category

    Documents

  • view

    216
  • download

    0

Transcript of 1 Equation-Based Congestion Control for Unicast Applications Sally Floyd, Mark Handley, Jitendra...

1

Equation-Based Congestion Control for Unicast Applications

Sally Floyd, Mark Handley, Jitendra Padhye & Jorg Widmer

August 2000, ACM SIGCOMM Computer Communication Review, Proceedings of the conference on Applications, Technologies, Architectures, and Protocols for Computer Communication, Volume 30 Issue 4

2

Motivation• Smooth adjustment of sending rate

− Respond to congestion slower and less severe

• TCP-friendly − Coexist

TCP-Friendly Rate Control (TFRC)

3

Outline• Introduction of TFRC• TCP response function• Protocol features• Simulation and experiments• Conclusion

4

TCP-Friendly Rate Control (TFRC)• Equation-based (c.f. window-based of TCP)

− Adjust sending rate according to control equation

− Calculate at sender side with the aid of receiver feedback

• Do not aggressively seek out available bandwidth; increase sending rate slowly in response to a decrease in loss event rate

• Do not halve sending rate upon single loss event; however, do halve in response to several successive loss event

5

TFRC• Advantage:

− Smooth-changing sending rate• Disadvantage:

− Slower response to sudden bandwidth increase

6

TCP response function • T: sending rating (calculated at sender)• s: packet size (known by sender)• R: round trip time (calculated at sender)• tRTO: timeout value, estimated from R

• p: loss event rate (calculated at receiver)

7

TCP response function• SRTT: estimate round trip time

(calculated from receiver feedback)• RTTvar: variance of round trip time

8

TCP response function• p is loss event rate instead of packet

loss rate• loss event can consist of several packet

lost within a round-trip time• loss interval is defined as the number

of packets between loss events• use Average Loss interval method

9

Average Loss Interval method

10

Average Loss Interval method

11

Average Loss Interval method• s0 is the most recent loss interval

• when a loss event occurs, s0 becomes s1 and new s0 becomes zero

• ignore s0 unless s0 is large enough to increase the average

12

History discounting• problem of average loss interval method:

− slow to respond to a sustained decrease in congestion

• when s0 > twice the average loss interval− reduce the weights of older loss intervals

13

TCP response function• If Tactual < Tnew

increase sending rateelse

decrease sending rate

14

Slowstart• Reno increase sending rate by 2 for each

round-trip time• rate-based protocol does not have such a

limitation; to prevent overshoot

• Treceived : rate of packets arrived at receiver

• slowstart terminates upon loss occurs

15

Protocol features• loss fraction vs loss event fraction

− stable steady-state packet loss rate, difference at most 10%

− multiple packet drops is uncommon in RED, but relatively more common in droptail

− difference diminishes if congestion persists

16

Protocol features• increasing transmission rate

− ~0.14 packet/RTT (without history discounting)*

− ~0.22 packet/RTT (with history discounting)*

− no need of explicit control of bursty traffic • response to persistent congestion

− require 4-8 RTT to halve sending rate• response to quiescent senders

*derivation skipped, interested readers may refer to the paper

17

Simulation Results

18

Simulation Results

19

Simulation Results

20

Simulation Results

21

Long background traffic

22

Short background traffic

23

Experiment Results

24

Experiment Results

25

Conclusion• highly varying throughput not suitable

for streaming• TFRC is one of the protocols trying to

cope to it• smoothness and interflow fairness• loss event • do not halve sending rate upon a loss

event• do halve sending rate upon persistent

congestion and more gentle increase in sending rate