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

[Martin Thomson <[e-mail]>]

martinthomson requested changes on this pull request.

BTW, I didn't see a notification when the extra commits were pushed.  Sorry about taking so long to get to this.

I think that some of this depends on @ianswett, so this should be a reminder to look at this again.  This is generally an improvement, so I'd like to see it merged, but it's a little hard to follow as it is.

>  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

This is still very hard to parse for me.   Does this work?

"If a packet is received, packets with significantly lower packet numbers (determined by kReorderingThreshold) that have not been received are marked as lost.  This mechanism combines both TCP's ... [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

"If a short period of time has elapsed since the last packet was sent and there are fewer than the reordering threshold (kReorderingThreshold) packets that have been sent since the highest acknowledged packet.  A sender will not be able to detect loss based on the reordering threshold in this case, so these packets are considered lost based on a timer.  This design is based on the Linux implementation... [citation needed]"

>  
-  * 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 can't see any change in response to this comment.

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

As above, no change apparent here.

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