Re: Definition of Recovery Period End

[Subodh Iyengar <[e-mail]>]

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