Re: [tsvwg] Alternative version of the UDP FRAG option

[Tom Herbert <[e-mail]>]

On Mon, Mar 18, 2019 at 7:43 AM C. M. Heard <[e-mail]> wrote:
>
> On Sat, Mar 16, 2019 at 9:06 AM Tom Herbert wrote:
> > Thinking about this, it occurs to me be that the LITE option isn't
> > needed. The assumption in the UDP options draft is that a receiver
> > needs the UDP payload to immediately follow the UDP header, but the
> > UDP payload can be anywhere in the surplus area as long as it's
> > aligned to four bytes. A receiver will know how to handle it and
> > deliver the UDP data to the application (e.g. by maintaining a pointer
> > to the data).
> >
> > So that allows a format like:
> >
> > UDP header (Length=8) | Surplus area header | Options | Payload
> >
> > The surplus area header contains the header length and a checksum
> > covering the surplus space (four bytes altogether). The three headers
> > can thought of as an extended UDP header, so the format becomes:
> >
> > Extended UDP header | Payload
> >
> > Which looks a whole lot like any other protocol format with a variable
> > length header such as TCP or IPv4.
>
> A major downside to this approach is that is does not let you add
> "optional to process" options such as MSS, Echo Request, and Echo
> Response to UDP datagrams that are intended to be processed normally
> by legacy receivers that do not understand UDP options or the extended
> UDP header format. You can do that with the option trailer as
> currently proposed.

Mike,

The converse is also true. We can't put options in a trailer that
*must* be processed by the receiver (fragmentation, compression,
security, etc.).

Tom

>
> Mike Heard