Subject: [tsvwg] UDP options list of issues

From: Joe Touch <[email-masked]>
Date: Sun, 4 Mar 2018 14:39:37 -0800

Hi, all,

IMO, we would benefit popping up a level to the list of issues and summarizing our views.

Here’s my attempt to do that.

Joe

———

Some assumptions:
	a) overhead is useful to minimize (efficiency and may reduce or avoid fragmentation)
	b) LITE capability must be preserved
	c) LITE+FRAG capability must be preserved
	d) this solution is not expected to outperform TCP (i.e., this is not an opportunity to redesign transport from scratch)

- TLV vs fixed header
	motivated (AFAICT) by the desire to enable hardware optimization and/or to detect error/misuses of spare area
	no clear hardware benefit (given the option area “floats” relative to the UDP header, 
	which floats relative to the IPv6 header TLV chain, and given it may not be word aligned)
	no clear benefit regarding packet errors or other spare area uses 
	(both require either CS works or TLV chain parses, neither of which is likely for random errors or other misuses)
	fixed wastes at least 2 bytes if CS isn’t used, (maybe 4-6 if supporting LITE/LITE+FRAG)

- Optional CS vs. mandatory
	motivated (AFAICT) by the desire to avoid processing packets with errors (accidental or by others misusing the extra space)
	optional is needed to correlate to lack of UDP checksum (for some types of tunnels, e.g.)
	mandatory also implies fixed (above), which incurs 2-6 bytes of overhead	

- option-area checksum details
	size
		8 if TLV, 16 if fixed; no clear problem with either choice
	algorithm
		no clear issue with using minor mods (foldover for 8 bit, invert or not)
		there are known dangers to using the complement of the sum 
		(such that the sum and data zero-out), as noted by the Partridge paper in the 90s.

- EOL vs option length field
	length would have to be 2 bytes; EOL is an optional one byte (not needed if no spare area remains)
	EOL thus saves up to 2 bytes when not needed (and it should generally not be needed at all)
	allowing EOL (i.e., allowing remaining unused spare area) implies that processing needs to stop at some point, 
	either based on a counter or the data seen (and given that a CS loads data into a register anyway, there’s no clear performance win to either approach)
	EOL itself is patterned after the TCP option of the same name
	and yes, leaving the spare area available for future use by other protocol extensions is intended here

- does CS end when EOL is seen?
	yes, as currently specified
	as noted above, leaving the spare are for future standards is a goal

My conclusion is that all the choices above either fail to improve the situation vs. our current proposal or increase overhead (or both). I don’t yet see a reason why any of them warrant a change vs. the existing approach.