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

[Joe Touch <[e-mail]>]

On 2019-07-15 09:39, Tom Herbert wrote:

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

I don't understand why this is confusing, so I'll be blunt: 

- OCS WILL NOT come at a *fixed offset* from the UDP header 

If you disagree, explain why you think that's true in your previous doc
or any other. 

It also can't come at a fixed offset from the start of the surplus space
UNLESS you assume that alignment doesn't matter. 

Is this clear enough? 

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

It's a deterministic EQUATION, but that equation is variable. 

I.e., the checksum is NOT at a fixed location from the *start of the
packet*, as it is in the UDP and TCP headers. 

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

That works fine for the fixed headers in TCP and UDP, which are less
than 255 bytes from the front of the packet in most cases (though not
all). They're certainly less than 255 bytes from the front of the TCP or
UDP packet start. 

However, are you also now asserting that we need to put OCS no more than
255 bytes from the front of the TCP or UDP packet? 

You do realize that widescale deployment of UDP and TCP use packet sizes
of 500+ byte payloads, which means WE CANNOT BE STUCK WITH THAT LIMIT. 

Yes, OCS comes less than 255 bytes *from the beginning of the surplus
space*, which itself comes some offset (>255) from the packet start. 

That's all I'm saying. 

> This is just one example of how
> implementations have been tuned to work on protocol headers as opposed
> to protocol trailers,

Sure, but if that's the limit AND it applies to the distance from the
front of the UDP packet, are you claiming it is now a limit for how far
OCS can be from the start? 

If that's the case, you're now claiming packets need to have payloads
smaller than 255 bytes, which IS A NONSTARTER. 

So again, if that's where you're getting the limits of using CS offload,
then use of that offload is already OFF THE TABLE. If not, please
explain. 

Joe