On 06/04/2020, 15:16, "Hanno Becker" <hanno.bec...@arm.com> wrote: > 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).
Looks like a sound proposal to me. The only problem I see with this is that recovery from tail loss is not efficient, which might or might not be a problem, depending on the loss pattern of your path. 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
