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

[Tom Herbert <[e-mail]>]

On Mon, Jul 15, 2019 at 4:44 PM Joe Touch <[e-mail]> wrote:
>
>
>
>
>
> On 2019-07-15 16:14, Tom Herbert wrote:
>
> On Mon, Jul 15, 2019 at 3:01 PM Joe Touch <[e-mail]> wrote:
>
>
> ...
>
> However, header/trailer is a misnomer. It's really about whether and how much to use LITE.
>
> I disagree. We have at least thirty years experience with protocol
> _headers_ on the Internet.
>
>
> That doesn't stop every solution for UDP from being a "trailer".
>
> They either trail conventional UDP data or zero-length UDP packets (no data). Either way, they're still trailers, not headers.
>
> As I said, you can coin new words for these, but it's just misleading. What you call a "header" is really what we already have as LITE, and it's not a header.

Joe,

I am using the correct terminology. Protocol headers are protocol
bytes in a packet that precede the payload data and occur at the
beginning of a packet, protocol trailers are protocol bytes that
follow the payload data and are at the end of the packet. LITE defines
both a header and trailer, UDP Extended Header defines a header, and
UDP Surplus Trailer defines a protocol trailer. The distinction and
relevance becomes when considering how implementations process these.

Please take a look at slides "CONSIDERATIONS Things to keep in mind
when designing a new protocol" starting at slide #30 in
https://datatracker.ietf.org/meeting/104/materials/slides-104-wgtlgo-forwarding-plane-realities-00
(technology deep dive @IETF104), particularly the advice on designing
protocol headers to be compatible with routers that will inevitably
process them.

Tom

>
>
> All implementations have been tuned for
> them, and it would be naive to think that introducing protocol
> trailers in data path protocols won't cause issues with established
> deployment (some have already been highlighted).
>
>
> LITE (or your "header") isn't compatible with established deployment. It will show up as zero-length packets; it won't just "not show up".
>
> The real question here is how to interact with legacy receivers - Sec 8 already addresses that based on WG feedback. If we want to change that algorithm, fine - but there are consequences.
>
> In the current approach:
>
> - IF receiver behavior is unknown, then the only safe thing to do is use only truly optional options - ones that can be silently ignored.
>
> - If that's NOT the case, the ONLY TRULY SAFE behavior is to negotiate use of those options that are NOT optional. It simply is NOT KNOWN TO BE EQUIVALENTLY SAFE to simply send the options as part of LITE per se.
>
> LITE has its uses, but it is not a substitute for NOT SENDING A PACKET.
>
> Note that udp-opts already includes that advice.
>
>
> Joe