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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
