Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-07

[Derek Fawcus <[e-mail]>]

On Sat, Mar 09, 2019 at 11:28:57AM -0800, Joe Touch wrote:
> This one’s a bit long - we need to converge quickly if the draft is going to be updated in time for the cutoff.
> 
> Please comment asap…

Sorry - I've been otherwise occupied; and hence this isn't a complete response...

> 1. we can add in the option length, BUT that also means:
> 	(a) we need to declare that the option area consumes the whole of the surplus area (no chance for other uses)
> 	OR
> 	(b) that the surplus area is always zero
> 	OR 
> 	(c) that OCS covers even the surplus area (it doesn’t need to be zero; it does need to be included)
> 
> 	we need a choice here. AFAICT, the safest (a)

I agree on (a); but then I was never convinced on the possibily of other users,
as future users would still need to be able to parse these options, in which case
why would they not use them?

The only use I could see for leaving surplus for non option use
would be in the case of there being an option indicating
'the rest of the surplus is X', for some X.

So really what we lose is the ability to have an option of more
than 255 bytes.

> 3. we have to deal with LITE/LITE+FRAG 
> 	we *can* use UDP CS=0, but that also may involve overriding the user’s desires here (i.e., the user API says “use UDP CS” and we’re not doing that)
> 	which means we have a choice:
> 	(d) override so that things work, i.e., force UDP CS=0 and then
> 		(d.1) do OCS as a check on our stuff only
> 		OR
> 		(d.2) disallow the use of OCS (if CS=0, what’s the point?)
> 		OR
> 		(d.3) use OCS=0 (this seems like a waste)
> 	OR
> 	(e) ignore the user setting of CS, then:
> 		(e.1) always do OCS as a check
> 		OR
> 		(e.2) if UDP CS=0, omit OCS (save space), basically like d.2 
> 		OR
> 		(e.3) if UDP CS=0, use OCS=0 (basically like e.2
> 
> If we do any of the (e) variants, we could either:
> 	(f.1) require users to disable UDP CS to use OCS
> 	OR
> 	(f.2) ignore the user UDP CS setting
> 
> So which is it?
> 
> I don’t like assuming user correct configuration (f.1).
> 
> So to me it’s (f.2) and (d.1). 

I'd split LITE w/o FRAG from LITE with FRAG.

The latter would not involce overriding the users choice of there being no CS,
as there is no UDP data as such.  The only thing we'd lose is a check on the
pseudo-header, so maybe encode that somewhere in the LITE+FRAG combo, dare I
say as another option?

So for LITE+FRAG, I'd agree (f.2) and (d.1)

[As an aside, the only guarenteed way I've found to send w/o UDP checksum
 using the sockets API is by using RAW sockets.]

> 5. the LITE only case
> 
> The whole point of LITE is that some of the IP payload isn’t checksummed. 
> 
> > Given that we're supposed to veryify such receivers can accept
> > LITE (w/o FRAG) and hold soft state, maybe this is acceptable?
> 
> 
> We don’t have a requirement that such receivers can accept LITE before we start using it, so soft state won’t help here.
> 
> > we can send
> > LITE (w/o FRAG) using UDP checksum of zero, and the additional
> > option encoding the actual checksum for the UDP data.
> > 
> > This additional checksum could simply be the existing defined
> > ACS option.
> 
> ACS uses a CRC, not IP checksum. That’s a LOT more work in software, so this isn’t a viable alternative.

Actually, my original thought here (which I then culled), was to have another
option, or ACS.  That other option would encode the current style of checksum,
so for concerns about CPU cost of using CRC, we could mitigate it.

What I had in mind was an option containing two 16 bit fields, one would
encode the partial-checksum for the pseudo-header as the originator sent
it, the other the partial-checksum for the original UDP payload.

e.g.:  [ Type = Frag-Chks | Len | part-phdr-chk | part-data-chk ]
  
That way the receiver can recover from any NAT mangling of the packet which
would otherwise mess with the checksum calculation.

i.e. for the UDP portion, assuming the packet was encoded with UDP CS=0

  1. Calculate partial checksum for pseudo-header as received
  2. Compare to option part-phdr-chk
  2a. If equal verify UDP data against part-data-chk
  2b. If differ verify UDP data against part-data-chk + (part-phdr-chk - phdr-chk)

The implementation of that can probably be optimised.

> IMO, we leave this one alone. The whole point of LITE is to do less work - if that means the LITE data corrupts the entire packet, then so be it. Then LITE basically fails.

However, I do agree that the LITE w/o FRAG case (incl. when using the proposed
UDP CS=0 encoding) needs more consideration, and so am happy to leave that
to a later revision of the draft.

Especially as it would be good to avoid having the OCS/CCO option encoding
the LITE data, but I'm not sure how we achieve that.  Maybe this is one of
the cases where we simply have to accept it will not pass through broken
middle devices?  Which would be a pity, but it may still pass through
more than UDP-Lite does.

i.e. maybe LITE w/o FRAG would simply have to be like in the current draft,
and using no clever encoding tricks for CCO discovered problems?

We already have the case that we won't pass through broken devices which
drop packets where there is any slack space.

DF