Designing TCP-Friendly Window-based Congestion Control for Real-time Multimedia Applications

1. Designing TCP-Friendly Window-based Congestion
Control for Real-time Multimedia Applications
PFLDNeT 2009
Soo-Hyun Choi and Mark Handley
University College London

2. congestion control for
real-time multimedia applications
• Two key common demands
– Timely delivery over perfect reliability
– Smooth and predictable throughput
• Proposed standard: TFRC
– What it solves?
• Smooth and predictable throughput
– How it solved?
• Equation-based sending rate control by modelling TCP
throughput
background

3. problems and goals
• TFRC works incorrectly in certain circumstances
• Fairness
– It could starve TCP traffics at a DSL-like link (especially with a very
small bottleneck buffer)
• Smoothness
– It could generate unwanted throughput oscillation in a short-term
timescale (due to EWMA coeff. when measuring RTT)
• Hard to Implement
– If RTT is smaller than CPU interrupt cycle, it will have to sub-
sample it, which in turn leads a noise in throughput calculation
problems and goals (1/3)

4. fairness
• DSL-like link (low statistical mux), Drop-tail queue
with a tiny bottleneck buffer
– TFRC is sufficiently smooth due to the different fine-grain CC
avoidance mechanism from TCP
problems and goals (2/3)
FIFO
TCP TFRC
Dest.
2 TCP and 2 TFRC
Droptail (5 packets)
Bottleneck link = 1Mb/s

5. smoothness and practical issue
• Short-term oscillatory behaviour
– To avoid this:
• Original TFRC used for inter-packet spacing
• Bansal introduced 'conservative' mode
– Worked well in the simulations, but not so sure in real-world
• Practical issue (uneasiness to implement correctly)
– Saurin observed the regular TFRC cuts inappropriately when
RTT is small (e.g., less than a host OS's interrupt clock
granularity)
problems and goals (3/3)
RTT i
E RTT s

6. motivation (1/2)
Do we have to be rate-based to be smooth?
Is rate-based worth all the trouble?

7. motivation
• Problems with rate-based control
– Fairness
– Hard to implement
• Solution: Smooth Thruput with Ack-clocking
motivation (2/2)
If there is another mean that can achieve
better fairness and make easy to implement
without compromising smoothness, then?

8. TCP-Friendly Window-based
Congestion Control (TFWC)
• Re-introduce TCP-like Ack-clock
– Using a window, it can embed RTT implicit in the Ack-clock
– No need to work around the OS's interrupt timer
• Smoothness, Friendliness, Responsiveness
– By using TCP-equation with the change to Ack-clock can
retain “ Friendliness” and “ Responsiveness” property
– Do we lose “ Smoothness” after all?
proposal

9. window calculation
• Window calculation using TCP-equation
– From the original TCP-equation
– Multiply , then we get window size:
TFWC mechanisms (1/9)
W =
1
2p
3
12
3p
8
 p132p
2

tRTT /s
T =
s
t RTT 2p
3
12
3p
8
 p132p
2


10. loss event rate
• Average Loss Interval
– Weighted average interval of packet losses
• Loss event rate from average loss interval
TFWC mechanisms (2/9)
Loss Event Rate  p=
1
Average Loss Interval

11. Ack Vector
• What is it?
– Data structure for Ack message
– No cumulative Ack numbers (unreliable transport)
• Data receiver builds AckVec
– Packet list indicating the packet has arrived
– Data receiver sends in an acknowledgement
• Data sender reports Ack of Ack (AoA)
– Data receiver prune AckVec based upon AoA
TFWC mechanisms (3/9)

12. Upon receipt of AckVec
• Sender determines which packets are missing:
TFWC mechanisms (4/9)
20 19 18 16 15 14 13 11 10
Latest Ack
AoA
19 18 17
16 15 14 13 12 11
margin to allow
re-ordering
packet loss
Received
AckVec

13. sender functionality
• On every AckVec reception
– Check packet loss
– Compute Average Loss Interval
– Calculate cwnd using the equation
– Send the next available packets if:
– Update RTT and RTO
→ Hence, making it sender driven Ack-clock basis
TFWC mechanisms (5/9)
≤Seqno. of New Data cwnd + Unacked Seqno.

14. hybrid window and rate (1/2)
• When the loss rate is high:
– A packet loss can cause timeout with very small windows due to the Ack-
clock failure
– The equation can result in cwnd less than one, for example.:
• when p > 0.15, then W < 1
• when p > 0.1, then W < 2
• TCP-like timeout method to clock packets out?
– Constant switching between window and timeout???
– Some of them will do exponential back-off, too.
→ TFRC-like rate-based when window is so small (i.e.,
when cwnd is less than 2)
TFWC mechanisms (6/9)

15. hybrid window and rate (2/2)
– One TCP/TFRC/TFWC for the queue size of 5 packets
– 500 Kb/s with 50 ms delay of the bottleneck link
– This is a boarder-line case where it doesn't run rate-driven always.
TFWC mechanisms (7/9)
Window only mode Hybrid mode

16. cwnd jitter (1/2)
• TFWC's throughput often less smooth enough for
interactive streaming applications than that of TFRC
– Phase effect?
• Maybe, yes, as flows through same bottleneck show different loss rate.
– This can be significantly mitigated by RED queue
• Being motivated by RED,
– Randomly add cwnd 'jitter' by inflating cwnd at least once an RTT
– Borrow a “ future” packet that would have been sent in that RTT
• Results:
– Reverses packet phase, hence breaking phase effects
TFWC mechanisms (8/9)

17. cwnd jitter (2/2)
TFWC mechanisms (9/9)
Without jitter With jitter
FIFO
TFWC
Dest.8 TFWCs
5 Mb/s
50 ms
5 Mb/s
50 ms
50 Mb/s
BDP = 63
Drop-tail
Size = BDP

18. Protocol Analysis
Friendliness, Smoothness, Responsiveness
analysis

19. TCP-Friendly (1/2)
• Scenario
– Varying # of sources from 1 to 100 in a dumbbell topology
– Varying bottleneck BW from 0.1 ~ 20 Mb/s with 10ms delay
– Reverse path TCP sources to reveal issues about Ack-
compression and reduce phase effect
– Drop-tail queue with a size of BDP
• Fairness Index (Θ) =
analysis > fairness (1/2)
∑
i =1
n
T tcpi
∑i=1
n
T tcpi
∑j =1
n
T j

20. TCP-Friendly (2/2)
analysis > fairness (2/2)
– For TFRC, Θ ~ 0.1 when bottleneck BW is low
– For TFWC, though it is not perfect, it certainly does a lot better
than TFRC
TCP competing with
the same number of TFRC
TCP competing with
the same number of TFWC

21. smoothness (1/4)
• Scenario
– Are we going to loose all the nice smoothness property by re-
introducing TCP-like Ack-clock?
• Let's plot Coefficient of Variance (CoV).
– Same simulation sets used in fairness comparison cases, and
plot averaged per-flow CoVs
CoV =
analysis > smoothness (1/4)
1
k
∑
i=1
k
Ti − T 2
T
: average throughput over time
k : number of time intervals
(time interval = 0.5 sec)
T

22. smoothness (2/4)
analysis > smoothness (2/4)
– TFRC's CoV is very high (> 0.9) when # of sources is small
– TFWC's CoV is relatively high when bottleneck BW is small
TFRC CoV TFWC CoV

23. smoothness – detailed (3/4)
• Scenario
– 8 TFR(W)C competing with the same # of TCP
– Bottleneck of 5 Mb/s with 20 ms link delay, Drop-tail queue
with a size of 300 packets
– Average cwnd per flow =
– Reverse path TCP sources:
• To reduce simulation phase effect
• To perturb the TFWC Ack flow
analysis > smoothness (3/4)
BDPqueuesize
no.of TCPno of TFWC
≈15 packets

24. smoothness – detailed (4/4)
analysis > smoothness (4/4)
• TCP
• TFRC
• TFWC

25. responsiveness (1/2)
• Scenario
– Stress TCP/TFRC/TFWC with impulse response as a form
of ON/OFF CBR source
• CBR rate is the half of the links speed
– Bottleneck of 1.5 Mb/s with roughly 60 ms of RTT
– Drop-tail queue with arbitrary large queue size
– One CBR source competing with one TFR(W)C
analysis > responsiveness (1/2)

26. responsiveness (2/2)
analysis > responsiveness (2/2)
CBR On CBR Off

27. conclusion
• TFWC achieved providing:
1. Fairer throughput
2. Same level of smoothness with that of TFRC
3. Faster responsiveness
4. Simpler to implement
without bearing all the trouble that a rate-based CC has.
• Future work
– Question on what is really better for such an application
between a rate-based CC and a window-based CC.
– Move to the real-world experiments
conclusion