Re: [tsvwg] design assumptions - draft-ietf-udp-options

["Black, David" <[e-mail]>]

Joe,

This is a convenient message to suggest some structuring of the discussion.

> 1- support options
> 2- allow at least some options to be silently ignored by legacy receivers (to
> enable ‘“optionally enhanced” exchanges)
> 3- allow at least some options to be required
> 4- allow the options themselves to be protected
> 5- support for fragmentation/reassembly
> 6- support for MTU discovery
> 7- support (optional?) middlebox checksum/payload length bug traversal
> 8- support LITE, i.e., where some of the payload is not covered by at least
> some checksum processing

As an individual, I think it would be useful to separate out LITE into a separate discussion topic as that would enable a focus on getting the UDP options functionality framework nailed down for the first 7 design goals, although there may be a need to acknowledge some FRAG/LITE interaction.

Thanks, --David

> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Joe Touch
> Sent: Tuesday, July 16, 2019 8:31 PM
> To: tsvwg
> Subject: [tsvwg] design assumptions - draft-ietf-udp-options
> 
> 
> [EXTERNAL EMAIL]
> 
> Getting back to the core design assumptions:
> 
> 1- support options
> 2- allow at least some options to be silently ignored by legacy receivers (to
> enable ‘“optionally enhanced” exchanges)
> 3- allow at least some options to be required
> 4- allow the options themselves to be protected
> 5- support for fragmentation/reassembly
> 6- support for MTU discovery
> 7- support (optional?) middlebox checksum/payload length bug traversal
> 8- support LITE, i.e., where some of the payload is not covered by at least
> some checksum processing
> 
> AFAICT:
> 
> #7 requires a CCO-like sum, but it MUST he calculated AFTER all other options
> are populated (it depends on the value of ALL other options and surplus
> data)
> 
> #8 can depend on everything except CCO (it doesn’t need to protect CCO),
> but it depends on the value of all other options and needs to be computed
> next-to-last (or last if CCO isn’t present)
> 
> And we need a way to know:
> 	- for #7, whether CCO is included or not used (at user’s peril, but to
> allow for transmitters to avoid work)
> 	- for #8, when to end the options (either a length field OR a EOL flag)
> 
> Are there any other design requirements?
> 
> Joe
> 
> 
> 
> 
> 
> 
> 
> 
>