On 06/04/2020, 02:49, Martin Thomson <m...@lowentropy.net> wrote:
> I think that you are assuming a lot about how the loss recovery part
> of the sender is operating here.
>
> If you receive ACK { 1, 3 }, then it might be reasonable to assume
> that 2 got lost, but it seems to me that assuming anything about 4 is
> premature.
The spec as currently written says that the signal "ACK {1, 3}" means
"retransmit {2, (3, end]}":
Upon receipt of an ACK for only some messages from a flight, an
implementation SHOULD retransmit the remaining messages or
fragments.
This works as expected only if the sender can assume that the receiver
has let enough time pass before generating ACK {1, 3}, but this is not
strongly stated in the description of receiver behaviour.
We should keep in mind that DTLS implementers are not necessarily
transport experts, and that warrants a bit more care in what we say as
well as what we don't say. In particular, we should try hard to avoid
expert bias.
One example where we can improve: we have a nice sentence about bunching
ACKs at 25% of current RTO halfway through bullet 2 of Section 7.1. In
fact, avoiding knee-jerk ACKing is one of the basic things to understand
here. Incidentally, this is how one's solves Hanno's conundrum above
(at least in non-pathological cases) because "retransmit {2, (3, end]}"
would be generated when the receiver has got some confidence about 4 &
co. being actually lost. Unfortunately, the sentence is oddly placed
and one tends to overlook it and not giving it the high and general
relevance it actually has.
> The sender can also make some adjustments, without necessarily
> adhering to a strict interpretation of the recommendations in the
> spec.
Agree again, but deciding to violate a SHOULD should be an exception,
not the rule. If I have to implement this, especially on very
low-bandwidth paths that fragment a lot, I probably would never follow
the recommendation: I'd first re-send 3 and sit back for a while waiting
for further ACKs before resending (3, end].
> The draft is imprecise about this logic intentionally. It recommends
> that the sender send missing data, which will likely work, and be
> fast. For large flights, yes, this will be suboptimal, but we are
> also assuming that this data is not subject to congestion control
> limits.
Just a note: "large flights" is relative to the available bandwidth so
(very) low-bandwidth would always have suboptimal recovery even if HS
data is not congestion controlled. And that's the environment where you
absolutely want to have a reliability scheme that is bandwidth
efficient.
> If we go to PQ schemes with large amounts of data, then that requires
> a different set of assumptions. It might also require that
> implementations take extra steps to avoid the resulting
> inefficiencies.
True that.
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
