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

[Joe Touch <[e-mail]>]

Hi, Derek,

Thank you for the feedback.

Below are my responses...

Note - one of the caveats is that I'd really like to see this become a
WG doc. at some point. I'd prefer to have running code and got very
close this past fall (the issue was student cycles, not protocol
design), FWIW.

Joe


On 2/28/2017 8:37 AM, Derek Fawcus wrote:
> On Mon, Feb 27, 2017 at 03:30:59p.m. -0800, Joe Touch wrote:
>> A new version of the UDP options proposal has been posted.
> I quite like the described scheme,  a few comments below:
>
>
> Section 5 question on must implement:
>
> Personally I'd say the most interesting / useful are (in order):
>   MSS, FRAG, TIME, LITE, ACS, AE
> So that would inform my choice of which to make mandatory

The set I picked are the minimum required to make the option work. OCS
is included because it is default-on, as per previous discussions.

I'm glad to have the WG determine what others would be required. IMO, it
wouldn't be hard to make MSS, FRAG, TIME, LITE, and ACS required. AE is
completely specified (believe it or not - all that was required was to
declare the ISN values to substitute for UDP for traffic key
generation), but it's also clearly very heavyweight compared to the rest
of the options.

> Section 5.4 (Alternate checksum):
>
> By inference one can deduce that 'UDP payload only'
> must refer to the data region which figure 3 names as the
> 'UDP user data', and hence also excludes any Lite data.
> Maybe this (UDP user data) should be explicitly stated?

Good point - I'll clarify. It will be the same data covered by the
current UDP checksum (UDP header, UDP payload as indicated by the UDP
header, and IP pseudoheader).

> Also which CRC16?  I've seen a few.  Maybe state its polynomial?
Good point - I don't have a preference, but I'll pick one in common use.

> Section 7 (UDP options vs. UDP-Lite):
>
> 4th para seems to refer to a prior scheme for a LITE
> option.  
Yes -

> With the described swap mechanism,  there is
> no need for an EOL option (for Lite purposes),  and
> the Lite data ends up directly following the normal
> data vs this text stating they are disjoint.

Agreed - I'll clean that up. The EOL option still needs to be included
(IMO) for similar reasons to the TCP option - to help shortcut option
processing when trailer padding is used (e.g., for word-aligned payloads).

> So this could be reduced to just the portion comparing
> the default delivery (or not) of the Lite data.
Agreed. Will do...

> Section 5.3 (Option Checksum)
>
> It looks like the described scheme was needed for
> compatibility with a prior version of the Lite
> mechanism.
This came out of WG discussions, notably because the option area is not
covered by the UDP checksum. It predates the inclusion of the Lite
mechanism and has no relation.

> You could simplify the option checksum handling by
> simply defining the first 2 bytes of the surplus
> area as a 16 bit checksum over the whole of the
> surplus area while in its Figure 10 form, i.e. not
> including the Lite data.
I agree with the second point (simplified processing), but not the first
(requiring OCS), unless we agree that OCS is always required (it is not
right now; it is default active, but could be turned off to save space -
though I'm not sure why that amount of space would matter).

> This would be compatible with the LITE swap scheme
> you describe in section 5.5, just with one having
> to swap 6 bytes rather than 4 bytes.  It would also
> take no more space than the existing checksum - assuming
> such was always included.
It takes two additional bytes - we can't redefine the existing checksum
and be compatible with legacy receivers.

> I can see that this would make the job of a middle
> box which chose to modify an option (say MSS clamping) easier,
> but I'd suggest the main gain is simply following
> a more familiar scheme of the same 16 bit ones complement
> as elsewhere (even if not negated as one usually does).
I don't want to design a transport protocol capability based on what a
middlebox might do. That's "laws for the lawless", IMO, and there's
little point. So I'd rather not address this.

> Section 5.1 (End of Options List)
>
> Given the above change to the options checksum, and the
> stale text in section 7, it would seem that there is no
> need for the EOL option,  and NOP could become 0; however
> that probably doesn't matter either way.
I'm in favor of keeping EOL because the code to handle it is easy and it
might enable other capabilities in the future (i.e., available space
after the header). It might be useful to mention that.

> Section 5.8 (Fragmentation)
>
> A trivial point,  but should this be referred to a segmentation instead?

I'm fine with whatever the WG prefers.

> I forsee the confused conversations in future when one is
> refering to UDP fragments, or Fragmented UDP and having
> to clarify if one means an IP fragment or this transport
> level fragmentation scheme.
>
> Figure 15 shows a 64 bit Identification field, yet the text
> refers to a 32 bit field.  Which is correct?
32. I think larger isn't needed. I'll fix that...

> If fragmentation is present with Lite, and two such packets
> are received to be reassembled, what happens to the Lite data
> from each packet?  Should this combination be rejected, or
> defined in some fashion?
Good point. I'll think about this and create an ordering list.

> I've not really looked at Seciton 5.9, as I'd need to refresh
> myself on the TCP option behaviour.
OK - glad to have that feedback too.

-----