Re: [TLS] Record-level ACKs in DTLS 1.3

[Eric Rescorla <[e-mail]>]

Hanno,


> Hi Ekr,
>
> thanks for your prompt reply.
>
> > Thanks for your note. I don't think your proposal will be an
> > improvement. It destroys information which could otherwise be used for
> > improve round-trip and loss estimation (cf. the difference between
> > QUIC and TCP ACKs).
>
> What information is destroyed that was there before? You can still
> use handshake metadata in place of record sequence numbers and
> do the same analysis as before.
> Also, with QUIC and TCP, we're mainly talking about throughput
optimization
> at the application stage, where DTLS doesn't ACK anyway.

If you retransmit a record with exactly the same contents,
it is not possible which version was received. It's true that




> > Second, it prevents the receiver from saying
> > some non-sensical things like acknowledging part of a received packet.
> > It's of course true that the current design allows you to ACK
> >non-received packets, but that's much more straightforward to detect.
>
> I don't think this is actually a complication: In both cases you
> have a list of messages you've sent which are tagged somehow -- either
> by a record sequence number or handshake metadata which at this point
> can be treated opaque -- and if you receive an ACK for a non-existent
> tag, you ignore it or fail, whatever the policy.

Sure, but now you just have some new artificial rule
that you can't process part of a handshake message,
even though you can actually say that.


> Beyond that, I consider the more fine-grained ACKing at the handshake
> level a benefit, because it allows to acknowledge parts of records
> containing multiple handshake messages only some of which could be
> processed. Example:
>
>     +---------------------------------+
>     | Seq No 1                        |---------------> Received
>     | Fragment 0..a                   |
>     +---------------------------------+
>
>     +---------------------------------+     lost
>     | Seq No 1                        |----------x
>     | Fragment a+1..b                 |
>     +---------------------------------+
>
>     +-----------------+----------+
>     | Seq No 1        | Seq no 2 |-------------------> Received
>     | Fragment b+1..N | complete |
>     +-----------------+----------+
>
> If this happens with an implementation which only supports contiguous
> reassembly (I think GnuTLS does it this way, or at least used to), it
> will drop the second fragment, but the second message might still be
> buffered and hence ACK'ed. With record-level ACKs, such fine-grained
> ACKing isn't possible, and HS Seq No 2 will need to be resent even
> though it has been received.

Yes, I agree that this is true, however, those implementations
have already decided that they favor implementation simplicity
over high performance, so I don't think this consideration
is relevant here.


> >  I don't think your proposal will be an improvement.
>
> I uphold this: ACKing at the handshake level does not lead to
complications
> while (a) easing memory efficient implementations for IoT devices and
> (b) increasing conceptual clarity by avoiding the current semantic
ambiguity
> of record level ACK with dependency on implementation-specific handshake
> level details like buffering and reassembly strategy.

I don't really agree with (b) for the reasons above. It introduces new
complications. As for (a) I believe that in practice the state that
must be kept is quite small (in general, there will only be no
retransmission at all and so you will only need one or slightly more
extant flight). The TLS handshake already requires you to store quite
a bit of state (hashes, etc.)  so I'm not persuaded by this argument.

I think we're down to a difference of technical judgement now, so
I'll leave it to the chairs to determine how to address this comment.

-Ekr