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

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
>