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

[Tom Herbert <[e-mail]>]

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.

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.

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

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