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
