Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

[Tom Herbert <[e-mail]>]

On Mon, Jul 15, 2019 at 9:15 AM Joe Touch <[e-mail]> wrote:
>
>
>
> > On Jul 15, 2019, at 8:50 AM, Tom Herbert <[e-mail]> wrote:
> >
> >> On Sun, Jul 14, 2019 at 8:52 AM Joe Touch <[e-mail]> wrote:
> >>
> >> So, *given* that we *are* different from UDP and TCP, i.e., we do NOT have the luxury of a fixed-offset location for this checksum
> >
> > Joe,
> >
> > There's no requirement that precludes defining a fixed header that
> > precedes the surplus space.
>
> It clearly can’t be a fixed location. Thats all I was asserting.
>
> Or do you disagree?
>
In draft-herbert-udp-space-hdr-01 the checksum is a header that
precedes the surplus space. The surplus space header is the head of
the surplus space aligned to a four byte offset (in case of UDP
Extended Header no padding is required). The location and presence of
the checksum field is deterministic.

> >> - why does the offset distance matter, i.e., front vs. end?
> >
> > Because some implementations assume that checksums are in protocol
> > headers towards the beginning of the packet. For instance, for
> > checksum offload the e1000e NIC stores offsets of checksum start and
> > checksum field in a byte. If either offset is greater than 255 then
> > the checksum can't be offloaded to the hardware.
>
> That’s a nonstarter. We cannot make that limit. Any other reason?

Well, this "nonstarter" has been in widescale deployment for many
years with proven benefits. This is just one example of how
implementations have been tuned to work on protocol headers as opposed
to protocol trailers, and it's probably not even the one with the
worst implications. There are going to be many hardware
implementations that simply can't process protocol trailers. So if
they think they need to, either they'll either drop the packet or
relegate them to some intolerably slow software path. As we've seen,
many times before, if hardware doesn't properly support a datapath
protocol in fast path the protocol is doomed (e.g. see the fate of
IPv4 options).

Tom