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

Please discuss this draft on the ICCRG list. I’ll keep stackevo-discuss in cc just this once as a reminder to folks here that this has moved, but please remove it in your response. Let’s try to cleanly transition to ICCRG if we can.

About your email, my general answer is: you seem to be reading more into this than it is.

You mention reliability, applicability to video streaming, etc.: this is still “normal” TCP. In fact a design goal was to minimize the changes that we need to do to it, so it’s a relatively easy code change. The intention is only to be able to combine the congestion controllers of multiple flows, as has been suggested before (CM, Ensemble sharing, ..). The outcome is that multiple flows are closer to being like one flow, and there should be some benefits there in terms of new flows immediately being able to use a larger cwnd, priority-based cwnd share assignment etc.

Since you mention tunnels, issues with traceroute, overlays, etc.: this is an e2e encapsulation. Same TCP source and destination endpoints as before.

Does it require rendez-vous points: it requires a well-known UDP port. The idea is that a client checks using UDP if the server is TCP-in-UDP capable (listening on the UDP port), and if not, falls back to TCP. This is achieved by “happy eyeballing” (sending out packets of both types in one go).

Cheers,
Michael

> On 25. mar. 2016, at 16.04, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
> 
> 
> 
> Le 25/03/2016 09:12, Michael Welzl a écrit :
>> 
>>> On 24. mar. 2016, at 18.46, Joe Touch <touch@isi.edu> wrote:
>>> 
>>> 
>>> 
>>> On 3/24/2016 1:20 AM, Michael Welzl wrote:
>>>> 
>>>>> On 24. mar. 2016, at 00.52, Joe Touch <touch@isi.edu> 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.
>> 
>> Even when the method avoids that packets grow in size?
> 
> The size of the tunnelled packets may not be as big as expected problem.
> For example, additional 40bytes on wireless are not that bad as
> initially expected, simply because the total size is already around
> 1280bytes before tunneling.
> 
> On another hand, this problem of multiplexing at multiple levels makes
> it that there is no 'traceroute' program that meaningfully reports
> number of hops through tunnels.  This is a universal tool for network debugging, maybe as loved as ping is.
> 
> Overlay networks grow for a while and then get levelled down into
> 'native' multiplexing level if I can say so.  For example IPv6 tunnels
> over an IPv4 world moved to IPv6 native (3ffe disappeared a while back
> and 6to4 recently; each had a different way of relating two multiplexing
> levels).
> 
> For TCP in UDP there would be a myriad ways of mixing the slow
> intelligence of TCP with the quick dumbness of UDP.  After trying them
> all would one come back to TCP and UDP side-by-side as before?  Why not?
> 
> Is TCP-in-UDP as reliable as TCP?  Or is it more subject to packet loss
> and longer retries?
> 
> Is TCP-in-UDP useful for video streaming from constrained devices, as
> useful as UDP is?
> 
> Does TCP-in-UDP require rendez-vous points?
> 
> Alex
> 
>> I’m surprised but I’m not going to debate this further: you provided
>> a useful pointer (the tunnels draft in INTAREA), I’ll have to take a
>> look and try to understand the problem. Anyway I agree that a
>> solution like the v6 flow labe that Tom Herbert suggested is nicer; I
>> have nothing at all against that and now plan to incorporate it in
>> the next version of the draft, for the v6 case.
>> 
>> As for the congestion control related bits of your email, I made a
>> mistake: I started this off saying “let’s discuss this in ICCRG”,
>> but then I follow up a discussion here on stackevo. This is purely
>> about congestion control, so it really belongs there. My next email
>> in this matter will go to you, cc iccrg.
>> 
>> Cheers, Michael
>> 
>> _______________________________________________ Stackevo-discuss
>> mailing list Stackevo-discuss@iab.org
>> https://www.iab.org/mailman/listinfo/stackevo-discuss
>> 
> 
> _______________________________________________
> Stackevo-discuss mailing list
> Stackevo-discuss@iab.org
> https://www.iab.org/mailman/listinfo/stackevo-discuss