[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