On Wed, 4 Feb 2026 16:43:46 -0500 Daniel Zahka wrote: > On 2/4/26 3:45 PM, Willem de Bruijn wrote: > > Daniel Zahka wrote: > >> In the case of tx rekeying, as soon as we install the new tx key, we > >> have no use for the previous one, and it can be disposed of > >> immediately. > > So this defines a rekey event as an instant in time. An alternative > > choice is to rekey at a specific seqno. > > > > The difference matters only for retransmits. > > > > Not sure there is a strong reason for either. But probably good to > > state the choice explicitly. > > I suppose if we think about a rekey as occurring at a seqno we could do > away with the deferred key deletion, and instead just wait for data sent > before that seqno to be ack'd before deleting the key. I would say if > nothing else that would be a significant improvement over what I have > right now.
If you mean the driver xmit problem - not sure this changed much, a (spurious) retransmission may theoretically still be queued on the driver ring when data is acked.
