Re: [TLS] DTLS 1.3 ACKs

[Ilari Liusvaara <[e-mail]>]

On Sun, Jul 02, 2017 at 02:00:51PM -0700, Eric Rescorla wrote:
> On Sun, Jul 2, 2017 at 1:13 PM, Ilari Liusvaara <[e-mail]>
> wrote:
> 
> > There can also be interactions with giving up on fragment transmissions
> > (in order to limit memory usage).
> >
> > Suppose similar case as before, but 2:1 gets lost instead of disappearing,
> > and is found after 2:5 is received by the client.
> >
> > The client will then generate second ACK, which ACKs 2:1. The server then
> > receives the ACK and has no idea what the client is talking about, since
> > server has dropped the state. But presumably fast-retransmits 2:4 and 2:5,
> > now as 2:6 and 2:7 (3rd transmission for both).
> >
> 
> It's not clear to me it's useful for implementations to delete state in
> this case.

As said, this would be to limit memory usage. I suppose real cheap
implementation could check for the first missing fragment and retransmit
from that point onwards, regardless if any subsequent fragment was ACKed.

I suppose if one really wants to scrimp on state, one combine the
fragments of small messages (basically, everything except Certificate)
in fixed way (ClientHello, HelloRetryRequest and ServerHello likely fit
into one fragment, EncryptedExtensions and CertificateRequest likely
jointly fit into one record, the same for CertificateVerify and
Finished). And then assign RSNs for retrasmissions with fixed base
(which impiles that RSN sequence might have gaps).





-Ilari