Re: [TLS] DTLS 1.3 ACKs

[Eric Rescorla <[e-mail]>]

On Sat, Jul 1, 2017 at 10:01 AM, Ilari Liusvaara <[e-mail]>
wrote:

> On Sat, Jun 24, 2017 at 12:05:44PM -0700, Eric Rescorla wrote:
> > On Sat, Jun 24, 2017 at 9:47 AM, Ilari Liusvaara <
> [e-mail]>
> > wrote:
> >
> > It seems ACKs work in terms of RSNs. This generates a weirdness that
> > > a fragment can be known with multiple IDs, in case a packet gets
> > > delayed enough to trigger retransmission but the original is then
> > > accepted. But OTOH, retransmission at fragment granularity is useful
> > > with potentially "obese" messages like Certificate.
> > >
> >
> > This is the calculation I made as well. Note that removing aliasing in
> this
> > fashion actually is useful in measuring packet loss (this is what QUIC
> > does).
>
> IMO, since handshake only occurs once per connection and DTLS needs to
> be implemented on all kinds of constrained devices (on both client and
> server sides), simplicity is more important than performance. Also,
> packet loss estimates do not seem useful: There are far too few packets
> to get useful statistics.
>

I think we definitely want to allow acknowledgements of subcomponents of
messages, because otherwise you have to retransmit the entire message,
which is painful in the case of the obese messages. This seems to leave
one with the option of acknowledging either fragments (which we then
need to invent labels for) or records (which already have labels
but need a map of RSN to fragment). My feeling is that on balance the
latter is a better choice, but I'll have a better sense once we've
implemented....

-Ekr