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

[Michael Welzl <[e-mail]>]

> On 25. mar. 2016, at 18.16, Alexandre Petrescu <[e-mail]> wrote:
> 
> 
> 
> 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.

It’s as applicable or non-applicable as 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.
> 
> 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.

Yes


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

Exactly: you have one UDP port number pair, using a well-known port, that encapsulates several separate TCP port number pairs.
To the TCP’s on both sides, its normal port numbers are still there - they’re preserved, by first exchanging them on the SYN / SYN-ACK and then just “compressing” them into a connection ID.


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

Aha! Well yes indeed, on the same machine. We change the TCP code on the client, we change the TCP code on the server, we involve no extra system.


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

The way we do it may not be optimal but it’s pretty simple, see below:


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

It’s described in section 4 of the draft:
https://tools.ietf.org/html/draft-welzl-irtf-iccrg-tcp-in-udp-00#section-4
The explanation begins under the bullet list, at the paragraph starting with "Unless it is known that…”.   Note to self: make a subsection for this in the next version…
We don’t wait for “UDP Port Unreachable”: we try both and use what comes back first.

Cheers,
Michael