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

[Tom Herbert <[e-mail]>]

On Tue, Nov 3, 2015 at 10:48 AM, Joe Touch <[e-mail]> wrote:
>
>
> 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.
>
That's great. Can you add this description to the draft?

One other question. In this model the options are really part of the
IP payload and not the UDP payload (so presumably this solution is not
UDP specific but can be applied to any protocol). Essentially this
another way to extend IP and so it seems conceivable that these TLVs
could alternatively be put into an IPv6 extension header to accomplish
the same effect (at least for IPv6). Have you considered the tradeoffs
for doing that?

Thanks,
Tom