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

[Tom Herbert <[e-mail]>]

On Wed, Mar 20, 2019 at 3:58 PM Joe Touch <[e-mail]> wrote:
>
>
>
> > On Mar 20, 2019, at 7:34 AM, Tom Herbert <[e-mail]> wrote:
> >
> > On Wed, Mar 20, 2019 at 3:25 PM Joe Touch <[e-mail]> wrote:
> >>
> >>
> >>
> >> On Mar 19, 2019, at 1:37 PM, Tom Herbert <[e-mail]> wrote:
> >>
> >> Gorry,
> >>
> >> Suppose we create a compression option whereby UDP payload is compressed and decompressed at the receiver.
> >>
> >>
> >> See the rules in Section 7 - which are there specifically to avoid this sort of tangle.
> >>
> > From section 7:
> >
> >>> At the sender, new options MUST NOT modify UDP packet content
> >   anywhere except within their option field; areas that need to remain
> >   unmodified include the IP header, IP options, the UDP body, the UDP
> >   option area (i.e., other options), and the post-option area.
> >
> > So that would seem to mean we'll never be able to add any interesting
> > options like the payload compression I described.
>
> Yes, but for a very specific reason.
>
> If you do, you then have to decide on what content every other option would operate - pre-compression or post. I suspect you’d say pre, but if more than one option does that, you’re dead.
Joe,

The order of the options can dictate how the operations are applied to
the data. In any case, I think this is unnecessarily limiting the
extensibility of the protocol, and it's divergent compared to other
protocols containing options like destination, HBH options, Geneve
options, TCP, that don't have this limitation. It will be interesting
to see what the consensus of the WG will be on this.

Tom

>
> Joe