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

[Derek Fawcus <[e-mail]>]

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

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?

Also which CRC16?  I've seen a few.  Maybe state its polynomial?


Section 7 (UDP options vs. UDP-Lite):

4th para seems to refer to a prior scheme for a LITE
option.  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.

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

Section 5.3 (Option Checksum)

It looks like the described scheme was needed for
compatibility with a prior version of the Lite
mechanism.

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.


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.

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).

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.

Section 5.8 (Fragmentation)

A trivial point,  but should this be referred to a segmentation instead?

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?

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?


I've not really looked at Seciton 5.9, as I'd need to refresh
myself on the TCP option behaviour.


DF