Re: [tsvwg] New Version Notification for draft-herbert-tcp-in-udp-00.txt

[Michael Welzl <[e-mail]>]

Hi,

[snip: checksum or not, changing the header or not]

> Whether or not the arguments are strong depend on what is being argued. Generally, minimal change to protocols is good, and I believe that philosophy was applied in GRE/UDP, SCTP/UDP, and MPLS/UDP. So I think from that perspective the arguments are strong.

Fair enough; we can stop discussing this and see what others think - I don’t have a strong opinion here. If we’d indeed find that there would be very good reasons to change the header, a choice of alternate header formats could also be encoded in your own header's reserved field….


> You mentioned doing encapsulation without changing the MTU is a great benefit, can you elaborate on that?

(nit-picking: you probably mean the MSS, not the MTU).

No, sorry, that’s a misunderstanding - I meant that being able to use the same outer (UDP) ports for multiple TCP connections is a great benefit.

Perhaps just noise since it was a misunderstanding, but I’ll elaborate a bit anyway:

That’s because it enables combining their congestion controls, with gains such as lower queuing delay (from less competition), total control over priorities, and more…  one particularly noteworthy gain: a new (or quiescent!) connection that hasn’t probed for capacity yet can immediately make use of capacity probing that another connection has already carried out. I.e., instead of starting with IW, if there is e.g. one other connection that has reached a large cwnd, the new connection can immediately be assigned cwnd/2, at potentially little disadvantage for the other connection - no need to go through slow start, no need to waste RTTs trying to understand where the limit is…

We have some results on this particular aspect in this paper: https://irtf.org/anrw/2016/anrw16-final28.pdf <https://irtf.org/anrw/2016/anrw16-final28.pdf>   … but generally we have more results on more aspects of the whole thing, in various contexts, and it’s just a big win altogether.  I think people now see multi-streaming as one of the major benefits of QUIC, and one out of several benefits thereof is its combined congestion control. I’m talking about getting the same gains with a relatively simple gradual change to the TCP CC. engine, all possible when the UDP ports are the same.


BTW, in a previous email, you wrote:
> Yes, there is an interesting benefit since the UDP ports can be decoupled from the TCP ports. This is also a property of the IPv6 flow label and in fact both the flow label and UDP source port in UDP encapsulation are set in Linux using the same functions.

…so I’ll note that the IPv6 flow label doesn’t seem to yield that same benefit: being able to do single-path coupled CC means that we must be able to rely on the path being the same (at least “rely” as much as other transports already do), and that means that, with IPv6, routers would have to hash over at most the IP addresses + protocol + flow label tuple for load balancing, not the tuple containing the ports. The spec allows both, and we have done some measurements which indicate that, alas, we can’t rely on such hashing without the ports.

Cheers,
Michael