Hi folks, For the context of this email, I have no particular opinion about this draft. Using a larger codepoint seems better for early stage work.
Zooming out a bit: we've now gathered a bit of experience for people trying to use QUIC codepoints. The guidance in RFC 9000 is correct and IANA designated experts are applying it well. However, there's a bit of a gap in explaining the sort of pattern of evolution Christian and Kazuho describe. I have a task to try and document that better (on the quicwg.org page for now) so that there's a bit more clarity and consistency. I'll send a draft for review once I have something. Cheers Lucas On Mon, Jan 22, 2024, at 12:09, Q Misell wrote: > Hi all, > > This appears to have caused quite the controversy. > > > 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?" > > Indeed it does, I somehow managed to completely miss that. I shall update to > an 8-byte codepoint in this case. > > > 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. > > That is entirely the reason for my request. Given that there are plentiful > codepoints I though registration prudent to remove the possibility of a clash. > > Thanks, > Q Misell > > Any statements contained in this email are personal to the author and are not > necessarily the statements of the company unless specifically stated. > AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, > Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered > in Wales under № 12417574 > <https://find-and-update.company-information.service.gov.uk/company/12417574>, > LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 > <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU > VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: > 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru > maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca > Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: > EE102625532. Glauca Digital and the Glauca logo are registered trademarks in > the UK, under № UK00003718474 and № UK00003718468, respectively. > > > > On Mon, 22 Jan 2024 at 07:55, Marten Seemann <[email protected]> wrote: >> 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
