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

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

Joe,

Still as an individual ..

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

Hmm - if that's what's going on, could we adopt that as the design goal/scope/rationale for LITE, and focus LITE discussion on that?

In other words, I'm suggesting that LITE's only purpose in this round of design would be to support FRAG, with DNS as a motivating use case for FRAG, so that all the other clever things that LITE might be good for are out of scope.  Is that reasonable?

Thanks, --David

> -----Original Message-----
> From: Joe Touch <[e-mail]>
> Sent: Wednesday, July 17, 2019 11:11 AM
> To: Black, David
> Cc: tsvwg
> Subject: Re: [tsvwg] design assumptions - draft-ietf-udp-options
> 
> 
> [EXTERNAL EMAIL]
> 
> 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
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >