Subject: Definition of Recovery Period End

From: Nick Banks <[email-masked]>
Date: Wed, 17 Jan 2018 00:35:53 +0000

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

---

From: Subodh Iyengar <[email-masked]>
Date: Wed, 17 Jan 2018 01:10:10 +0000

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 <[email-masked]> on behalf of Nick Banks <[email-masked]>
Sent: Tuesday, January 16, 2018 4:35:53 PM
To: IETF QUIC WG
Subject: Definition of Recovery Period End

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

---

From: Ian Swett <[email-masked]>
Date: Tue, 16 Jan 2018 20:56:37 -0500

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 <[email-masked]> wrote:

> 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 <[email-masked]> on behalf of Nick Banks <
> [email-masked]>
> *Sent:* Tuesday, January 16, 2018 4:35:53 PM
> *To:* IETF QUIC WG
> *Subject:* Definition of Recovery Period End
>
>
> 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
>

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 18 Jan 2018 11:29:36 -0800

Nick,

To clarify, "recovery period" is defined in the context of loss recovery
and congestion control. The congestion controller is expected to take
congestion action on loss. However, it should be careful to hold off on
future congestion actions until this action propagates through the network.

More precisely, the Reno congestion controller will reduce its rate when
the sender detects loss, and should only reduce its rate again if the new
rate is too high... that is, another loss is detected on packets sent
*after* the rate reduction. Feedback on the new rate takes about an RTT of
time, and is measured as the time period between sending the first packet
after a loss is detected to when that or a subsequently sent packet is
acked. This is the recovery period. It is not meant to indicate when all
losses are recovered from.

Would it help to describe this in the draft?

- jana

On Tue, Jan 16, 2018 at 5:56 PM, Ian Swett <[email-masked]> wrote:

>> 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

---

From: Nick Banks <[email-masked]>
Date: Thu, 18 Jan 2018 19:33:15 +0000

Thanks for all the additional information. It all makes sense. While not completely necessary, I do think it would be a bit helpful to add those details on exactly what recovery period means and what it is trying to accomplish.

Thanks again,
- Nick

From: Jana Iyengar [mailto:[email-masked]]
Sent: Thursday, January 18, 2018 11:30 AM
To: Ian Swett <[email-masked]>
Cc: Subodh Iyengar <[email-masked]>; Nick Banks <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Definition of Recovery Period End

Nick,

To clarify, "recovery period" is defined in the context of loss recovery and congestion control. The congestion controller is expected to take congestion action on loss. However, it should be careful to hold off on future congestion actions until this action propagates through the network.

More precisely, the Reno congestion controller will reduce its rate when the sender detects loss, and should only reduce its rate again if the new rate is too high... that is, another loss is detected on packets sent *after* the rate reduction. Feedback on the new rate takes about an RTT of time, and is measured as the time period between sending the first packet after a loss is detected to when that or a subsequently sent packet is acked. This is the recovery period. It is not meant to indicate when all losses are recovered from.

- jana

On Tue, Jan 16, 2018 at 5:56 PM, Ian Swett <[email-masked]<mailto:[email-masked]>> wrote:
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 <[email-masked]<mailto:[email-masked]>> wrote:

Subodh

________________________________
From: QUIC <[email-masked]<mailto:[email-masked]>> on behalf of Nick Banks <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 16, 2018 4:35:53 PM
To: IETF QUIC WG
Subject: Definition of Recovery Period End

Thanks,

- Nick Banks