Re: [quicwg/base-drafts] Connection ID Length changes (#2473)

[Kazuho Oku <[e-mail]>]

@martinduke 
> Either I have been very unclear, or I am proposing something that makes a simple error so that it is confusing everybody. Here is what I am proposing to allow (CIDs are letters)

I think it works, though I wonder why the client needs to switch to using a zero-length client CID when it migrates. Can't it just continue using a zero-length client CID?

@ianswett 
> The server can also statelessly reset the connection if it has no state by 5-tuple, as you mention above.

Please let me retract that, because it's wrong. The design of stateless reset requires the source of the reset token to not be reused. That's something the sender of stateless reset can enforce when using CIDs, but not when relying on the 5-tuple. Quoting from section 10.4.2 of the transport draft: _This design relies on the peer always sending a connection ID in its packets so that the endpoint can use the connection ID from a packet to reset the connection. An endpoint that uses this design MUST either use the same connection ID length for all connections or encode the length of the connection ID such that it can be recovered without state. In addition, it cannot provide a zero-length connection ID._

> I don't have a very strong feeling on this, but it seems like another thing we forbid that has some potentially valid uses with drawbacks we don't like. Unless we think this is actively harmful, I'd prefer to allow this.

I would not oppose to allowing it, though the premise would be that it does not introduce complexity to other implementations that would not be using the feature, because I do not understand the practical benefit.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2473#issuecomment-464410321