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

[Christopher Wood <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>