Re: [Spud] [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-01.txt

[Tom Herbert <[e-mail]>]

> We need to live without broken offloads because offloads are part of the
> protocol stack. They can't simply jump in and try to help without being
> very careful about corner cases like this.
>
> E.g., we've already seen an offload that merges TCP packets with
> different options, which ought to be clearly inappropriate.
>
Checksum offload conforms to the requirements for host checksum field
processing and Length field handling in RFC768 and RFC1122-- if this
change maintains those requirements then there is no issue.

It is not clear from the draft what the effect on checksum processing
will be. My questions are:

1) What is the UDP payload length for number of bytes to checksum over?
2) What value is in the UDP length field when the checksum is performed?
3) What is the on-the-wire value of the UDP length field?

If the use of UDP options is treated as a "truncation" of the UDP
payload before the checksum calculation is performed then the answers
to the above questions are the same and there is no incompatibility.
The option bytes would not be covered by the UDP checksum however.

Thanks,
Tom