Re: [Edm] Few comments on draft-edm-protocol-greasing-02

[Lucas Pardue <[e-mail]>]

Hi Cullen,

Thanks reading and sending feedback.

On Tue, Oct 31, 2023 at 12:57 AM Cullen Jennings <[e-mail]> wrote:

>
> At a high level this document looks fine and I have no complaints with
> publishing it more or less as is. However, I do see one significant area
> that I think would improve it. I imagine this has been discussed before so
> take with large grain of salt.
>
> My experience with interoperability problems across a wide range of
> protocols is mishandling of code points is far less often the problem that
> breaks the future and a much more common issue is:
>
> 1) incorrect assumptions on ordering of options and/or,
> 2) incorrect assumptions that the bits will forever land in the same
> location in the packet.
>
> I view both designing and exercising the protocol to deal with these
> issues as a form of “greasing”. I wish the draft talked about that.
>

This is, to my mind at least, what Section 4 should by covering under the
term protocol variability (because greasing has a quite tight definition).
I agree that it is often not enough to stick a random value in the same
byte offset of every connection. Instead tweaking time and space is
probably going to unearth false expectations or edge case errors (some
examples we've discussed in meetings).

Do you have some concrete examples of the issues (1) and (2)? The protocols
I'm familiar with don't tend to see these issues much, possibly because
things are encrypted and/or the formats don't lend themselves to that. It
sounds like your's are slightly different and would be good to capture
and/or consider.


> I think the draft could be a bit more concrete on exactly how to write
> IANA sections.


So we summarise how QUIC did things in Section 3 [1]. However, that's
just one example. Does it suit other protocols that have different IANA
registries? I'm not so sure.


>
> On the trivial nits category, it seems like this draft could be much
> shorter and be very concrete about the recommendations. To put it bluntly,
> one of the LLM summary tools I used made content that I liked better. I’m
> not volunteering to do it but it might be worth of pass of “how much can be
> removed” from the draft. This is deeply an editorial comment and not
> something I care much about one way or the other.
>

I'll always admit to my early drafts having the opportunity for judicious
editing. The sections are currently walls of text and some editorial chops
and reformatting could no doubt improve the readability - I'm up for that.

However, my understanding of the scope of the document is that we're trying
to fill in blanks left by Maintaining Robust Protocols [2] and Long-Term
Viability of Protocol Extension Mechanisms [3], targetting a wide range of
protocols. Some of that new text is targetted at protocol authors but
other text is targetted at implementers. And I'm not sure how much we can
concretely tell that latter group. For example, when it comes to
variability such as "split data over several PDUs just to make sure your
peer is robust", that immediately creates tension with wanting to minimise
PDU overheads for e.g. performance.

So far the examples are pretty QUIC oriented because that's where several
of the contributors experiences have occurred. I'm not convinced we can
draw too many conclusions from just those - this stuff isn't always cut and
dry in my experience. Even among QUIC implementers some folks will GREASE
and some won't. Their implementation or deployment reasons for picking
either are justified.


>
> No change needed for just as FWIW feedback, the draft failed to convince
> me that a large range of code points for greasing was going to offer much
> benefit over a very small number of code points.


This is a fair observation. What sort of text might convince you?

The argument goes that if its too easy to hard code N grease values as
exceptions, then that's what people will do. Then when somebody starts
sending an actual code point in extension space, it causes the receiver to
error out. We could add more text to explain why but that seems contrary to
your above comment that we should be shorter with more concrete
recommendations :-D In the case of QUIC - we have several codepoints that
can have 2^62 possible values. To me, that's in the realm of "imagine
infinity" and if we picked something like 1-30 GREASE codepoints, the
easiest thing for people to do is just hardcode them rather than worry
about infinity.

Cheers
Lucas

[1] -
https://www.ietf.org/archive/id/draft-edm-protocol-greasing-02.html#section-3-5

[2] - https://www.rfc-editor.org/rfc/rfc9413
[3] - https://www.rfc-editor.org/rfc/rfc9170