[Rtg-dt-encap-considerations] Some comments on draft

[Tom Herbert <[e-mail]>]

Abstract:

in the case when->in the case that

Section 2

The encapsulation protocols typically->Encapsulation protocols typically

And NIC hardware->NIC hardware

Section 4

2nd bullet is a lttle wordy. I think this is saying we assumed mostly
stateless encapsulation protocol

Section 5

The goal to->The goal is to

the need to be aware->they need to be aware

The section on IPv6 flow label is still a little conservative I think.
We already have RFC 6438 that described use of flow labels with
tunnels. Also, this might be better positioned as a way to provide
additional entropy (14 bits for tunnels is going to be a little light
in some contexts).

Section 8

some way to indicate which encapsulation header will follow... not
clear. This saying: some way to indicate next protocol?

Bullet 2. I don't understand the part about "bringing in protocol
numbers that don't make sense".

Section 10

A single marker in the encaps... there was discussion in nvo3 such a
plan and it had some problems By using a single bit the epochs are
forced to be rather coarse. Other problems with part about using a s
single bit to do 1-way latency. I think this paragraph should be
removed or expanded with more detail.

Section 11: Still needs to be cleaned up. I will try to do that.

Section 13: Data centers may be very highly optimized for their own
internal traffic by assuming that all internal traffic in under a
specific congestion control. That hash allowed us to size and carve
buffers in very specific ways. With cloud, we introduce 3rd party
stacks, that may implement CC, but not one which is conformant with
internal traffic. This is creating problems and may be the motivation
for true cc at encap layer

Last paragraph: Rate limiting is not the same thing as congestion
control (unless there's very active management of rate)

Section 14

There is little value in the portion of the UDP checksum... true in
terms of being redundant to an encapsulated checksum, however there is
value in leveraging the outer checksum to validate inner one using
common NIC offload features.

For description of partial checksum maybe add: This checksum would
cover the encapsulation header and a pseudo header that includes at
least the IP addresses and ports.

For NAT problem this can be solved with an additional field that holds
the checksum of the original IP addresses.

Section 17

Once again the idea of spraying packets of single flows has been brought up:
https://www.cs.purdue.edu/homes/kompella/publications/infocom13.pdf

It's probably more correct to say that TCP is optimized for in order
delivery, but can handle ooo. Some other protocols (non-IP) might have
much more difficulty.

Section 18

Keep encap headers small-- can we be more specific on what small means?