Hi Thomas! > That said, as currently written, this doesn't seem to work particularly well on paths that are lossy, slow, and with small MTUs (or a combination thereof), which we need to make sure it's reasonably well covered as it happens to be one of our main use cases. > I'm inclined to say this could be solved by profiling the reliability scheme for constrained networks (in I-D.tschofenig-uta-tls13-profile),
Given we agree that there is a significant inefficiency in the ACKing scheme as stated, I'd prefer we try to improve the spec now provided we find a not too intrusive way to do so, and not postpone the problem. After all, it seems that there isn't much to be changed if we go for option 2 from the original post, which perhaps isn't far off from the original intention anyway: * Sending ACKs: ACKs may be sent for any record immediately, but it is recommended to bunch ACKs and in particular send them on any sign of disruption.. * Receiving ACKs: Upon receipt of an ACK, implementations should note which messages have been received and omit them from future retransmissions. It is up to the implementation to decide when to retransmit and what to retransmit, but it is recommended they retransmit after a period of time during which no further ACK messages have been received. They may also proactively retransmit parts of a flight early if an ACK message indicates a gap (note, though, that in this example one would only retransmit the gap, not the gap + tail as before). The decisive difference to the current draft is that this takes away the character of ACKs as retransmission requests (resulting from the recommendation of immediate retransmission upon receipt of a partial ACK), while it retains flexibility as to how exactly the scheme is implemented. Cheers, Hanno Cheers 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 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
