On Wed, Nov 25, 2020 at 02:29:55PM +0100, Kashyap Thimmaraju wrote:
> I was not part of the mailing list (but I am now :)) when you replied
> so I've had to manually copy your responses. Below I've included the
> person's name and replied to their comments/remarks.
>
> > Dmitri Tikhonov
> > I ran some experiments myself and I realized that my original guess was
> > incorrect. lsquic server retires the Initial DCID a short time after
> > handshake succeeds. When a CID is retired, all incoming packets bearing
> > it are dropped.
> >
> > lsquic keeps CIDs retired for at least 30 seconds and at most forever
> > (old entries are purged opportunistically when new entries are added.)
>
> Good to know. We did some experiments and it seemed to persist for over a
> day. However, we did not try to connect with other CIDs so that could
> explain why they remained for so long.
Yes, that's exactly how it happened. The underlying data structure's FIFO
component drops old entries after some threshold is reached.
> > I looked for guidance in the Transport Draft for how long a CID is to
> > stay retired (both Initial DCID and those retired via the
> > RETIRE_CONNECTION_ID frame), but found none.
>
> So for lsquic, the problem is about a CID being stuck in the retired state?
Yes: there was no upper limit on the amount of time that a CID was retired.
This has been fixed in lsquic 2.24.4 [1].
Thank you again!
- Dmitri.
1. https://github.com/litespeedtech/lsquic/releases/tag/v2.24.4
