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

[Detlef Bosau]

On 02/01/2012 11:20 PM, Daniel Havey wrote:
> Hehe ;^)  I agree with Detlef.  We have to be more careful with our terminology, and we have to be specific about the network conditions that we are talking about.
>
> 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?
> Soooo, I have an issue with the term "quickly".

Actually, the term is precisely determined :-)


>   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. (And I well expect criticism by Saverio here. IIRC, 
Saverio did quite a lot of work on analytical models for TCP. However, 
all these analytical discussions which are necessary for doing control 
theoretical considerations, did not yet convince me.)


> 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.  If the packet is received, I should know about it slightly sooner.  This is how quickly a TCP can react to changes in the network.

Exactly. And if you introduce queuing delay into the network, you will 
slow down the reaction significantly.

> I think what Mirja is talking about is the aggressiveness of the response to a feedback signal.  This is determined by the congestion control algorithm.  Cubic tends to be more aggressive than Reno.

And "more aggressive" does not necessarily mean "better".


So, I repeat my statement: We should rather spend some time talking 
about the problem then perhaps waste time talking about appealing 
solutions which are yet to find a problem.

Detlef


-- 

------------------------------------------------------------------
Detlef Bosau
Galileistraße 30	
70565 Stuttgart                            Tel.:   +49 711 5208031
                                            mobile: +49 172 6819937
                                            skype:     detlef.bosau
                                            ICQ:          566129673
detlef.bosau at web.de                     http://www.detlef-bosau.de
------------------------------------------------------------------