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

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



>  QUIC uses a combination of ack information and alarms to detect lost packets.
 An unacknowledged QUIC packet is marked as lost in one of the following ways:
 
-  * A packet is marked as lost if at least one packet that was sent a threshold
-    number of packets (kReorderingThreshold) after it has been
-    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.
-
-  * 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

I'm finding "a threshold number of packets" really hard to parse.  I think that you want to say that a packet is declared lost when a packet with a significantly higher packet number is acknowledged.  (This is an area where packet number skipping really hurts us.)

> -    number of packets (kReorderingThreshold) after it has been
-    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.
-
-  * 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.

`[citation needed]`


> -
-  * 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 know that I'm tired, but I simply cannot parse this sentence at all.  I can't offer advice on how to make this comprehensible, but I do think that you need to explain that this isn't loss according to the definitions of the reordering threshold and RTO.  This is a way of using the dead air after transmission ceases to more proactively repair gaps near the end of the transmission.

Structurally, I think that you want to come at this differently.  There are two elementary parameters: the reordering threshold and the retransmission timeout.  Explain those first.  Then explain the limitations of those mechanisms: when the sender has nothing more to send, reordering no longer works, which slows repair toward the end of a transmission.  Repairing gaps near the end on a shorter timer ensures that you don't fall back on the relatively slow RTO.  Preemptively retransmitting data in an additional packet triggers that shorter timer and can be used to provide redundancy for trailing data.

>  
-  * Instead of a packet threshold to tolerate reordering, a QUIC sender may use
-    a time threshold. This allows for senders to be tolerant of short periods of
-    significant reordering. In this mechanism, a QUIC sender marks a packet as
-    lost when a packet larger than it is acknowledged and a threshold amount of
-    time has passed since the packet was sent.
+The above mechanisms use a packet threshold to tolerate
+reordering. Alternatively, a QUIC sender may use a time threshold. This allows

I think that we need to be clearer about how the time threshold plays into this.  I would prefer to see the reordering and time thresholds described together.  If it makes sense in some cases to disable the time threshold, then describe those conditions.  If it makes sense to disable the time threshold except for certain scenarios, you can effectively disable the time threshold by increasing its value.

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

I would say shorter rather than more aggressive.  "Aggressiveness" isn't really a property we care about. 

General comment: if you intend to talk about specific tuning variables (as you do for the reordering threshold), please be consistent about referencing all of those variables.

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