On Mon, Apr 6, 2020 at 7:17 AM Hanno Becker <[email protected]> wrote:
> 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. > First, let me say that in scenarios like the one you posit we have other problems besides ACK inefficiency. Specifically, DTLS doesn't do any real congestion control and so your initial window will be way too big if you broadcast a 40K message at once. So I don't think a huge amount of optimization is in order here. By contrast. we do know that DTLS retransmission is too slow and given that small flights are common, losing the ability to indicate that you lost a tail seems undesirable. ISTM that the easiest way to deal with this is to have the sender treat the current ACK state as the union of the states it has received and permit receivers to only ACK each packet once (while encouraging them to fill the ACK packet). Then you would retransmit if your new ACK state was partial rather than if the ACK was partial. -Ekr
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
