Hi Chris, Thanks for your reply. No, the PR does not address the issue described below, because it keeps the use of a single kind of ACK for the two different purposes (a) retransmission requests [optional] and (b) acknowledgement of completion [mandatory]. However, it clearly describes this double-use of ACKs, which already is a good thing IMO.
However, as mentioned, given the late stage of standardization, I merely wanted to have this point raised and perhaps discussed, but didn't expect a change in the end. Unfortunately, there doesn't seem to be much interest in this, so I think one can put this to the records. Cheers, Hanno ________________________________ From: TLS <tls-boun...@ietf.org> on behalf of Christopher Wood <c...@heapingbits.net> Sent: Thursday, April 23, 2020 12:34 AM To: TLS@ietf.org <tls@ietf.org> Subject: Re: [TLS] On the two types of ACKs in DTLS 1.3 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 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
