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

[Tom Herbert <[e-mail]>]

On Wed, Aug 16, 2023, 11:47 PM Michael Welzl <[e-mail]> wrote:

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

Michael,

Within the network, the flow label serves the same function as how devices
are using the ports in UDP encapsulation- in both cases they are use to
mark packet as belonging to the same flow.

A "flow" in this context is purposely ill defined, it does not have to
correspond one to one to a transport flow. So you're idea of combining TCP
flows into a mega flow for purposes of network visibility is a valid use
case; although I'd recommend that the IPv6 flow label and UDP source port
in encapsulation should be correlated to be consistent, i.e. packets of the
same flow should share the same flow label and source port.

The caveat with UDP port numbers is that some Firewalls might enforce
symmetric use of UDP ports to establish a quasi transport state. Like if
ports are (A,B) in one direction, they must be (B,A) in the other
direction. Personally, I'd rather not require that for TCPinUDP and I
believe it's not a requirement of QUIC, but I am interested in opinions on
this

Tom


> Cheers,
> Michael
>
>