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

[Tom Herbert <[e-mail]>]

On Mon, Jul 15, 2019 at 10:02 AM Joe Touch <[e-mail]> wrote:
>
>
>
>
>
> 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
>
Joe,

On that I agree. But, draft-herbert-udp-space-hdr-01 proposes to put a
checksum, which is not OCS, in a fixed header at the beginning of the
surplus space that covers the whole surplus. The motivations for this
are articulated in section 4 of that draft, have been brought several
times on the mailing list, as well as tsvwg meeting @IETF104.

Tom


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