Re: Definition of Recovery Period End

[Ian Swett <[e-mail]>]

Nick, this is a very good question.

Initially, this was chosen because it was the most straightforward mapping
of TCP's behavior.

This has some pros and cons.  The major con is that it makes direct
comparison to TCP more difficult, particularly when loss rates are high.  A
positive is that QUIC can reduce it's CWND(and sending rate) more rapidly
in the face of high loss and may provide more consistent performance in
cases when the CWND is large, so observing a loss within an epoch is common.

The intent is that the QUIC approach to recovery is an ideal embodiment of
the spirit of the original TCP algorithms for recovery.  If we have any
data that indicates they don't work well in practice, I'd be happy to
consider changes to the recovery draft.

On Tue, Jan 16, 2018 at 8:10 PM, Subodh Iyengar <[e-mail]> wrote:

> All of the loss recovery modes that QUIC has have the following property
>
>
> if packet n is lost, then packet n - 1 must also be lost.
>
>
> This is true both in the threshold and time reordering based recovery.
>
> A newly sent packet in loss is triggered by either sending a TLP or RTO.
>
> If you get an ack for a new packet without getting the acks for all the
> other sent packets, QUICs threshold loss recovery will kick in and confirm
> that the packets that were sent before were lost.
>
>
> So I believe you don't need to wait for all the information to be ACKed
> once you get an ack for the latest packet. An argument could be made that
> the ack for the new packet might not trigger loss
>
> of all the packets, however it will definitely trigger QUIC's early
> retransmit timer, which will trigger the future loss.
>
>
> Subodh
>
>
>
>
> ------------------------------
> *From:* QUIC <[e-mail]> on behalf of Nick Banks <
> [e-mail]>
> *Sent:* Tuesday, January 16, 2018 4:35:53 PM
> *To:* IETF QUIC WG
> *Subject:* Definition of Recovery Period End
>
>
> Asking this on here per recommendation on GitHub:
>
>
>
> According to the spec, recovery starts with detection of a lost packet and
> ends with the acknowledgement of a single, newly sent packet. Why isn’t
> recovery ending only after all the information in the frames that were lost
> prior to the recovery period have been acknowledged? This way would seem
> more inline to what TCP does today.
>
>
>
> For instance, if 4 packets worth of STREAM frames and a MAX_DATA frame
> were lost, why shouldn’t recovery last until all that data had been resent
> and acknowledged?
>
>
>
> Thanks,
>
> - Nick Banks
>