Re: [tsvwg] New Version Notification for draft-herbert-udp-space-hdr-01.txt

[Joe Touch <[e-mail]>]

Re-sending the full response this time: 

On 2019-07-10 15:17, Tom Herbert wrote:

> On Wed, Jul 10, 2019 at 12:24 PM Joe Touch <[e-mail]> wrote: 
> 
>> On 2019-07-10 11:36, Tom Herbert wrote:
>> 
>> ...
>> The UDP surplus header provides alignment,
>> 
>> UDP options already has NOPs for that.
> The NOPs align the options to the start of surplus. If the surplus
> space is unaligned to begin with then there's no point to using NOPs
> to align individual options.

That's already supported in the UDP options. They can start with NOPs
too. 

>> integrity check,
>> 
>> UDP options already has a OCS for that.
> 
> A one byte optional checksum is next to useless as an integrity check.
> This has already been brought up in reference to OCS.

It was changed to 2 bytes before the last IETF, between v5 and v6 (we're
on v7; the doc table does need to be updated, but the text is accurate
and no longer talks about folding it over). 

>> disambiguation for other uses of surplus space,
>> 
>> This isn't needed. It won't support existing uses (not that any are known) because they won't follow the format.  UDP options already allows for experimental uses and other standards-track extensions through codepoint assignment.
> 
> If the checksum fails then surplus space isn't processed. So,
> probability of misinterpretation of some random use of surplus space
> is < 0.0015%.

See above. 

>> a means to extend the UDP header,
>> 
>> Actually, it hinders UDP options by limiting them to 1020 bytes, as with all "other uses".
> That is intentional. Allowing unlimited options is a path towards DOS attack.

There are only 256 codepoints; options you don't support you skip over.
And only NOPs can be repeated and only up to 3x in a row. 

And if you see enough of these with options you don't know or care
about, maybe you should throttle. 

One thing we do know is that any fixed size limit WILL be insufficient.

>> friendliness with HW and SW implentations,
>> 
>> It has no benefit vs. the existing approach in this regard.
> The checksum ensures that the surplus space sums to zero...

We've already been over this and the updated text already does EXACTLY
the same thing, except that it doesn't need alignment to work. 

> ... Along similar lines, a per packet checksum is
> much better than the fragmentation checksum since we can offload the
> former and not the latter.

That remains one of the items that we're waiting for others to comment
on, ones we're NOT discussing because we're still wasting time on this. 

--- 

In summary, please look at the current draft and note that OCS is now 3
bytes. That is incorrect in the table (we already noted that on the
list; it's in the next round of opdates) but not in the text of the OCS
section. 

Joe