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

[Michael Welzl <[e-mail]>]

> On 24. mar. 2016, at 00.52, Joe Touch <[e-mail]> wrote:
> 
> 
> 
> On 3/23/2016 4:43 PM, Michael Welzl wrote:
>> 
>>> On 24. mar. 2016, at 00.05, Joe Touch <[e-mail]> wrote:
>>> 
>>> 
>>> 
>>> On 3/23/2016 4:42 AM, Michael Welzl wrote:
>>>> I'm sending this here as well because it relates to the idea of "running the Internet over UDP" (which, I noticed, is presentation that Brian will give in MAPRG: https://datatracker.ietf.org/meeting/95/agenda/maprg/ ).
>>>> This draft explains how we think it should be done with TCP; we believe that it can have quite significant positive side-effects, mainly because of the opportunity to combine the congestion controls of multiple connections.
>>> 
>>> Ick.
>>> 
>>> We went through this before multiple times. One notable was the impact
>>> of chunking and muxing in HTTP, effectively reinventing IP inside.
>>> 
>>> "A person with one watch always knows what time it is. A person with two
>>> is never sure.”
>> 
>> I don’t think I follow this, sorry.
> 
> 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?


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


> 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. Well, now we’re kind of stuck with this end-to-end thing that tries to guess the right rate over a path that can consist of an arbitrary composition of link layers… “IP over everything, and then let TCP try to do the right thing over it”. Nonsense, I say! But super hard to fix...)


>> 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  :)

Cheers,
Michael



(*) Researchy side note here: I’m all for fixing this, but this would require putting congestion controls inside the network, which you said you didn’t like earlier in this conversation if I understood you correctly. Well, definitely this is a research topic, not an engineering one, at this stage - but I’m convinced that this is the right direction to pursue. Indeed, THEN we can admit that packet networks can allow packets to take different paths. Moving such stuff to the Internet would require making PEPs first-class network citizens, and doing away with the notion that taking care of congestion control (not necessarily reliability! so these are not your standard TCP splitters) is a security breach. I have no idea if that can ever be made to happen, and lots of homework about control loop interactions and such is necessary before even thinking further on this I’d say.