Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

[Joe Touch <[e-mail]>]

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

> On Mon, Jul 15, 2019 at 10:02 AM Joe Touch <[e-mail]> wrote: 
> 
>> On 2019-07-15 09:39, Tom Herbert wrote:
>> 
>> On Mon, Jul 15, 2019 at 9:15 AM Joe Touch <[e-mail]> wrote:
>> 
>> On Jul 15, 2019, at 8:50 AM, Tom Herbert <[e-mail]> wrote:
>> 
>> On Sun, Jul 14, 2019 at 8:52 AM Joe Touch <[e-mail]> wrote:
>> 
>> So, *given* that we *are* different from UDP and TCP, i.e., we do NOT have the luxury of a fixed-offset location for this checksum
>> 
>> Joe,
>> 
>> There's no requirement that precludes defining a fixed header that
>> precedes the surplus space.
>> 
>> It clearly can't be a fixed location. Thats all I was asserting.
>> 
>> Or do you disagree?
>> 
>> In draft-herbert-udp-space-hdr-01 the checksum is a header that
>> precedes the surplus space.
>> 
>> I don't understand why this is confusing, so I'll be blunt:
>> 
>> - OCS WILL NOT come at a *fixed offset* from the UDP header
> Joe,
> 
> On that I agree. But, draft-herbert-udp-space-hdr-01 proposes to put a
> checksum, which is not OCS, in a fixed header at the beginning of the
> surplus space that covers the whole surplus.

Sorry, but you're not following where were are with the UDP options. 

1) we already agreed (in the past week) to make the OCS field mandatory 

2) OCS always covered the entire option space 

3) we already agreed that there would NOT be any surplus space beyond
the options, i.e., that options would take up the whole surplus space 
(anyone who wants to use surplus space should coordinate with the UDP
options using that mechanism, as I noted when evaluating your proposal
as not necessary) 

NOTE: we still can use EOL to halt option processing, but the assumption
is that the remainder is *ignored*, not there for other uses. If that's
an issue, we can omit EOL. 

**Given that context**, all that remains regarding OCS now are the
following questions (which is why I started with them and hope to get
back to): 
- OCS at head or tail of the surplus space 
- OCS aligned, and if so, at what level (16-bit, 32-bit) 

NOTE1: your claims about offloading driving alignment seem to be
undermined by the need for using an untenable 255-byte offset from the
beginning of the UDP packet (not the surplus space - whose start offset
itself *varies from packet to packet* relative to the UDP header, unlike
the UDP checksum). 

NOTE2: *as repeatedly already noted*, again - GIVEN THIS CONTEXT - there
is no utility in the additional pre-option header proposed in
draft-herbert-udp-space-hdr-01. 

Joe 

>