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

[Joe Touch <[e-mail]>]

On 11/2/2015 8:17 AM, [e-mail] wrote:
> Sorry I wasn't at the meeting yesterday in Japan
> 
> - Block packets (perhaps firewalls, for instance), but also truncate
> (which may be more common on devices doing incremental checksum update).

Sure, which ought to be safe.

> - I expect the default behaviour is either to copy UDP-L; which means you
> lose the options (i.e., truncate - sad but not disaster) or IP-L; which
> means you get all (the same as UDP-Lite).

For end systems, the only behavior we've seen so far is to copy the UDP
portion (i.e., in legacy mode) and ignore the extension area.

Joe

> 
> Gorry
>>
>> On 11/1/2015 10:43 PM, Tom Herbert wrote:
>>> On Mon, Nov 2, 2015 at 3:05 PM, Bob Briscoe <[e-mail]> wrote:
>>>> Joe,
>>>>
>>>> Before starting measurements, I would recommend searching the Web for
>>>> the manuals of middleboxes that might block such packets.
>>>>
>>> Please look at NIC offloads also. I am pretty certain that the most
>>> common flavor of checksum offload will break in this proposal since
>>> devices use the value in the UDP length field as the length of the
>>> payload to compute the checksum over.
>>
>> That is the intended behavior.
>>
>>> UDP Fragmentation Offload would
>>> similarly be broken, although we can probably live without that (but
>>> we can't live without checksum offload!).
>>
>> 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.
>>
>> Joe
>>