Hi Ekr, > I don't really agree with (b) for the reasons above. It introduces new > complications. As for (a) I believe that in practice the state that > must be kept is quite small (in general, there will only be no > retransmission at all and so you will only need one or slightly more > extant flight). The TLS handshake already requires you to store quite > a bit of state (hashes, etc.) so I'm not persuaded by this argument.
DTLS 1.3 should suit the case of IoT devices and lossy IoT networks, together with the long-term prospect of post-quantum cryptography and the large cryptographic material that goes along with it. In such context, it is / will be important to be able to deal with excessive fragmentation and retransmission efficiently. Moreover, note that in the face of a PMTU change, retransmission on the basis of buffered opaque record content without knowledge of the underlying handshake structure doesn't work, and will require retransmission of the entire flight. This is avoided with ACKing at the handshake level, which makes retransmissions agnostic to PMTU changes. > I think we're down to a difference of technical judgement now, so > I'll leave it to the chairs to determine how to address this comment. It would be nice to hear some more opinions on this here, too. Thanks for the discussion, Cheers, Hanno ________________________________ From: Eric Rescorla <[email protected]> Sent: Thursday, March 5, 2020 2:38 PM To: Hanno Becker <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [TLS] Record-level ACKs in DTLS 1.3 Hanno, > Hi Ekr, > > thanks for your prompt reply. > > > Thanks for your note. I don't think your proposal will be an > > improvement. It destroys information which could otherwise be used for > > improve round-trip and loss estimation (cf. the difference between > > QUIC and TCP ACKs). > > What information is destroyed that was there before? You can still > use handshake metadata in place of record sequence numbers and > do the same analysis as before. > Also, with QUIC and TCP, we're mainly talking about throughput optimization > at the application stage, where DTLS doesn't ACK anyway. If you retransmit a record with exactly the same contents, it is not possible which version was received. It's true that > > Second, it prevents the receiver from saying > > some non-sensical things like acknowledging part of a received packet. > > It's of course true that the current design allows you to ACK > >non-received packets, but that's much more straightforward to detect. > > I don't think this is actually a complication: In both cases you > have a list of messages you've sent which are tagged somehow -- either > by a record sequence number or handshake metadata which at this point > can be treated opaque -- and if you receive an ACK for a non-existent > tag, you ignore it or fail, whatever the policy. Sure, but now you just have some new artificial rule that you can't process part of a handshake message, even though you can actually say that. > Beyond that, I consider the more fine-grained ACKing at the handshake > level a benefit, because it allows to acknowledge parts of records > containing multiple handshake messages only some of which could be > processed. Example: > > +---------------------------------+ > | Seq No 1 |---------------> Received > | Fragment 0..a | > +---------------------------------+ > > +---------------------------------+ lost > | Seq No 1 |----------x > | Fragment a+1..b | > +---------------------------------+ > > +-----------------+----------+ > | Seq No 1 | Seq no 2 |-------------------> Received > | Fragment b+1..N | complete | > +-----------------+----------+ > > If this happens with an implementation which only supports contiguous > reassembly (I think GnuTLS does it this way, or at least used to), it > will drop the second fragment, but the second message might still be > buffered and hence ACK'ed. With record-level ACKs, such fine-grained > ACKing isn't possible, and HS Seq No 2 will need to be resent even > though it has been received. Yes, I agree that this is true, however, those implementations have already decided that they favor implementation simplicity over high performance, so I don't think this consideration is relevant here. > > I don't think your proposal will be an improvement. > > I uphold this: ACKing at the handshake level does not lead to complications > while (a) easing memory efficient implementations for IoT devices and > (b) increasing conceptual clarity by avoiding the current semantic ambiguity > of record level ACK with dependency on implementation-specific handshake > level details like buffering and reassembly strategy. I don't really agree with (b) for the reasons above. It introduces new complications. As for (a) I believe that in practice the state that must be kept is quite small (in general, there will only be no retransmission at all and so you will only need one or slightly more extant flight). The TLS handshake already requires you to store quite a bit of state (hashes, etc.) so I'm not persuaded by this argument. I think we're down to a difference of technical judgement now, so I'll leave it to the chairs to determine how to address this comment. -Ekr 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 [email protected] https://www.ietf.org/mailman/listinfo/tls
