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

From: janaiyengar <[email-masked]>
Date: Wed, 17 May 2017 13:56:06 -0700

Addresses comments from Ian and Martin in #397 
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/536

-- Commit Summary --

  * Addresses comments from Martin and Ian

-- File Changes --

    M draft-ietf-quic-recovery.md (59)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/536.patch
https://github.com/quicwg/base-drafts/pull/536.diff

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

---

From: ianswett <[email-masked]>
Date: Wed, 17 May 2017 14:39:48 -0700

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

---

From: janaiyengar <[email-masked]>
Date: Wed, 17 May 2017 15:30:58 -0700

janaiyengar commented on this pull request.

I think we should document the "simpler" packet based ones for now, and if we can describe the time-based ones separately, then that's useful too. But we should keep them separable so (i) it's easier to reason about, and (ii) it's easier to implement if you only want to implement one.

-- 
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#discussion_r117125392

---

From: janaiyengar <[email-masked]>
Date: Wed, 17 May 2017 15:33:35 -0700

Yeah, I was trying to figure out exactly what is reasonable to say here, but didn't spend time figuring it out. Do you want to suggest an edit here? Specifically, this gets into the details of spurious detection, but that may be worth describing here. I'll try to get to this today.

-- 
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#discussion_r117125795

---

From: Martin Thomson <[email-masked]>
Date: Thu, 18 May 2017 07:25:19 -0700

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

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.

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

---

From: ianswett <[email-masked]>
Date: Thu, 18 May 2017 18:08:53 -0700

I agree it's a bit hard to read.  Packet number skipping doesn't matter, because the sender knows it skipped packets.  It does introduce extra work in that case, but it's easily solvable.

I tend to agree.

-- 
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#discussion_r117386165