Re: [quicwg/base-drafts] Cleaning up Loss Detection overview (#536)

[ianswett <[e-mail]>]

ianswett commented on this pull request.

A few suggestions.

> -
-  * If a packet is near the tail, where fewer than kReorderingThreshold packets
-    are sent after it, the sender cannot expect to detect loss based on the
-    previous mechanism. In this case, a sender uses both ack information and an
-    alarm to detect loss. Specifically, when the last sent packet is
-    acknowledged, the sender waits a short period of time to allow for
-    reordering and then marks any unacknowledged packets as lost. This mechanism
+  * When at least one packet that was sent a threshold number of packets
+    (kReorderingThreshold) after an unacknowledged packet is acknowledged. This
+    indicates that the unacknowledged packet is either lost or reordered beyond
+    the specified threshold. This mechanism combines both TCP's FastRetransmit
+    and FACK mechanisms.
+
+  * When a short period of time has elapsed after the last sent packet is
+    acknowledged, with unacknowledged packets near the tail (fewer than
+    kReorderingThreshold packets sent after them). The sender cannot expect to

I was hoping we could combine early retransmit and time based here, just like the implementation does.  

I realize this is a bit harder to write, but maybe something like:
When a larger packet than the unacknowledged packet has been acked and the reordering threshold in time has elapsed since a larger packet was acknowledged.  In order to implement a mechanism equivalent to TCP Early Retransmit, this only applies when the acked packet is the largest sent.

>      is based on the Linux implementation of TCP Early Retransmit.
 
-  * If a packet is sent at the tail, there are no packets sent after it, and the
-    sender cannot use ack information to detect its loss. The sender therefore
-    relies on an alarm to detect such tail losses. This mechanism is based on
-    TCP's Tail Loss Probe.
+  * When a Retransmission Timeout (RTO) alarm fires. An RTO alarm is set after
+    Tail Loss Probe attempts at evoking acknowledgements (see below). When this
+    alarm fires, all unacknowledged packets are marked as lost.

Actually, they're only marked as lost when a larger packet has been acknowledged.

>  
-  * Handshake packets, which contain STREAM frames for stream 0, are
-    critical to QUIC transport and crypto negotiation, so a separate alarm
-    period is used for them.
+Handshake packets, which contain STREAM frames for stream 0, are critical to
+QUIC transport and crypto negotiation, so a separate (more aggressive) alarm

nit: I would just say "more aggressive" and drop the separate and ()

> -
-  * If a packet is near the tail, where fewer than kReorderingThreshold packets
-    are sent after it, the sender cannot expect to detect loss based on the
-    previous mechanism. In this case, a sender uses both ack information and an
-    alarm to detect loss. Specifically, when the last sent packet is
-    acknowledged, the sender waits a short period of time to allow for
-    reordering and then marks any unacknowledged packets as lost. This mechanism
+  * When at least one packet that was sent a threshold number of packets
+    (kReorderingThreshold) after an unacknowledged packet is acknowledged. This
+    indicates that the unacknowledged packet is either lost or reordered beyond
+    the specified threshold. This mechanism combines both TCP's FastRetransmit
+    and FACK mechanisms.
+
+  * When a short period of time has elapsed after the last sent packet is
+    acknowledged, with unacknowledged packets near the tail (fewer than
+    kReorderingThreshold packets sent after them). The sender cannot expect to

Reading below, i see what you're trying to do by describing standard FACK style loss detection first, and it likely makes sense.

In which case, how about "for unacknowledged packets within kReorderingThreshold from the tail." instead of "with unacknowledged..."

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/536#pullrequestreview-38789909