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

[Tom Herbert <[e-mail]>]

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.

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.

There are some other end system issues in dealing with UDP
encapsulation that we considered in Linux (load balancing, checksum,
segmentation offload). Please look at
http://people.netfilter.org/pablo/netdev0.1/papers/UDP-Encapsulation-in-Linux.pdf.

Thanks,
Tom

On Wed, Mar 23, 2016 at 1:04 AM, Michael Welzl <[e-mail]> wrote:
> Hi,
>
> This could be of interest to folks here. We'd be glad to get your comments - please send them to the ICCRG list only, at [e-mail].
>
> Cheers,
> Michael
>
>
>> Begin forwarded message:
>>
>> From: Michael Welzl <[e-mail]>
>> Subject: Fwd: New Version Notification for draft-welzl-irtf-iccrg-tcp-in-udp-00.txt
>> Date: 23 Mar 2016 09:02:38 CET
>> To: [e-mail]
>>
>> (..)
>>
>> Chair hat off:
>>
>> Dear all,
>>
>> I'm submitting this to ICCRG as the primary (and possibly ultimate? We'll see) forum to discuss this draft. We'd be happy to get your comments - please keep them on the ICCRG list.
>> We have FreeBSD code, from which we can already confirm that the encapsulation is indeed relatively easy to do (as our draft states). However, it doesn't do the congestion control coupling yet; we're working on it. For that, so far, we have simulations - from these, we hope to be able to show some first results in BA.
>>
>> Cheers,
>> Michael
>>
>>
>>
>>> Begin forwarded message:
>>>
>>> From: <[e-mail]>
>>> Subject: New Version Notification for draft-welzl-irtf-iccrg-tcp-in-udp-00.txt
>>> Date: 21 Mar 2016 18:45:57 CET
>>> To: Jianjie You <[e-mail]>, Michael Welzl <[e-mail]>, Safiqul Islam <[e-mail]>, Kristian Hiorth <[e-mail]>
>>> Resent-From: <[e-mail]>
>>>
>>>
>>> A new version of I-D, draft-welzl-irtf-iccrg-tcp-in-udp-00.txt
>>> has been successfully submitted by Michael Welzl and posted to the
>>> IETF repository.
>>>
>>> Name:                draft-welzl-irtf-iccrg-tcp-in-udp
>>> Revision:    00
>>> Title:               TCP in UDP
>>> Document date:       2016-03-21
>>> Group:               Individual Submission
>>> Pages:               17
>>> URL:            https://www.ietf.org/internet-drafts/draft-welzl-irtf-iccrg-tcp-in-udp-00.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-welzl-irtf-iccrg-tcp-in-udp/
>>> Htmlized:       https://tools.ietf.org/html/draft-welzl-irtf-iccrg-tcp-in-udp-00
>>>
>>>
>>> Abstract:
>>>  This document specifies a method to encapsulate multiple TCP
>>>  connections using only one UDP port number pair.  Doing so allows for
>>>  a relatively easy implementation of coupled congestion control for
>>>  the TCP connections.  This can have several performance benefits, and
>>>  it makes it possible to precisely assign a share of the congestion
>>>  window to the connections based on priorities.  It also enables use
>>>  of UDP-based NAT traversal techniques, and it can act as a framework
>>>  for experimentation with novel changes to the TCP standard.
>>>
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> The IETF Secretariat
>>>
>>
>