Subject: [quicwg/base-drafts] Add details of marking packets lost on PTO (#2624)

From: Jana Iyengar <[email-masked]>
Date: Mon, 15 Apr 2019 15:06:06 -0700

This PR adds text and pseudo-code to clarify what an endpoint should do when PTO fires and there is no data or other ack-eliciting frames to send.

Also does a bit of editorializing to replace "sender" with "endpoint" in the relevant section.

Closes #2493.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Add details of marking packets lost on PTO

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2624.patch
https://github.com/quicwg/base-drafts/pull/2624.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/2624

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 15 Apr 2019 22:09:13 +0000 (UTC)

@janaiyengar pushed 1 commit.

85fb8c47af0ebf15b065d44528dc60860f696709  lint

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2624/files/dee63bb0bcfb24ff6d968ab8cce4a6ef242b2e51..85fb8c47af0ebf15b065d44528dc60860f696709

---

From: ianswett <[email-masked]>
Date: Mon, 15 Apr 2019 18:43:10 -0700

ianswett requested changes on this pull request.

Two things.  If we want to change sender to endpoint in this draft, which I'm not a big fan of, I'd prefer to do so consistently in a single CL.  Also, the more I look at this issue, I think we have our SHOULD/MAY backwards and we SHOULD recommend always sending something, even if the only purpose is to establish loss of outstanding packets.

> @@ -592,7 +592,7 @@ TCP's retransmission timeout period {{?RFC6298}}.
 
 ### Computing PTO
 
-When an ack-eliciting packet is transmitted, the sender schedules a timer for

Can you undo the editorializing about sender/endpoint for this PR?  I prefer sender in this context, but I'd prefer to separate that question out.

 ### Sending Probe Packets
 
-When a PTO timer expires, the sender MUST send one ack-eliciting packet as a
-probe, unless there is nothing to send. A sender MAY send up to two
-ack-eliciting packets, to avoid an expensive consecutive PTO expiration due
-to a single packet loss.
+When a PTO timer expires, an endpoint MUST send at least one ack-eliciting
+packet as a probe, unless there are no ack-eliciting frames to send.  An
+endpoint MAY send up to two ack-eliciting packets, to avoid an expensive
+consecutive PTO expiration due to a single packet loss.
+
+It is possible that the endpoint has no new or previously-sent data or other
+ack-eliciting frames to send.  This can happen for example when there is no new

```suggestion
ack-eliciting frames to send.  For example, this can happen when there is no new
```

>      pto_count++
+    if (any ack-eliciting frames available to send):
+      SendOneOrTwoPackets()
+    else:
+      // Mark all packets in flight as lost

This pseudocode makes an excellent argument that we should recommend sending a PING to establish loss.

-- 
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/2624#pullrequestreview-226951363

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 15 Apr 2019 19:10:19 -0700

janaiyengar commented on this pull request.

Why? Because you'd have to mark packets as lost?

-- 
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/2624#discussion_r275607093

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 16 Apr 2019 02:14:30 +0000 (UTC)

ffa1e6dfea7f0aa03a132f6cf8e6013350ec5fac  s/endpoint/sender

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2624/files/85fb8c47af0ebf15b065d44528dc60860f696709..ffa1e6dfea7f0aa03a132f6cf8e6013350ec5fac

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 16 Apr 2019 02:25:32 +0000 (UTC)

@ianswett: I've done s/endpoint/sender. Let's deal with this separately. On the SHOULD, thinking about this, yes, I think I agree with you. I'll modify the PR, let's see how that looks.

-- 
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/2624#issuecomment-483486438

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 15 Apr 2019 19:30:13 -0700

94d4ecc443a1993a02463cee83e826db3fb0fdde  SHOULD send, MAY mark as lost

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2624/files/ffa1e6dfea7f0aa03a132f6cf8e6013350ec5fac..94d4ecc443a1993a02463cee83e826db3fb0fdde

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 15 Apr 2019 19:32:55 -0700

f38b74b730c7da32bcb72c6186e6f0be539023a7  grammaring

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2624/files/94d4ecc443a1993a02463cee83e826db3fb0fdde..f38b74b730c7da32bcb72c6186e6f0be539023a7

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 16 Apr 2019 02:33:19 +0000 (UTC)

Ok, modified, take a look

-- 
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/2624#issuecomment-483487828

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 15 Apr 2019 19:35:49 -0700

98bd510e5c30b6823824a44801daee4c3a5ef468  clean up

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2624/files/f38b74b730c7da32bcb72c6186e6f0be539023a7..98bd510e5c30b6823824a44801daee4c3a5ef468

---

From: ianswett <[email-masked]>
Date: Tue, 16 Apr 2019 03:39:29 -0700

ianswett commented on this pull request.

> @@ -623,10 +623,21 @@ time.

-When a PTO timer expires, the sender MUST send one ack-eliciting packet as a
-probe, unless there is nothing to send. A sender MAY send up to two
-ack-eliciting packets, to avoid an expensive consecutive PTO expiration due
-to a single packet loss.
+When a PTO timer expires, a sender MUST send at least one ack-eliciting packet
+as a probe, unless there is no data available to send.  An endpoint MAY send up
+to two ack-eliciting packets, to avoid an expensive consecutive PTO expiration
+due to a single packet loss.
+
+It is possible that the sender has no new or previously-sent data to send.  For
+example, this can happen when there is no new application data to send and all
+streams with data in flight are reset (see Section 13.2 of {{QUIC-TRANSPORT}}).

As Nick Banks has repeatedly pointed out, when you reset a stream, you send a STREAM_RESET frame, which is ack-eliciting, so this example doesn't really hold up that well.  A MESSAGE/DATAGRAM frame is the easiest real-world example because it's ack-eliciting and unreliable, but it's not in the v1 draft :(

-- 
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/2624#pullrequestreview-227114494

---

From: Nick Banks <[email-masked]>
Date: Tue, 16 Apr 2019 06:57:33 -0700

nibanks commented on this pull request.

 

Maybe the best example is if the PTO timer expires and the only thing left outstanding was a spurious retransmission. For instance, packet 1 sent a stream frame, then you thought it was lost, then you sent packet 2 but then an ACK came for packet 1. Then PTO fires. You can mark that packet as possibly lost, but it wouldn't cause anything to be queued for transmit.

-- 
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/2624#discussion_r275810926

---

From: ianswett <[email-masked]>
Date: Tue, 16 Apr 2019 07:52:40 -0700

+Under these conditions, the sender SHOULD send PING or other ack-eliciting

```suggestion
Under these conditions, the sender SHOULD send a PING or other ack-eliciting
```

-- 
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/2624#pullrequestreview-227249087

---

From: ianswett <[email-masked]>
Date: Tue, 16 Apr 2019 07:57:12 -0700

LG overall, but I think the example needs to be fixed, unfortunately.

 
+frames in up to two packets, re-arming the PTO timer.

Why send two packets in the case when you're just trying to establish loss?  I'd specifically say 1 packet for this case.

+frames in up to two packets, re-arming the PTO timer.
+
+When there is no data to send, the sender MAY mark any packets still in flight

I'd like to be clear that this is an alternative, so maybe say "Alternatively, when there is..."?

> @@ -1242,7 +1246,8 @@ OnLossDetectionTimeout():
        SendOnePaddedInitialPacket()
     crypto_count++
   else:
-    // PTO
+    // PTO. Send new data if available, else retransmit old data.
+    // If neither is available, send PING frames.

```suggestion
    // If neither is available, send a PING frame.
```

> @@ -1455,8 +1460,7 @@ Invoked when an ACK frame with an ECN section is received from the peer.
 
 ## On Packets Lost
 
-Invoked by loss detection from DetectLostPackets when new packets
-are detected lost.
+Invoked when packets are deemed lost.

Is it worth specifying "from DetectLostPackets" still?

 

Because of the reset issue, I think another example, such as Nick's, would be best.

-- 
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/2624#pullrequestreview-227249612

---

From: ianswett <[email-masked]>
Date: Tue, 16 Apr 2019 07:57:48 -0700

As written now, this swaps a SHOULD and a MAY, so I'm changing it to design.

-- 
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/2624#issuecomment-483697808

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 16 Apr 2019 15:47:03 -0700

deff1fdb9c108d164859e318b07df71e2b93ccbc  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2624/files/98bd510e5c30b6823824a44801daee4c3a5ef468..deff1fdb9c108d164859e318b07df71e2b93ccbc

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 16 Apr 2019 15:51:16 -0700

Yeah, good point. Thanks for the alternate example, @nibanks.

-- 
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/2624#discussion_r276022661

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 18 Apr 2019 21:30:56 +0000 (UTC)

@janaiyengar pushed 2 commits.

a04207e42369bdc0f18ed92f79f97a8221feea48  nick and ian suggestions
d1d064835234ddfeae9bfab5291336d8f10544e4  fix conflict

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2624/files/deff1fdb9c108d164859e318b07df71e2b93ccbc..d1d064835234ddfeae9bfab5291336d8f10544e4

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 18 Apr 2019 14:31:47 -0700

dfde380d3f9b9d5cf95b51be7d3c0402d5a48369  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2624/files/d1d064835234ddfeae9bfab5291336d8f10544e4..dfde380d3f9b9d5cf95b51be7d3c0402d5a48369

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 18 Apr 2019 14:33:38 -0700

52d47bed2b9d0ae4d87521996dea74c0e66054d7  nits

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2624/files/dfde380d3f9b9d5cf95b51be7d3c0402d5a48369..52d47bed2b9d0ae4d87521996dea74c0e66054d7

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 18 Apr 2019 21:34:35 +0000 (UTC)

13fcfe96429fd1f31172fda730b8c6884a050ba7  grammar

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2624/files/52d47bed2b9d0ae4d87521996dea74c0e66054d7..13fcfe96429fd1f31172fda730b8c6884a050ba7

---

From: ianswett <[email-masked]>
Date: Thu, 18 Apr 2019 14:37:44 -0700

+as a probe, unless there is no data available to send.  An endpoint MAY send up
+to two ack-eliciting packets, to avoid an expensive consecutive PTO expiration
+due to a single packet loss.
+
+It is possible that the sender has no new or previously-sent data to send.  As
+an example, consider the following sequence of events: new application data is
+sent in a STREAM frame, deemed lost, then retransmitted in a new packet, and
+then the original transmission is acknowledged.  In the absence of any new
+application data, a PTO timer expiration now would find the sender with no new
+or previously-sent data to send.
+
+When there is no data to send, the sender SHOULD send a PING or other
+ack-eliciting frame in a single packet, re-arming the PTO timer.
+
+Alternatively, instead of sending the ack-eliciting packet, the sender MAY mark

```suggestion
Alternatively, instead of sending an ack-eliciting packet, the sender MAY mark
```

-- 
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/2624#pullrequestreview-228518207

---

From: ianswett <[email-masked]>
Date: Thu, 18 Apr 2019 14:38:05 -0700

ianswett approved this pull request.

-- 
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/2624#pullrequestreview-228518358

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 18 Apr 2019 14:39:25 -0700

6344ffec4f7826d22fcba29d2baab0bfdacd84f0  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2624/files/13fcfe96429fd1f31172fda730b8c6884a050ba7..6344ffec4f7826d22fcba29d2baab0bfdacd84f0

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 18 Apr 2019 14:42:09 -0700

Merged #2624 into master.

-- 
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/2624#event-2286994593