Re: [tsvwg] Comments on draft-pauly-tsvwg-tcp-encapsulation

[Mirja Kühlewind <[e-mail]>]

Hi Tom,

see below.

On 25.09.2018 20:10, Tom Herbert wrote:
> On Tue, Sep 25, 2018 at 8:12 AM, Mirja Kühlewind
> <[e-mail]> wrote:
>> Hi Erik, hi Tommy,
>>
>> I beliebe I promised in Montreal to send some more comments on draft-pauly-tsvwg-tcp-encapsulation; at least that’s what my todo list says (now that I reached down to some bottom part of it).
>>
>> Anyway, here it comes, mainly based on what I already said in the meeting:
>>
>> - Section 3: the example format you define is definitely the right way to go and is what is usually used. However, when I was reading encapsulation, I was thinking that you could probably also just put the whole UDP packet including the UDP header into the TCP stream. Is that a thing that we want maybe discuss as well?
> 
> Mirja,
> 
> Would that include the IP header for for each encapsulated packet? If
> the TCP encapsulation endpoints are coincident with the UDP endpoints
> then the IP headers for reconstituting the UDP/IP packet could be
> derived from the outer IP header- that would save quite a few bytes.
> This makes the inner UDP checksum interesting when the packet goes
> through NAT, but that can be resolved by using the NAT Address
> Checksum option as described in draft-ietf-intarea-gue-extensions.

No I think that a different use case; this draft is mostly about 
end-to-end encapsulation to my understanding and tunneling is just 
mentioned because similar approaches could be used if needed. I was just 
thinking if it might be potentially easier to keep the whole UDP header 
instead of replacing it with a length field. However replacing it 
entirely also saves some bytes.

> 
> On the the topic of encapsulation format, I would suggest the authors
> look at GUE as a possible candidate to make TCP encapsulation generic
> and extensible. The generic part would mean that each TCP encapsulated
> packet could have type, extensible allows options like the one
> described above and there might be some other options that are useful
> like CRC and header authentication. Checksum offload for TCP and UDP
> packets encapsulated in TCP might also be possible to pull off with a
> little protocol help. The only thing needed to turn GUE into GTE
> (Generic TCP Encapsulation) would be adding the length field to
> demarcate messages in the stream.

As I said, as this is not about tunneling, GUE is probably an overkill.

> 
>>
>> - One comment I had in the meeting is actually related to this first point. I said that there should be a stronger recommendation to not change the protocol above. However, if you currently implement your own congestion control and the switch to TCP, it might actually be beneficial to disable that congestion control. I guess the point needs more discussion to figure out what we actually want to recommend, e.g. make minimal change and don’t change the header for easier convergence at gateway…?
>>
> One obvious question that will be raised on this draft is why would an
> application bother to encapsulate UDP in TCP as opposed to just using
> TCP directly. I would presume the answer is that there are some
> applications where the client or server side can't be changed and TCP
> encapsulation would be implemented as a transparent layer beneath the
> application. If that's the case, the congestion control of the
> application protocol probably can't be changed too easily.

Usually, these protocol are already designed for UDP because that's the 
right choice of protocol, e.g. low bandwidth IOT applications. However, 
to work over the Internet, often TCP is the only deployable choice.

I guess if that is not clear from the doc, it would make sense to add a 
small applicability section.

Mirja


> 
> Tom
> 
>> - In section 3.1 it could probably make sense briefly mention the possibility of head-of-line blocking when you multiplex.
>>
>> - Another high level comment from the discussion in Montreal was, that it would probably make sense to separate more clearly the case where encapsulation is used end-to-end or between tunnel endpoints. I guess for the second case, there may be some docs in the INT area that could be worth citing, e.g. draft-touch-intarea-tunnels; not sure if there is more.
>>
>> That’s all I have for now! Hope that helps! Thanks for writing this up!
>>
>> Mirja
>>
>>
>>