I agree with Kazuho and Christian. There were doubts raised on this list regarding the proposed protocol mechanism, and I'm surprised to see a request for a provisional registration at this point, and for an individual draft. This only seems justified if there's intent for internet-scale deployment by multiple QUIC stacks. If that's the case, I'd like to learn more about it.
In any case, allocating a (somewhat) scarce 2-byte code point before adoption seems premature to me, especially since this draft will likely go through a couple of revisions (and therefore code points). Using an 8 byte code point, as Christian and Kazuho suggested, would be the strictly better choice. On Mon, 22 Jan 2024 at 14:28, Christian Huitema <[email protected]> wrote: > > > On 1/21/2024 9:43 PM, Martin Thomson wrote: > > On Mon, Jan 22, 2024, at 16:31, Kazuho Oku wrote: > >> Regarding the code point, doesn't RFC 9000 section 22.1.2 state that > >> 4-byte or 8-byte code points should be used unless it is "especially > >> sensitive to having a longer encoding?" My feeling is that transport > >> parameters and error codes are not sensitive, as they are used only > >> once per the lifetime of a connection. > > > > That's encouragement that Q might take or not, but - as a designated > expert - I can't really say "no" on that basis. > > > >> That said, I wonder if it is necessary to request a provisional > >> registration for every individual draft. My experience has been that > >> drafts submitted to the working group are discussed and revised. Then, > >> as they mature, code points are fixed and registered. > > > > Again, if the presumption here is that this is going to be deployed, > then a code point would help and a provisional registration would help with > collision avoidance. This hasn't been discussed in this group, so the risk > of collision is perhaps higher. > > > > I haven't asked if the intent was to deploy this tweak, but we don't use > that as a condition of registration. > > > >>From my perspective, I would prefer if drafts that are seeking > deployment choose and register provisional code points. And that drafts > that are just ideas keep their code points set to 0xTBD. It's a tiny bit > of clerical work to support a deployment, but it means that we don't have > one rule for people who are discussing IETF drafts and one for everyone > else. > > > > The purpose of the BDP drafts is to manage paths with large bandwidth > delay products, and skip the O(log2(BDP/IW10)) RTT required for ramping > up the CWND to the desired value. There is really zero reason to > allocate sort code points for that. > > -- Christian Huitema > >
