Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

[Tom Herbert <[e-mail]>]

On Thu, Jul 18, 2019 at 10:59 AM Gorry Fairhurst <[e-mail]> wrote:
>
> On 18/07/2019, 18:25, Tom Herbert wrote:
> > On Thu, Jul 18, 2019 at 9:56 AM Joe Touch<[e-mail]>  wrote:
> >>
> >>
> >>
> >>
> >> On 2019-07-18 08:35, Tom Herbert wrote:
> >>
> >> ...
> >>
> >> A single bit in the option type to indicate that the option can be
> >> skipped if unrecognized should be sufficient.
> >>
> >> Tom
> >>
> >>
> >>
> >> That bit has two meanings:
> >>
> >> - for legacy receivers, it's simply ignored for legacy data
> >>
> >> - for option-aware, if the flag is set, what does it mean?
> >>    - it should never mean drop the legacy data, otherwise an options-aware endpoint can't decide to act as legacy
> >>    - it could mean drop non-legacy data
> >>
> >> Right now, the onus is on the receiver to decide what to do with the data.. The info is passed to the user - NOT decided by UDP.
> >>
> >> I.e., cuurrently:
> >>
> >> - unknown options are ignored by both legacy and option-aware endpoints
> >> - UDP processing skips over all such options
> >> - users can decide/negotiate what to do with those options on a per endpoint basis
> >>
> >> Note: the first time you send something, if you want a response to help you know what the endpoint will do, you need to set "ignore" anyway, which is what the default does. Otherwise you won't get a response and won't know why (the packet could have been dropped).
> >>
> >> So this only makes sense for negotiated soft-state anyway, at which point the user can either configure the endpoint UDP socket to drop if unknown or accept.
> >>
> >> Why would we NOT give the user this choice?
> >>
> > Joe,
> >
> > Consider that someone invents the compression option a year from now.
> > The option cannot be ignored by a receiver since delivering compressed
> > data to the application would be jibberish. So someone starts using
> > compression and performs a "soft-state" negotiation with a timeout of
> > 30 seconds in the example algorithm you previously described for
> > soft-state negotiation. So the sender is sending compression option to
> > some receiver. But, at some point, say 10 seconds into a timeout
> > period, the receiving host changes to a different configuration that
> > doesn't support the compression option-- maybe the host address is
> > virtual IP and packets are now routed to a different backend, or maybe
> > someone reboots the receiving hosts with a new configuration.
> > The
> > sender doesn't know the receiver has changed and continues sending the
> > compression option. The new receiver sees the options but doesn't
> > recognize it.
>
> > If the receiver ignores the option and delivers the data
> > to the application then that's data corruption. That's not robust.
> That's where I disagree. I think anything that is not a native UDP
> packet MUST be carried in the options space. That's where I would
> suggest we put the compressed payload. if that means the main payload
> area isnothing", then that would be OK for me.
>
That's already assumed. If there are any options that can't be ignored
then the UDP Length = 8 format must be used. If processing options
fails then the packet can be dropped.

> When the remote endpoint fails to process the compressed payload (or
> myseriously the option si stripped/ignored - how, but don't worry), then
> the app doesn't respond. It times out and does something.
>
Remote endpoint or remote application? We can't give an application
the compressed payload.

> Personally, unless there was a strong desire to be unidirectional (then
> you have to live with that), I'd send an option to the other end to
> solicit a little feedback - or do the same at the app layer.
>
You can do that, but bear in mind that UDP is a stateless protocol.
The feedback you get from one probe exchange might be completely
invalid on the very next packet sent. Any information gleaned about a
peer can only be considered advisory.

> Gorry
> > The "drop packet on unknown option" is the conventional and cheap way
> > to avoid situations like this and make stateless options robust.
> Not sure how that now helps?
>
> The receiver already ignores unknown options.

I believe that's the problem. There some options that cannot be
ignored and still maintain correctness. This is already a known issue
with other protocols.

Tom

> > Tom
> >
> >> Joe
> >>
> >>
> Gorry
>