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

[Alexandre Petrescu <[e-mail]>]

Le 25/03/2016 17:57, Michael Welzl a écrit :
> 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.

Ok for TCP, but the question was of TCP-in-UDP applicability to
video-streaming as opposed to UDP applicability in video-streaming.

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

I can agree.

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

I guess you mean multiple TCP flows.

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

But different couples of port numbers, right?  It would be
transport-layer encapsulation similar to network-layer encapsulation
which uses different couples of IP addresses.

> Does it require rendez-vous points: it requires a well-known UDP
> port.

Ok, so the TCP and UDP endpoitns would be on a same machine.  I was
thinking they were on different machines, and the machine owning the
well-known UDP port (rdv point) would multiplex to other TCP-only
machines which dont implement TCP-in-UDP.

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

There are a few questions here.

If a destination is not TCP-in-UDP capable will it tell it explicitely
to the source?  This is hard to do.

Or will the source decide based on the reception of a "UDP Port
Unreachable"?  If so, then you hit this need of the UDP layer to
communicate to the TCP layer: if  UDP port number is unavailable then
use this other TCP port number.  And there are so many ways to do that,
that at some point one may think it's better to leave them alone
separate, not one in the other.

> This is achieved by “happy eyeballing” (sending out packets of both
> types in one go).

I didnt know.  I will look.

Alex


>
> Cheers, Michael
>
>
>
>> On 25. mar. 2016, at 16.04, Alexandre Petrescu
>> <[e-mail]> wrote:
>>
>>
>>
>> Le 25/03/2016 09:12, Michael Welzl a écrit :
>>>
>>>> On 24. mar. 2016, at 18.46, Joe Touch <[e-mail]> wrote:
>>>>
>>>>
>>>>
>>>> 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.
>>>
>>> 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 [e-mail]
>>> https://www.iab.org/mailman/listinfo/stackevo-discuss
>>>
>>
>> _______________________________________________ Stackevo-discuss
>> mailing list [e-mail]
>> https://www.iab.org/mailman/listinfo/stackevo-discuss
>
>