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

Cheers,
Michael