Re: Definition of Recovery Period End

[Jana Iyengar <[e-mail]>]

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