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

[Joe Touch <[e-mail]>]

Hi, David,

I would agree with your point on #8 LITE were it not that #8 is the basis for the only way we have to accomplish #5 Frag while satisfying #2.

I.e., these items are not individual; they’re linked together. I haven’t made a full diagram, but:

#5 frag is critical to our driving use cases, e.g., the basis of needing options, i.e., #1 opt
#5 frag depends on #8 LITE to satisfy #2 legacy
#5 frag depends on #6 MTU to determine how to frag
#7 is important - at least for the short term - to get around middleboxes checksum computation bugs
#4 is important whenever UDP CS != 0
#3 is important to the use of some options that either cannot (eg., those that can’t do #2 legacy) or should not (e.g., ACS, AE) be ignored

So:

1 depends on 4, 5 (which depends on 2 (which depends on 3), 6, and 8) and 7

I.e., they’re all tied together.

Joe


> On Jul 17, 2019, at 6:32 AM, Black, David <[e-mail]> wrote:
> 
> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>