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

[Sebastian Moeller <[e-mail]>]

Hi Michael,


> On Aug 16, 2023, at 19:45, Michael Welzl <[e-mail]> wrote:
> 
> Below:
> 
>> On Aug 16, 2023, at 6:52 PM, Tom Herbert <tom=[e-mail]> wrote:
>> 
>> 
>> 
>> On Wed, Aug 16, 2023, 3:17 AM Michael Welzl <[e-mail]> wrote:
>> Hi again, Tom, all,
>> 
>> In my previous email I have stated that I think this is worth doing, and pointed at some previous designs that encapsulate TCP in UDP.
>> 
>> Now, I would like to discuss some design details. I have two comments, for now:
>> 
>> 1)
>> Generally, these designs remove some elements of the TCP header (such as the urgent pointer, and in some of the designs also the checksum).
>> Two of the proposals ( draft-cheshire-tcp-over-udp-00 and our own, draft-welzl-tcp-ccc ) cut down the length of the TCP header in this way so much that this encapsulation can be done without changing the MTU. I think this is a great benefit - which you lose by maintaining the checksum. Why do you think the TCP checksum is still needed when you already have a TCP checksum?
>> 
>> Hi Michael,
>> 
>> I assume you mean we already have the UDP checksum.
> 
> Oops, yes.
> 
> 
>> Design rationale is:
>> 
>> 1) The UDP checksum is optional in IPv4. We'd have to make a requirement in TCPinUDP.
> 
> Okay, yes, that’s a very minor reason though…  (side note: this made me check QUIC: it doesn’t have a checksum either, right?  Actually, I’m surprised: I couldn’t find the word “checksum" in RFCs 9000, 9001, 9002, 9308, 9312??  What am I missing?  Surely, if it doesn’t have one, there should be some words somewhere about *not* disabling the UDP checksum when encapsulating it?!).
> 
> 
>> 2) TCP checksum is always required. To make it optional or use TCP checksum would require changes to core TCP stack
> 
> Yes, just item 4) below - but small ones. Many things require changes to the stack.
> 
> 
>> 3) There's no performance cost to hosts for having redundant checksums (assuming reasonable checksum offload is available). This is already true for TCP/IP in UDP encapsulation like VXLAN.
> 
> True, but a not much of an argument: “it’s there because it doesn’t hurt”…
> 
> 
>> 4) IMO, the benefits to avoid reducing the MTU don't outweigh the complexity to implement a compressed TCP header. The additional 12 bytes of overhead is easily accounted for determining MSS (we already do this for other forms of encapsulation also). PLMTUD continues to work, and so the only real cost is only 12 bytes on the wire overhead (<1% of typical MTU and less that any IPinIP encapsulation)
> 
> I see the point of the wire overhead gain being small, and you’re right: since we negotiate the MSS anyway it’s not a problem for PLPMTUD etc. At the same time, I think your arguments in favor are also not strong…  well, I can see that there could be a benefit in being able to hand a packet over to a 100% unchanged TCP stack, even with hardware support, which this encapsulation probably allows. I don’t have a very strong opinion here myself.
> 
> 
>> 2)
>> The UDP source port. I dislike this rule:
>> 
>>    The port value SHOULD be derived
>>    from the TCP 5-tuple; this can either be a hash over the 5-tuple, or
>>    simply a random number that is assigned by the source for the TCP
>>    connection maintained in its PCB (Protocol Control Block).
>>  
>> ...because TCP-in-UDP encapsulation yields a great opportunity to combine the congestion controls of multiple TCP connections (as in our design)  **IFF**  they share the same outer (UDP) 5-tuple, with many benefits (as described in my previous email, with pointers to results). Not sharing the same 5-tuple can also be beneficial, e.g. to make use of in-network load balancing with a mechanism such as TCP. There can be security reasons to decide for one or the other, too.
>> 
>> How to set the source port is a SHOULD. The source could set it differently assuming the implementation supports it.
> 
> That’d be okay with me if we’d be discussing how to implement the RFC that this spec is. But, we have an opportunity for clearer words about this  :-)    and in fact, I’d rather say: unless someone has good reasons NOT to do this, the default should be to use the same port for multiple connections, so that coupled cc. can do its job.

	[SM] I respectfully disagree, this will essentially require that flow-queuing schedulers/AQMs look into the secondary TCP header*... Could I ask you to make a prediction about the number of coupled CCs deployed in the field versus flow-queuing schedulers? My intuition is that we have considerably more FQ schedulers in the field, so the default should cater to those.

*) That or the coupled TCP flows are treated like a single flow in the aggregate, which might not give the expected throughput.


> 
> 
>> So, I would say that the choice of the UDP source port should be a conscious decision based on such considerations rather than generally derived from the TCP 5-tuple with a SHOULD.
>> 
>> We could, but again the implementation needs to support it. And  we want to make sure there is a recommended default that makes sense which I believe should be to automatically set an entropy value for the flow
> 
> Aha, I see, your primary intention is to leave the TCP code entirely unchanged. That could go in the list of arguments to exceptionally set the port as you suggest, diverging from my proposed default ;-)
> Otherwise… we’re here to change things, right?  and single-path cc coupling is a big win. Software and hardware can change when it’s worth it.

	[SM] "single-path cc coupling is a big win" over a flow queuing scheduler/AQM? Interested in data supporting your claim.

Regards
	Sebastian


> 
> Cheers,
> Michael
> 
> 
> 
>> 
>> 
>> If you wonder where “such considerations” would come from - e.g., a TAPS implementation would have the necessary inputs:
>> https://ietf-tapswg.github.io/api-drafts/draft-ietf-taps-interface.html#name-connection-groups
>> vs. https://ietf-tapswg.github.io/api-drafts/draft-ietf-taps-interface.html#name-isolate-session
>> ( All of this has been tried and tested. We did implement TCP connection coupling below a TAPS-like interface in the NEAT project. )
>> 
>> 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.
>> 
>> Tom
>>  
>> 
>> Cheers,
>> Michael
>> 
>> 
>> 
>>> On 12 Aug 2023, at 00:22, Tom Herbert <tom=[e-mail]> wrote:
>>> 
>>> Hi,
>>> 
>>> This is a draft describing how TCP could be encapsulated in UDP. This
>>> would be useful if UDP really is to be the "new network layer" and we
>>> want to use UDP Options with TCP to carry network layer options.
>>> 
>>> Thanks,
>>> Tom
>>> 
>>> 
>>> ---------- Forwarded message ---------
>>> From: <[e-mail]>
>>> Date: Fri, Aug 11, 2023 at 3:19 PM
>>> Subject: New Version Notification for draft-herbert-tcp-in-udp-00.txt
>>> To: Tom Herbert <[e-mail]>
>>> 
>>> 
>>> 
>>> A new version of I-D, draft-herbert-tcp-in-udp-00.txt
>>> has been successfully submitted by Tom Herbert and posted to the
>>> IETF repository.
>>> 
>>> Name:           draft-herbert-tcp-in-udp
>>> Revision:       00
>>> Title:          TCP-in-UDP Encapsulation
>>> Document date:  2023-08-11
>>> Group:          Individual Submission
>>> Pages:          10
>>> URL:            https://www.ietf.org/archive/id/draft-herbert-tcp-in-udp-00.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-herbert-tcp-in-udp/
>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-herbert-tcp-in-udp
>>> 
>>> 
>>> Abstract:
>>>   This document specifies a method of encapsulating TCP protocol
>>>   packets within UDP headers.  TCP-in-UDP is useful in situations where
>>>   network capabilities specific to UDP can be leveraged for TCP
>>>   packets.
>>> 
>>> 
>>> 
>>> 
>>> The IETF Secretariat