[e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic

[Lachlan Andrew]

Greetings Detlef,

On 2 February 2012 22:51, Detlef Bosau <detlef.bosau at web.de> wrote:
> On 02/01/2012 11:20 PM, Daniel Havey wrote:
>>
>> For instance we were talking about delay.  Lachlan said, something to the
>> effect of Cubic causes large delays.  I don't think it does.
>
> Unfortunately, I don't see Lachlan's post yet. However, what shall be the
> reason for the delay? It's hardly a propagation delay on the path, neither a
> serialization delay, which may cause grief here. If ever, the problem is
> likely to be caused by queuing delays. Do you agree here?

That post was ages ago, before Mirja reopened the thread.  Yes, it was
saying that CUBIC induces excessive queueing delays.

>>  I see TCP as a control system with a delayed feedback loop.
>
> This is an always interesting analogy - however, at least to me, not a very
> helpful one.

It isn't an analogy.  Congestion control *is* a control system.  It is
just not a simple one, and all tractable analyses have to model it as
something much simpler than it is.

>> The feedback is an ACK or a dupAck.  How quickly a TCP reacts is
>> completely dependent on RTT (how long it takes for the feedback signal to
>> return to the sender).  If I send a packet and it is lost, I will not know
>> it until the ACK from the next packet reaches me.
>
> Exactly. And if you introduce queuing delay into the network, you will slow
> down the reaction significantly.

No.  With loss-based TCP, the feedback delay is of the order of the
interval between packet losses, which is very much larger than the
RTT.  (To see why that is the feedback delay, consider how the network
signals "increase your rate"; it has to withhold the next expected
packet loss.)  Although increasing queueing delays makes the RTT much
higher, algorithms like CUBIC actually make the feedback delay much
less, by causing more frequent losses.

A better solution is provided by Compound TCP, which doesn't wait for
losses.  By monitoring the delay, it  does  get feedback on the
fastest possible timescale (an RTT).  It doesn't need to increase the
loss rate in order to allow responses to congestion.  However, it does
still take a long time to converge to a fair rate, because the
underlying loss-based CWND still only responds on the same timescale
as Reno does.  In my understanding, Compound is a strict improvement
over Reno when there is one big flow (long-lasting and high-BDP)
sharing with occasional cross-traffic, but reverts to Reno when there
are just two or more big flows, if the buffers are large.  In
contrast, in all cases, CUBIC has some benefits (mostly for the flow
deploying CUBIC) and some drawbacks (mostly for the cross traffic)
over Reno.

Cheers,
Lachlan

-- 
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew>
Ph +61 3 9214 4837