Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-09.txt

[Joseph Touch <[e-mail]>]

Hi, all,

This update includes the following. 

It omits the reordering of the FRAG header intended to support zero-copy until we converge on the new format. I believe that capability may still be useful, but if we prefer, it can be omitted.

Many thanks to Gorry and Tom Jones for their detailed feedback, which has been incorporated or addressed by the changes as well.

Joe

UDP option notes

CHANGES
Fixed numerous typos, including the section numbering issue
New UNSAFE option for sender indication of options that it expects to be implemented:
If UNSAFE is encountered and not supported, it halts option processing and causes it to fail, so no further options are processed
The packet is passed to the app layer with all options processed up to that point indicated, including the UNSAFE one that triggered the condition
Core options are never UNSAFE because they’re always implemented
OCS can say “if I fail, stop option processing here and deliver the core”, but that’s not the same as UNSAFE
Actually, only OCS should stop in its tracks based on the value competed; everything else should just log what happens
Any option can say “if the option itself fails somehow, then drop/ignore” but that should default to ACCEPT (except for OCS, which defaults to drop)
I.e., UNSAFE is only relevant to whether an option is known, not what happens if it fails
Revised FRAG (integrates previous FRAG and LITE)
Unknown UNSAFE options before FRAG cause FRAG to be ignored  (but others don’t, so you CAN OCS or AUTH components before reassembly) **as a side effect of UNSAFE **
When FRAG fails, the packet processing continues, as with any other failed but supported options (i.e., options after FRAG still happen and the data - if any - would be delivered, or a zero-length packet)
If FRAG is first, it supports RDMA-like avoidance of user data copy (as before), but not if it is not first (which should only happen with UNSAFE options, which means data needs to be copied anyway)
In general, however, options are:
Ignored individually if not supported
Flagged as failing if supported but computes incorrect checksum, etc.
The RECEIVER decides what to drop
The default is NOT to drop (legacy behavior) but CAN be overridden
all options to be ignored if any one FAILS due to format / parsing or OCS failure
BUT NO options can prevent UDP data from going to the app by default
Apps that care can override that default
Options that should “share fate” with UDP data must be designed as UNSAFE options
There are NO currently defined UNSAFE options, FWIW
Fixed OCS description to include the surplus length pseudo header 
Also removed the claim that this would zero-out in ones complement (with surplus length, it does not)
Reiterated that the “coordination” of alignment is intended to emulate computation as if aligned to the UDP header
Clarify that failed ACS is NOT silently dropped by default
Recovers can override if desired
Default behavior works like legacy
Packet would still carry a flag allowing app to drop if desired too
Clarified that ACS and AE cover the UDP payload
Clarified that AE, like ACS, should silent drop unless configured otherwise
RFC6081 Teredo defines use when UDPlen >> IPlen-IPhdr
This is confusing; it implies Teredo processing ignores the IP length and uses UDP as an override
It won’t traverse non-Teredo routers (an errata might be appropriate?)
It is inconsistent with our approach (and so noted)
This doc now updates ROHC 3095 too
puts it in line with more recent header compression standards that we caught
UDP header compression should ever have assumed that UDP Length is implicit based on IP length

> On Nov 25, 2020, at 4:09 PM, [e-mail] wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transport Area Working Group WG of the IETF.
> 
>        Title           : Transport Options for UDP
>        Author          : Joe Touch
> 	Filename        : draft-ietf-tsvwg-udp-options-09.txt
> 	Pages           : 36
> 	Date            : 2020-11-25
> 
> Abstract:
>   Transport protocols are extended through the use of transport header
>   options. This document extends UDP by indicating the location,
>   syntax, and semantics for UDP transport layer options.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-09
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-09
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
>