Re: [iccrg] [Stackevo-discuss] New Version Notification for draft-welzl-irtf-iccrg-tcp-in-udp-00.txt

[Michael Welzl <[e-mail]>]

So now I’m answering the congestion control bits here. I’ll reorder things a little to more effectively answer points that belong together, I hope you don’t mind.

Side note: while this is about TCP using multiple paths, so far we have left MPTCP out of the discussion, and that probably makes sense. It does pretty clearly reflect "one congestion controller per path” thinking, I would say, and that makes it come from a different angle than what we’re discussing here: assuming a network of multiple paths, not a single path, for a single end-to-end congestion controller.


> On 24. mar. 2016, at 18.46, Joe Touch <[e-mail]> wrote:
> 
> 
> 
> On 3/24/2016 1:20 AM, Michael Welzl wrote:
>> 
>>> On 24. mar. 2016, at 00.52, Joe Touch <[e-mail]> wrote:
> ...
> 
>>>>> I can't imagine what combined congestion control of TCP would mean
>>>>> inside the network - we had a hard enough time defining it for either
>>>>> TCB sharing or the Congestion Manager just at the endpoints.
>>>> 
>>>> I don’t get this either; it sounds like a misunderstanding?
>>>> 
>>>> So the encapsulation here is just meant to force packets to take the 
>>>> same path - else the Congestion Manager may be doing something
>>>> pretty wrong.
>>> 
>>> The CM is supposed to react to E2E congestion, which is the sum of all
>>> effects of the different paths that packets can take.
>> 
>> I’ll have to disagree. The CM is one congestion control instance, 
>> and E2E TCP-like congestion control is based on the assumption of a
>> single path. Things go wrong if this assumption is broken, e.g. when
>> packets from a single connection are sent in different directions
>> inside the network. This is not only due to possible reordering, but
>> also because e.g. a congestion event on path 1 would make the
>> controller reduce its rate, even if path 2 still has 3 times more
>> capacity available.
> 
> TCP has always handled reordering.

In one way or another, yes…  I (and I’m sure, you) know of various attempts to deal with it; first off, stretching the threshold to allow more than 3 DupACKs, which is a trade-off between allowing more reordering and making the response slower. Second, trying to survive even when you got it wrong - i.e., seeing spurious loss events, and then having to undo the response; yes, good TCP implementations can cope with these things to some degree, but repeatedly seeing and undoing spurious loss events isn’t exactly what I’d call TCP’s normal operation condition. It’s also implementation dependent - this Ph.D. thesis:
http://folk.uio.no/paalh/students/DominikKaspar-phd.pdf
finds that Linux TCP can handle reordering better than a fully standard-conforming implementation would.

Bottom line, I agree TCP handles it, but I wouldn’t say these are its “normal” (preferred) operation conditions. Anyway, I mainly mentioned it because it’s the more prominent problem that one gets when using multiple paths. The other one that I mentioned above seems more severe to me. See below:


> TCP congestion control treats the network as a system - if the net as a
> whole drops packets, it backs off. If the net as a whole does not, it
> increases. That's consistent with TCP CC. You don't need to assume a
> single path.
(..)
> TCP CC absolutely allows us to assume different paths - it reacts to the
> *network* as a transfer mechanism, i.e., where the "path" is through the
> blob we call a network. The only real problem is when that blob's
> properties vary, but that's always a problem for every feedback system.

so then how do you solve the 2-path problem I explained above? Let me make this clearer, with a simple, very static example problem (the only dynamics here come from a single TCP connection):
Consider an empty network. Path 1 has capacity X. Path 2 has capacity 3*X. Some device in the network decides to round-robin schedule packets from a single TCP connection across paths 1 and 2.
Congestion will first appear on path 1. TCP will react, halving its cwnd. Most of the capacity of path 2 will always remain unused that way.

How do you solve this with e2e congestion control?


>> (*) Researchy side note here: I’m all for fixing this, but this
>> would require putting congestion controls inside the network,
> 
> No, it really doesn't. It just means we assume that the net is the
> "path", not that we know or have control over a specific set of links.

The only solution I can see to my problem above is not to schedule traffic as I described it. Obviously the scheduler should send more packets on path 2 than on path 1. Doing this correctly requires knowing the capacities of these links. Considering a more dynamic network situation, it requires knowledge about where the bottleneck currently is, and how much capacity is available per link. This is a control loop. If you put such a control loop in the network, you may want to give it a different name than me, but this is what I meant when I said “this would require putting congestion controls inside the network”.


> NOTE: threads along these lines have been popping up on V6OPS recently
> too; it'd be useful to check there. I'm not the only one who thinks we
> should stop trying to act like we can pin paths merely by picking IP
> addresses, flow labels, or doing DPI - all we ought to assume is that
> everything within a flow is "treated the same way", which does not mean
> that every packet is treated IDENTICALLY.

As per my example above, this would mean that you’d need something quite similar to congestion control inside the network, or the available capacity for packets on all these paths must be equal, all the way to the receiver - else you’ll end up underutilizing your network.

Cheers,
Michael