RE: Definition of Recovery Period End

[Nick Banks <[e-mail]>]

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:[e-mail]]
Sent: Thursday, January 18, 2018 11:30 AM
To: Ian Swett <[e-mail]>
Cc: Subodh Iyengar <[e-mail]>; Nick Banks <[e-mail]>; IETF QUIC WG <[e-mail]>
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.

Would it help to describe this in the draft?

- jana

On Tue, Jan 16, 2018 at 5:56 PM, Ian Swett <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[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]<mailto:[e-mail]>> on behalf of Nick Banks <[e-mail]<mailto:[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