Subject: [tsvwg] DPLPMTU (was RE: design assumptions - draft-ietf-udp-options - trying to see the bigger picture)

From: <[email-masked]>
Date: Fri, 19 Jul 2019 05:32:23 +0000

Hi Mike, Gorry, all,

(Focusing on the DPLPMTU part) 

How the pieces are structured/described in the two documents is broken. 

udp-options has a normative dependency on DPLPMTU I-D to specify how this would work, but that document does not elaborate on the processing of UDP options. 

Cheers,
Med 

> -----Message d'origine-----
> De : tsvwg [mailto:[email-masked]] De la part de Gorry Fairhurst
> Envoyé : jeudi 18 juillet 2019 18:16
> À : C. M. Heard
> Cc : TSVWG
> Objet : Re: [tsvwg] design assumptions - draft-ietf-udp-options - trying
> to see the bigger picture
> 
> On 18/07/2019, 16:46, C. M. Heard wrote:
> > On Thu, Jul 18, 2019 at 3:39 AM Gorry Fairhurst wrote:
> > >
> > > For DPLPMTU (#6) the complexity is in another spec (which seems
> correct
> > > to me). I'd be interested whether a separate spec of Frag is also one
> > > way to ensure we get experience with the core spec, and then consider
> > > how to design Frag (#5, #8).
> >
> > For DPLPMTU the complexity is in another spec, but the tools that UDP
> > options provide for it are in the base spec. Those tools are:
> >
> > - padding for probe packets
> > - request option
> > - response option
> >
> > The request and response options are pretty straightforward, but the
> > details of how padding will be accommodated may well depend on what
> > packet format we converge to for providing other things, especially
> > FRAG.
> DPLPMTUD works best with *just* padding packets (i.e. that carry no
> payloads or fragments). It's just so much easier to run the algorithm.

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 19 Jul 2019 09:13:02 +0100

Thanks: We do need to check that,

Gorry