Subject: Re: [quicwg/base-drafts] Adds substantive descriptions of loss detection mechanisms (#801)

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Oct 2017 06:36:01 +0000 (UTC)

I can't work out what circle is complaining about here.  Can you rebase this branch and push again?  It might be easier to see any problem with the new CI setup.

-- 
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/801#issuecomment-335075384

---

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Oct 2017 08:17:56 +0000 (UTC)

martinthomson commented on this pull request.

> -    TCP's Tail Loss Probe.
-
-  * If all else fails, a Retransmission Timeout (RTO) alarm is always set when
-    any retransmittable packet is outstanding. When this alarm fires, all
-    unacknowledged packets are marked as lost.
-
-  * 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 larger packet number is acknowledged and a threshold amount of
-    time has passed since the packet was sent.
-
-  * 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.
+QUIC uses both ack information and timeouts to detect lost packets, and this

s/acked/acknowledged/g
s/ack information/acknowledgment information/g
s/ack-based/ACK-based/g or s/ack-based/acknowledgment-based/g

-- 
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/801#pullrequestreview-67910553

---

From: janaiyengar <[email-masked]>
Date: Mon, 09 Oct 2017 23:54:56 +0000 (UTC)

janaiyengar commented on this pull request.

> +
+## Computing the RTT estimate
+
+(To be filled)
+
+
+## Ack-based Detection
+
+Ack-based loss detection implements the spirit of TCP's Fast Retransmit
+{{!RFC5681}}, Early Retransmit {{!RFC5827}}, FACK, and SACK loss recovery
+{{!RFC6675}}. This section provides an overview of how these algorithms are
+implemented in QUIC.
+
+### Fast Retransmit
+
+An unacknowledged packet is marked as lost when an acknowledgment is received

I'm adding a TODO, but not doing this in this PR. I think we're going to need an early terminology section.

-- 
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/801#discussion_r143603875

---

From: janaiyengar <[email-masked]>
Date: Tue, 10 Oct 2017 00:48:46 +0000 (UTC)

> +reordering, causing a sender to spuriously detect losses. Spurious loss
+detection leads to unnecessary retransmissions and may result in degraded
+performance due to the actions of the congestion controller upon detecting
+loss. Implementers MAY use algorithms developed for TCP, such as TCP-NCR
+{{!RFC4653}}, to improve QUIC's reordering resilience, though care should be
+taken to map TCP specifics to QUIC correctly. Similarly, using time-based loss
+detection to deal with reordering, such as in PR-TCP, should be more readily
+usable in QUIC. Making QUIC deal with such networks is important open research,
+and implementers are encouraged to explore this space.
+
+### Early Retransmit
+
+Unacknowledged packets close to the tail may have fewer than
+kReorderingThreshold number of packets sent after them. Loss of such packets
+cannot be detected via Fast Retransmit. To enable ack-based loss detection of
+such packets, receipt of an acknowledgment for the last outstanding packet

Hm -- yeah, I think this is important. I'm adding ackable in a few places, including in TLP.

-- 
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/801#discussion_r143609842

---

From: janaiyengar <[email-masked]>
Date: Mon, 09 Oct 2017 17:52:46 -0700

+triggers the Early Retransmit process, as follows.
+
+If there are unacknowledged packets still pending, they ought to be

I think "ought to be" is correct here, since we say that the sender SHOULD set an alarm here... we don't mark for rtx until the alarm fires.

-- 
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/801#discussion_r143610227

---

From: janaiyengar <[email-masked]>
Date: Tue, 10 Oct 2017 00:56:15 +0000 (UTC)

> +alarm when a tail packet is transmitted. When this alarm fires, a Tail Loss
+Probe (TLP) packet is sent to evoke an acknowledgement from the receiver.
+
+The alarm duration, or Probe Timeout (PTO), is set based on the following
+conditions:
+
+* If there is exactly one unacknowledged packet, PTO SHOULD be scheduled for
+  max(2*SRTT, 1.5*SRTT+kDelayedAckTimeout)
+
+* If there are more than one unacknowledged packets, PTO SHOULD be scheduled for
+  max(2*SRTT, 10ms).
+
+* If RTO is earlier, schedule a TLP alarm in its place. That is, PTO SHOULD be
+  scheduled for min(RTO, PTO).
+
+kDelayedAckTimeout is the worst case delayed ACK timer.  When the is exactly one

I used wording from the TLP draft, but changed it to "expected" now. We need to revisit this algorithm anyways, so I don't think we need to finesse this part yet.

-- 
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/801#discussion_r143610573

---

From: janaiyengar <[email-masked]>
Date: Mon, 09 Oct 2017 17:57:06 -0700

+* If there is exactly one unacknowledged packet, PTO SHOULD be scheduled for
+  max(2*SRTT, 1.5*SRTT+kDelayedAckTimeout)
+
+* If there are more than one unacknowledged packets, PTO SHOULD be scheduled for
+  max(2*SRTT, 10ms).
+
+* If RTO is earlier, schedule a TLP alarm in its place. That is, PTO SHOULD be
+  scheduled for min(RTO, PTO).
+
+kDelayedAckTimeout is the worst case delayed ACK timer.  When the is exactly one
+unacknowledged packet, the alarm duration includes time for an acknowledgment to
+be received, and additionally, a kDelayedAckTimeout period to compensate for the
+delayed acknowledgment timer at the receiver.
+
+The RECOMMENDED value for kDelayedAckTimeout is 25ms.

But we don't allow negotiation here yet. I think it's a good idea to negotiate, so I'll add a TODO 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/801#discussion_r143610680

---

From: janaiyengar <[email-masked]>
Date: Wed, 11 Oct 2017 04:49:14 +0000 (UTC)

@janaiyengar pushed 1 commit.

f4602dc  trailing whitespaces

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/801/files/3d757f47e0e3994f0641963d6043e04e6f3d7d31..f4602dc133fbbca62ff1c7584a2a8a0c25b28e24

---

From: janaiyengar <[email-masked]>
Date: Wed, 11 Oct 2017 04:46:28 +0000 (UTC)

> +* When an RTO alarm fires, RTO is set to twice its current value.
+
+The sender typically incurs a high latency penalty when an RTO is encountered,
+and this penalty increases exponentially in subsequent consecutive RTOs. Sending
+a single RTO packet therefore makes the connection very sensitive to single
+packet loss. Sending two packets instead of one significantly increases
+resilience to packet drop in both directions, thus reducing the probability of
+consecutive RTOs.
+
+QUIC's RTO algorithm differs from TCP in that an RTO alarm event is not
+considered a strong enough signal of packet loss. An RTO alarm fires only when
+there's a prolonged period of network silence, which could be caused by a change
+in the underlying network RTT.
+
+When an ack is received after one or more consecutive RTO alarm events, any
+packets with lower packet numbers than those acked MUST be marked as lost.

I've modified the text here, PTAL.

-- 
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/801#discussion_r143911448

---

From: ianswett <[email-masked]>
Date: Wed, 11 Oct 2017 06:56:26 -0700

ianswett approved this pull request.

Great improvement.  We can tackle the TODOs next.

-- 
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/801#pullrequestreview-68614897

---

From: ianswett <[email-masked]>
Date: Wed, 11 Oct 2017 06:56:36 -0700

Merged #801.

-- 
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/801#event-1288257979