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

[Michael Welzl <[e-mail]>]

> On 25. mar. 2016, at 19.51, Tom Herbert <[e-mail]> wrote:
> 
> On Fri, Mar 25, 2016 at 11:22 AM, Michael Welzl <[e-mail]> wrote:
>> 
>>> On 25. mar. 2016, at 18.58, Tom Herbert <[e-mail]> wrote:
>>> 
>>> On Fri, Mar 25, 2016 at 10:29 AM, Michael Welzl <[e-mail]> wrote:
>>>> Hi!
>>>> 
>>>> 
>>>>> On 25. mar. 2016, at 18.00, Tom Herbert <[e-mail]> wrote:
>>>>> 
>>>>> Hi Michael,
>>>>> 
>>>>> For encapsulation format I suggest that you look at GUE
>>>>> (https://tools.ietf.org/html/draft-ietf-nvo3-gue-02). GUE can
>>>>> encapsulate TCP in UDP and inserts a GUE header that allows extra meta
>>>>> data.  The connection ID could be moved to the GUE header so that no
>>>>> special modification of the encapsulated TCP header would be needed.
>>>>> The connection ID would be a new field in the GUE header. There is
>>>>> already a session ID option defined, but that is 96 bits which is
>>>>> probably overkill.
>>>> 
>>>> I have, as I wrote this draft. It struck me as something that isn’t really necessary just for the purpose of what TCP-in-UDP is trying to achieve. In particular, other than GUE (if I got it correctly), TCP-in-UDP strictly assumes end-to-end operation, and requires changing the sender-side TCP code too because the main point is to combine congestion controls. This makes it possible to do whatever we want with the encapsulated TCP header.
>>>> 
>>> Then you are redefining TCP.
>> 
>> Yes - that’s the whole point
>> 
>> 
>>> You can do that, but this substantially
>>> reduces the possibility of deployment. In real networks we need
>>> tcpdump, netflow, diagnostics, other debugging tools. Encapsulation
>>> works best when it does not require changes to the encapsulated
>>> packet. Besides that if your willing to change TCP for this use, why
>>> not just go a little farther and use SCTP/UDP which I believe already
>>> has a concept of shared congestion window amongst sub-flows?
>> 
>> You’re completely right. In fact I expect the performance of this TCP coupling to be quite similar to SCTP/UDP with multistreaming. The difference is in how this is implemented: it can, for example, be plugged underneath existing applications that use TCP, and it’s also a way to play with new TCP options that middleboxes wouldn’t like. It’s a small overhead method - TCP code has been optimized to death, SCTP comes with some overheads such as the CRC checksum (but it also has some more benefits).
>> 
>> 
>>>>> Another consideration is the UDP checksum. This must be set in IPV6
>>>>> (excepting that the requirements in RFC6935 and RFC6936 are met) and
>>>>> is recommended for encapsulation any way. This means that there are
>>>>> two checksums (TCP and UDP) per packet which becomes a performance
>>>>> issue since most NICs can offload at most one checksum and often that
>>>>> is restricted to only the checksum in a plain TCP or UDP packet with
>>>>> no encapsulation. We solved this in GUE with remote checksum offload
>>>>> (https://tools.ietf.org/html/draft-herbert-remotecsumoffload-02) which
>>>>> should work fine with TCP over UDP case.
>>>> 
>>>> We (and the preceding proposals that are cited in the draft) removed the redundant TCP checksum from the encapsulated TCP header. Because it’s end-to-end and changes TCP anyway, we can do that.
>>>> 
>>> That will break our ability to use NIC offload with TCP/UDP
>>> (segmentation offload for instance). Everything, including many
>>> performance optimizations, is already designed around the requirement
>>> that the TCP checksum must be set. Trying to undo that requirement is
>>> actually a complication, not a simplification in practice.
>> 
>> Interesting… here I lack knowledge about offloading. Are you saying that GUE doesn’t have that problem? That would make it a more attractive encapsulation option then.
>> 
> 
> There's been a lot of work in this area since encapsulation over UDP
> is very hot as a solution for tunneling. So we are working on
> solutions that are generic across all flavors of foo-over-udp for L2
> and L3 encapsulation. I believe these solutions should be applicable
> to L4 encapsulation also (e.g. TCP/UDP). What we don't want is HW
> vendors endlessly adding protocol specific support in HW for all these
> foo-over-udp. With some care, we should be able to design new
> encapsulations and generic HW support that avoid the need for
> protocol-specific awareness in HW.

Understood, makes perfect sense to me.

Cheers,
Michael