Hey Martin,
Thanks a lot for your reply!
> I think that you are assuming a lot about how the loss recovery part of the
> sender is operating here
My assumptions follow what the spec says SHOULD be done, though - nothing more
and nothing less.
> 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
I agree, but again this is what the spec unambiguously does by saying
implementations SHOULD resend the complement of what was ACKed.
I think in principle we agree on reasonable measures for improving the ACK
efficiency. However, I disagree with the assessment that the scheme
as-described provides sufficient efficiency for common uses, since large
fragmentation and low MTU networks will be a common characteristic for IoT
deployments, and DTLS 1.3 'out of the box' implementations should suite these,
where by out of the box I mean implementations that do precisely what the spec
says they SHOULD do.
On first sight, an easy improvement seems to be mentioning/recommending
implementations to buffer ACKs for some time, but we have to be careful with
this since it affects the semantics of ACKs in a major way which may lead to
interoperability issues: If ACKs are buffered on the receiver, they can be sent
recurringly, and also be split. This way, they are no longer 'negative' in the
sense that they indicate a disruption, as is the case now. If, in turn, ACKs
are not necessarily buffered but trigger immediate retransmission,
implementations should not use them recurringly.
Thus, in a nutshell, leaving the question of whether ACKs should be buffered or
not on the receiver to the implementor, leads to interoperability issues.
Cheers,
Hanno
________________________________
From: TLS <tls-boun...@ietf.org> on behalf of Thomas Fossati
<thomas.foss...@arm.com>
Sent: Monday, April 6, 2020 12:01 PM
To: Martin Thomson <m...@lowentropy.net>; tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] Efficiency of ACKing scheme
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
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
