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

[Tom Herbert <[e-mail]>]

On Tue, Feb 28, 2017 at 12:46 PM, Derek Fawcus
<[e-mail]> wrote:
> 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.
>
Agreed, probably want to stick with the normal 16-bit Internet
checksum it will probably be more efficient since we've optimized
implementation of that anyway.

>> > 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.
>
Pretty much all NICs now days can set/verify UDP checksums on TX/RX so
we basically get it for free. This is why I doubt we'll ever see
UDP-lite in real deployment-- it is far less efficient than using the
UDP checksum. In a similar vein, applying a checksum over a packet
that is then fragmented is not easily supported in HW, for TX it
requires TSO logic for RX we might be able to deduce the reassembled
checksum from the checksummed individual fragments but it's a lot of
work. I think the LITE functionality is probably here for
completeness. CRC might be more interesting though.

Tom