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

[Tom Herbert <[e-mail]>]

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.

Tom

> Cheers,
> Michael
>