Re: [quicwg/base-drafts] Required state for retaining unacked RETIRE_CONNECTION_ID frames is unbound (#3509)

[ianswett <[e-mail]>]

@kazuho I don't think not sending RCID frames is that easy.  Tracking something that needs to be sent consumes comparable state to tracking it in flight.  Or are you suggesting a different algorithm that indicates a RCID frame doesn't need to be sent?

If the peer has to wait for one Retire Prior To to take effect before it's increased again, that leaves only the peer migrating really quickly and lost ACKs as the unbounded case. As @kazuho said, I think it's more likely a well-behaved peer would run out of CIDs in this case than any other failure mode.  I previously suggested stopping sending out NCID frames when the RCID frame limit had been reached to force the issue, but that just changes who has to close the connection.

FWIW, we already have sanity checks where our implementation closes the connection when a datastructure becomes too large.  The limits are high enough that they're almost never hit unless there is a bug, but they've been helpful in finding bugs.  I would advocate everyone have these.  @marten-seemann You'll never get to 0 transport errors.  Some implementations will have a bug, and some peers or servers will have faulty or corrupted memory.  For example, in Google QUIC we found we received the ClientHello on a stream besides 1 surprisingly often.

-- 
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/3509#issuecomment-607253576