On 09/04/2020, 15:18, "Eric Rescorla" <e...@rtfm.com> wrote:
> > On Thu, Apr 9, 2020 at 6:59 AM Thomas Fossati <thomas.foss...@arm.com>
> > wrote:
> > On 09/04/2020, 14:20, "Eric Rescorla" <e...@rtfm.com> wrote:
> > > Assuming I understand Hanno's proposal, I do not believe that this
> > > is in fact an improvement, as it does not cover the important case
> > > where the record containing the SH is lost and then the rest of
> > > the messages from the server are uninterpretable.
> >
> > I don't want to speak for Hanno here but the refinement proposed in
> > [1], specifically the bit that says:
> >
> > [...] They may also proactively retransmit parts of a flight early
> > if an ACK message indicates a gap.
> >
> > should cover the case you mention I think.
>
> 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.
(But again, I'm not him and that's why I suggested collecting all the
pieces of this discussion together in one PR.)
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
