Hi Hanno, I believe this (now merged) PR addresses your concerns:
https://github.com/tlswg/dtls13-spec/pull/140 Best, Chris On Fri, Apr 3, 2020, at 5:08 AM, Hanno Becker wrote: > 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 > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
