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

[Joe Touch <[e-mail]>]

On 3/24/2016 1:20 AM, Michael Welzl wrote:
> 
>> On 24. mar. 2016, at 00.52, Joe Touch <[e-mail]> wrote:
...
>> Having one uniform layer at which multiplexing occurs makes things easy.
>> Having two means you have to wonder what the other is doing all the time
>> and whether the two correlate.
> 
> Is this a real practical problem related to this draft?

It is a real practical problem anytime you tunnel.

>>>> 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.

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.

>> The idea that packets need to take a single path is an ATM concept, not
>> IP. I think the Internet would be a lot better off if we just admit that
>> it's *based* on the idea that packets can use different paths, and that
>> this is a good thing.
> 
> I agree with everything you say here, but only in my research world 
> of non-Internet-compatible things. However, for the Internet, TCP’s 
> end-to-end congestion control really doesn’t allow us to admit that 
> packet can take different paths. (*) I remember Van Jacobson
> presenting in his SIGCOMM 2001 keynote how we’ve wrongly applied
> circuit-style thinking to the Internet, and how this really isn’t how
> things should be. I sat there, trying to understand what he says,
> because I thought that *he* did this to us?!?! (I don’t blame him for
> having made a quick fix that worked, this was a great job! - but, to
> me, folks should have understood early on that this can only be a
> temporary fix, not a “clean” solution: if anything has made the
> Internet circuit-like then it’s TCP’s end-to-end congestion control,
> I’d say. 

Van has gone back and forth on this issue. The next keynote I saw him
give in Switzerland basically did a complete 180 on his Sigcomm keynote.

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.

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.

...
>>> The sender-side behavior then couples connections; this could be 
>>> done via the Congestion Manager, or in a way similar to TCB sharing,
>>> or with our algorithm (which is somewhat similar to TCB sharing).
>>> That’s why we call it “example algorithm” - think of this as “UDP
>>> encapsulation forces TCP connections on the same path so we can use
>>> the CM”. That’s really all it is.
>>
>> "all it is" is a complete reimplementation of everything in IP inside
>> UDP -- because everything that IP provides will ultimately be need by
>> this layer, as well as a way to map this to the corresponding IP mechanism.
>>
>> I think it would be useful to take a deeper look at the implications
>> before jumping into this water.
>>
>> Joe
>>
> 
> I don’t get it. Why do you say “everything that IP provides will
> ultimately be needed by this layer”? I can’t see why the implications
> would be as bad as you say, at least not for the draft we’re discussing
> here. It’s only 4 bytes of UDP header that map a few TCP connections to
> one UDP port number pair using a well-known UDP port… the way you talk
> about this, these must be the world’s most dangerous 4 bytes :)

Look at the tunnels draft in INTAREA. When you add a header, you create
a tunnel. The implications of doing so on the E2E and HBH signalling are
important and very difficult to get right. It's not just 4 bytes.

> (*) 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.

Joe