Hi,
Apologies for the late reply.
First, let me say that foremost I wanted to highlight the potential
efficiency problem with the current solution. The mentioned alternative
isn't yet fully thought through, so it may well have drawbacks itself
that render it no better than the current version. However, in any
case I'd hope we can in the end find a solution which doesn't suffer from
the current inefficiency, as this seems prohibitive for IoT deployments.
Replying to Ekr's initial comment first:
> 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.
I agree, something along those lines should work and I was attempting that
with the proposed text, though spelling out the details doesn't seem entirely
straightforward. For example, we don't want to retransmit immediately if we
receive an ACK such that the new cumulative ACK state is partial, because
otherwise we'd retransmit many times while building up the ACK state. The
proposed text therefore recommends to retransmit after a sufficiently
long period during which no further ACK is received.
Receivers, in turn, may send ACKs one-by-one, though it is encouraged
to fill them, as you said.
So if I understand your comment above correctly, it appears
to be in line with the intention of the proposed new text.
Note that the proposal leaves it open whether receivers send
ACKs recurringly, even if everything is transmitted perfectly,
or only when they notice a disruption. The only recommendation
I think the text should make is that once an implementation decides
to start ACKing, it shouldn't leave a too large time-gap between
two consecutive ACKs: This is for the recommended heuristic of
"retransmission on ACK-less period" on the sender to work.
Best,
Hanno
________________________________
From: Thomas Fossati <thomas.foss...@arm.com>
Sent: Thursday, April 9, 2020 4:12 PM
To: Eric Rescorla <e...@rtfm.com>
Cc: Hanno Becker <hanno.bec...@arm.com>; Rob Sayre <say...@gmail.com>;
tls@ietf.org <tls@ietf.org>; Thomas Fossati <thomas.foss...@arm.com>
Subject: Re: [TLS] Efficiency of ACKing scheme
On 09/04/2020, 15:34, "Eric Rescorla" <e...@rtfm.com> wrote:
> > > But this requires being able to send an empty ACK that means "I
> > > got nothing". In which case, I don't see how it's really different
> > > from the current text except that it gives the sender less
> > > guidance.
> >
> > Not sure there's an "empty ACK" in Hanno's proposal. This is how I
> > interpret it in the context of your example: in the second flight,
> > if rec#0 (containing SH) is lost and rec#1 gets through, the
> > receiver sends ACK {1}. From that the sender can infer the gap and
> > retransmit rec#0.
> >
> > You can't send ACK{1} because you can't decrypt it because it is
> > out of order with respect to the DH key. This is the point of the
> > empty ACK.
True, so you send ACK{} (as per last para of Section 7.1) and similarly
the receiver can deduce a gap -- indeed a very precise one -- and
re-send record containing the SH.
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
