Re: [ledbat] Another uTP story by alarmist author

[Richard Bennett <[e-mail]>]

That's a nice analysis of TCP congestion-avoidance mechanisms, Nick, but 
I'm not sure it's any more accurate than my simplification for the mass 
audience. I don't argue that a scavenger class isn't needed, I simply 
express my skepticism for some of the claims that have been made for the 
uTP approach. As you point out, TCP implementations have a number of 
tweaks and variations for congestion avoidance, many of them RTT-based, 
so it's not correct to say that TCP just waits for packet drop to slow 
down. TCP over ECN certainly doesn't, but I've written about that in the 
press previously.

The main concern I have about the uTP approach is that the system is 
simply an endpoint implementation, and endpoints don't have all the 
information about the status is ES-IS and IS-IS links they need for 
assessing a path. A single-product hack has to go on the information it 
has, but an IETF standard can take a larger focus and combine feedback 
from the infrastructure with path selection to get a better answer. As 
you point out, delay measurements are jitter-prone, and after smoothing 
it's not clear that they're any better than AIMD. Latency is also not a 
constant for a flow.

A secondary concern is the likelihood of false positives in path 
selection due to the inability of legacy traffic shapers to deal with 
UDP correctly, especially when the payload is obfuscated.

And the third concern is to effect on flow optimizers, routers, and NATs 
of P2P streams moving around much faster than they do today, and of P2P 
streams growing in number relative to existing practice because they're 
probing more paths. These things all impact the infrastructure.

But thanks again for your assessment of Compound TCP.

RB

Nicholas Weaver wrote:
> Unfortunately there are continued errors in your article.
>
>
>
> On Dec 5, 2008, at 11:51 AM, Richard Bennett wrote:
>>
>> Morris also told the media this week that TCP only reduces its 
>> sending rate in response to packet loss, a common but erroneous 
>> belief. Like uTP, Microsoft’s Compound TCP begins to slow down when 
>> it detects latency increases. Even though TCP is capable of being 
>> just as polite as BitTorrent wants uTP to be, the fact that it hides 
>> its delay measurements from applications makes it troublesome for P2P 
>> clients with many paths to choose from. But it’s sensible to explore 
>> alternatives to TCP, as we’ve said on these pages many times, and 
>> we’re glad BitTorrent finally agrees.
>>
>
> And Compound TCP is the exact opposite requirements as uTP, the goal 
> is something which is NOT outcompeted by AIMD, if I'm groking the 
> description correctly.  Compound-TCP uses a sum-of-windows method, an 
> AIMD window and a delay-based window.
>
> uTP is a "Minimum of AIMD/delay based" window sizing algorithm.
>
> The implications are huge.
>
>
> Compound TCP is designed to get the delay-based behavior on very fast, 
> high latency networks, where even a very small loss rate introduces 
> very bad behavior to AIMD based congestion control and, in the absence 
> of congestion, an AIMD based sender would back off and not utilize the 
> link.
>
> Yet by using a sum-of-window with a second AIMD based window, it is 
> fully competitive with TCP flows.  This is actually more agressive 
> than conventional AIMD, except that the delay-based window gets 
> outcompeted by other AIMD flows, so it becomes effectively AIMD based 
> in terms of agressiveness.
>
> Thus under competition, Compound TCP can be considered AT LEAST 
> AIMD-only for fairness/agressiveness, because it uses the sum of the 
> two windows so the AIMD window will compete like any other flow and 
> (hopefully) the delay-based window will go to 0.
>
> Thus Compound TCP does NOT back off earlier.  In fact, the feature is 
> that it does NOT back off on a packet drop if it is on a high 
> bandwidth, high latency network!
>
>
> uTP, by being a "Minimum of two window" algorithm, is the opposite, as 
> it is AT MOST AIMD-only for fairness/agressiveness, precisely because 
> it takes advantage of the side effect of delay based congestion 
> control: it backs off earlier than AIMD-based flows so it gets starved 
> out by AIMD-based flows (hopefully).
>
>
> In almost all other TCP applications, the starvation problem faced by 
> delay-based window sizing is a problem.  For a scavenger-class 
> protocol like uTP, it is potentially a feature.
>
> Thus all TCP stacks are AT LEAST AIMD-aggressive, including Compound 
> TCP, as it uses delay-based metrics to have the exact opposite 
> behavior: attempting to grab more bandwidth in conditions where 
> AIMD-based systems fail.  Because any TCP stack that is not AT LEAST 
> AIMD-aggressive is going to face starvation under congestion.
>
>
>
> The open question is "how much friendlier" is (min(AIMD, delay based)) 
> in practice.
>
> Delay-based measurements are notoriously noisy and jitter prone, so it 
> may very well become "just AIMD" in terms of ISP congestion behavior, 
> which means it isn't more aggressive than TCP but isn't less 
> aggressive, thus it isn't a real scavenger-class service.
>
>
> And this isn't about replacing TCP, its about alternate congestion 
> control algorithms which are friendlier than AIMD (TCP Reno).
>
> The window sizing algorithms from uTP could just as easily be an 
> option in a TCP stack (and I've argued it should be a single-sided 
> option: one side of a TCP stack should be able to control both sending 
> and receiving windows in this manner).
>
> And its really just observing that "Not all flows are really equal 
> under congestion", so if you can designate a flow as "less important", 
> you get better aggregate behavior, and because you have some points of 
> congestion (eg, the user's uplink) where only the individual user 
> experiences it, there are incentives for applications to actually use 
> such a property.
>
>

-- 
Richard Bennett

_______________________________________________
ledbat mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ledbat