[TLS] On the two types of ACKs in DTLS 1.3

[Hanno Becker <[e-mail]>]

Hi all,

I am aware that we're late into the standardization of DTLS 1.3, and
likely too late for any intrusive change, but I'd still like to share
another comment on the proposed ACKing scheme and its implication on
complexity of migration from DTLS 1.2 to DTLS 1.3, in addition to the
aspect discussed earlier regarding handshake-level vs. record-level ACKs
(https://mailarchive.ietf.org/arch/msg/tls/O0pghTnz_8q1AiHSeMSzxZg30RM/)

As it stands, there are two quite different kinds of ACKs sharing
the same wire-format:

1. ACKs as 'retransmission requests'

   Consider the following two excerpts from the draft:

   A:
   "When an implementation receives a partial flight, it SHOULD generate
    an ACK that covers the messages from that flight which it has
    received so far."

   B:
   "Upon receipt
    of an ACK for only some messages from a flight, an implementation
    SHOULD retransmit the remaining messages or fragments."

   This means that ACKs should be sent only on signs of disruption,
   and that receivers of partial ACKs are supposed to immediately
   retransmit.

   In particular, this precludes recurring use of ACKs where an ACK
   is generated for each message as it comes in and is processed:
   Indeed, implementations behaving this way would trigger multiple
   retransmissions on the peer, provided the peer obeys (B), even
   if there's not a single packet-loss or reordering occurring.

   In this sense, the above ACKs are 'negative' and should not be
   seen at all during a disruption-free handshake.

   Note, also, that handshakes will continue to progress if this
   kind of ACKs is entirely ignored, which amounts to falling back
   to how DTLS 1.2 handles retransmissions, purely on the basis
   of timeouts and implicit acknowledgement.

2. ACKs as 'acknowledgement of completion'

   In contrast to the previous kind of ACK, those ACKs are 'positive'
   in that they indicate completion of a handshake, and they are
   mandatory in that a handshake will not complete unless they are
   used. In particular, an implementation MUST support those kinds
   of ACKs.

At the moment, both kinds of ACKs are handled in the same way on the wire,
and in order to even distinguish them an implementation has to maintain
accurate knowledge of the sequence numbers of records it has sent.

In particular, even if implementations decide to not make use of
type-1 ACKs -- that is, retransmission requests -- it doesn't buy
them anything in terms of code-size and simplicity, because they
still have to implement type-2 ACKs, and detecting those requires
implementing record sequence number bookkeeping.

I believe that this will harden migration of DTLS 1.2 stacks to DTLS 1.3,
because it makes the minimal difference between a compliant DTLS 1.3
implementation and a pair of "DTLS 1.2 + TLS 1.3 logic" quite large.

In contrast, if retransmission requests and completion-ACKs were treated
differently, and in particular easily distinguishable on the wire, then
migration from a pair of DTLS 1.2 + TLS 1.3 stack to a minimal compliant
DTLS 1.3 would only require implementing 'completion-ACKs', which, since
they convey only a single bit of information, can in principle have a
much simpler wire-format than what we have for ACKs today.

I would be interested in comments from implementors, esp. for stacks
targeting embedded / constrained environments.

Cheers,
Hanno

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.