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

[Derek Fawcus <[e-mail]>]

On Tue, Feb 28, 2017 at 11:29:09a.m. -0800, Joe Touch wrote:
> Note - one of the caveats is that I'd really like to see this become a
> WG doc. at some point.

Seems like a good idea.

> On 2/28/2017 8:37 AM, Derek Fawcus wrote:
> > On Mon, Feb 27, 2017 at 03:30:59p.m. -0800, Joe Touch wrote:
> >
> > 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

Well that was just the order from which I'd chose the mandatory set,
I wasn't necessarily suggesting that all be mandatory.

For me the suggested mandatory additions would probably be MSS and FRAG,
then possibly TIME due to the timing points with reassembly which
you mention.

> > Section 5.3 (Option Checksum)

> > 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, 

I view requiring it to always be present is a sensible choice
as that allows for some level of validation that the surplus
area actually is options.  As I believe you mention later
in the draft.

> but could be turned off to save space -
> though I'm not sure why that amount of space would matter).

Quite.  I'd say the cost/benefit weighs in favour of using
the space to always have the options summed.

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

Sorry,  I've lost the thread here.

I was not suggesting altering how the normal UDP checksum works.

I was mainly driving at how in implementing this in a host stack I'd
like to verify the options.  Namely that in the absense of the Lite
option,  it would allow one to use the existing checksum validation
routine to run across the whole of the surplus area, and if it summed
to the usual (1's complement) zero,  it is good.

In the presence of Lite option it only becomes slightly more complex,
in that one performs the check as two partial sums.

This could be combined with whatever logic is extracting/detecting
the presence of the options.  That would obviously requiring using
the usual 1s complement of the 1s complement sum.  It would have
to occur before normal UDP processing, and be driven off the UDP
length and the IP header payload length being different

[I'm assuming the presence of a routine like:
   uint16_t ip_partial_checksum(uint16_t old_sum, void *start, uint16_t length)
 which sums the supplied range in to the old_sum, returning the new value.
 Initialisation and final 1s-complement being done outside that routine.
]


Or are you referring to existing implementations of your current
option code?

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

The reference to middle boxes was an unimportant side comment,
please forget I mentioned it.

The significant point was allowing the same style of checksum
as already exists, and hence using the same (or similar)
set of routines.  Especially since if we assume the checksum
is always present, it costs no more in terms of payload that
the 8 bit scheme.

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

I'm fine either way.

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

Tom's suggestion here was interesting.  It would seem to be
re-defining the FRAG+LITE case where the UDP User Data is zero length,
such that the LITE is now segmented,  and non-Lite.  I'm not sure
about that yet,  it feels a bit weird.

However, the overall checksum he mentioned could itself be in an
option,  and would only need to be in one of the fragments.

DF