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

[Joe Touch <[e-mail]>]

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…

Joe

PS =  yes, we talk about TLV but need to explain that some options are exceptions (OCS, NOP, EOL). I also need to update the OCS to be 3 bytes long (in the table and figure). Those are in addition to the issues below.

-------

Raffaelo and Mike both pointed out:

> On Mar 9, 2019, at 5:23 AM, C. M. Heard <[e-mail]> wrote:
> ...
> the errant middleboxes that CCO is designed to work around do not use the
> correct length value in their (re)computation of the UDP checksum. ...

Well, there are several implications here:

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)

2. we don’t need OCS alignment; what we do need is to “coordinate” the alignment of a 16-bit of the length to the OCS checksum field
	i.e.:
	- calculate the length needed (IPlen - UDP len)
	- if OCS checksum field is not 16-bit aligned to the start of the option area, then swap bytes
	- add the result to the OCS checksum (‘pseudo header’ seems a bit heavy here, but same point)

As Derek noted:
> As I recall the LITE+FRAG use case has no data in the UDP payload
> (i.e UDP header length is zero)?
> 
> For this case, there is another way to work around a broken path (be it
> boxes, NICs, or whatever), that is simply to send with UDP header checksum
> of zero, and contain any necessary checksums in the UDP slack space.


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

Thoughts?

also Derek noted:

> The OCS/CCO case can cover that, except for the LITE (w/o FRAG) case.
> 
> For the latter I guess we could also use UDP checksum of zero, and have
> an option to restore a proper checksum for the UDP data at the receiver,
> however that will still leave legacy receivers experiencing such packets
> as unchecksumed.


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.

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.

------