marten-seemann / draft-seemann-quic-nat-traversal

Other
15 stars 4 forks source link

Management of connection ID and rounds #31

Open huitema opened 3 months ago

huitema commented 3 months ago

It seems that servers have two ways to limit the number of ongoing attempts: they can use the "rounds" mechanism, or they can control the number of CID provided to the client. The draft is a bit silent about that, merely asking for "enough CID".

In RFC 9000, the way to get more CID is to retire the unused ones. Logically, that should happen after an attempt is cancelled. Retiring is normally effective after only a "draining" timer -- typically 3*RTO, but that's an imperfect mechanism. What happens if a path challenge is delayed and arrives after the CID has been retired? Will that trigger a stateless reset?

If we consider the multipath extension, I assume that abandoning an attempt means abandoning the path number used in the attempt. That will be synchronized with the peer (bilateral abandon), and will trigger provisioning of new CID (life is good, if slow).

In both cases, there is a pacing mechanism -- there wont be enough resource for new attempts until the RETIRE_CID or PATH_ABANDON have been processed, which include a 3*RTO timer. Given that pacing mechanism, I wonder whether we need to worry with rounds, etc.