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

[Joe Touch <[e-mail]>]

On Nov 2, 2015, at 5:15 PM, Tom Herbert <[e-mail]> wrote:

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

The udp payload indicated by the udp length field, and the usual IP pseudoheader. 

> 2) What value is in the UDP length field when the checksum is performed?

The length before the trailer.  

> 3) What is the on-the-wire value of the UDP length field?

Same as #2 above.  

> 
> If the use of UDP options is treated as a "truncation" of the UDP
> payload before the checksum calculation is performed

It is. 

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

Correct. A separate "trailer checksum" would be required to protect the trailer. 

Joe

> 
> Thanks,
> Tom