[Iccrg] incentives for 1/p: I muddled my answer in Stockholm

Bob Briscoe rbriscoe at jungle.bt.co.uk
Mon Aug 3 18:30:51 BST 2009


Folks,

In Stockholm, I said that 1/p congestion controls like Relentless 
ensure that, relative to TCP, there are more congestion signals per 
RTT as flows get faster. This emergent property ensures 
responsiveness scales with speed.

Someone (sorry I didn't see who, as the lights were shining in my 
eyes) asked whether this implied re-ECN and responsiveness 
requirements were pulling in opposite directions; re-ECN gives 
transports the incentive to create less congestion but transports 
require more congestion signals to remain responsive. I'm sorry, I 
gave an answer that was unclear and inconclusive, whereas I could 
have been clear and conclusive...

To be clear, a move to 1/p congestion controls is unaffected by 
incentives to reduce congestion. Why? Because transports have another 
degree of freedom for reducing congestion: the 'weight'. Having 
chosen a weight, using a 1/p control ensures the weight chosen for a 
particular type of session remains correct as capacity scales over 
time and on different paths.

Let's assume the transport converges on an average window W:
         W = w/(p^b)
where
         w: weight (note lower case)
         p: loss fraction (or ECN marking)
         b: responsiveness parameter
b_TCP = 1/2
b_Rel = 1   (Rel: Relentless)

If the transport can set w and b, the transport has more degrees of 
freedom than it needs to alter the number of congestion signals per RTT.

Imagine we start at a time in history where use of TCP leads to just 
enough congestion signals to control most flows passing through most 
bottlenecks (e.g. one signal every few RTTs). The question: what to 
do wherever and whenever faster links are available:

Scenario #1: Stay with TCP (b=1/2):
Over faster links, people will need to increase their w so that TCP 
gets more frequent signals, and can accelerate fast enough to use the 
available capacity while staying controllable (Note: increasing w 
could be hacked at the application layer with multiple TCP flows over 
the same path and a congestion manager).

Scenario #2: Move from TCP to Relentless (b=1):
The first time Relentless is used, it can be set with a low w, but no 
lower than the point where there aren't frequent enough signals for 
responsive control. Then whenever higher or lower speed links are 
encountered, for ever into the distant future, the same w can be used 
for the same type of session.

Summary
-------
Moving from TCP (b=1/2) to Relentless (b=1) doesn't imply more 
congestion than _necessary_ to keep responsiveness, because w can be 
reduced as low as desired.
But once you set b=1 (e.g. Relentless) and you set w as low as 
feasible for a certain type of session, you don't have to configure 
anything ever again. Whereas, if you keep with TCP, you continually 
have to fiddle with the weights to keep it working as links get faster.



Bob



________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research  




More information about the Iccrg mailing list