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

On Fri, Mar 25, 2016 at 8:04 AM, 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.
>
I believe https://tools.ietf.org/html/draft-nordmark-nvo3-transcending-traceroute-01
is the proposed solution for that.

> 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