Subject: [quicwg/base-drafts] Proposed change to #1965 (#2212)

From: janaiyengar <[email-masked]>
Date: Wed, 19 Dec 2018 17:25:55 -0800

A proposal: I think I prefer to mark things as lost instead of suggesting that a sender SHOULD send something when there's really nothing to be sent.  I was starting to rephrase #1965 to say "SHOULD send ack-eliciting packet, but MAY mark as lost", and I needed to explain how a sender makes this choice. I realized that if it's been long enough (PTO is long enough) and there's nothing left to send, then maybe it is sensible to mark anything pending as lost. So, I changed my suggestion to that, which is this PR (against #1965).
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Proposed change: MUST mark inflight data as lost

-- File Changes --

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

-- Patch Links --

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

---

From: janaiyengar <[email-masked]>
Date: Wed, 19 Dec 2018 17:38:12 -0800

@janaiyengar pushed 1 commit.

cf7894acb8e8a557b857f4baf281a10756e2e469  reflow

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

---

From: Nick Banks <[email-masked]>
Date: Wed, 19 Dec 2018 18:17:02 -0800

nibanks commented on this pull request.

> @@ -496,11 +496,14 @@ MAY use alternate strategies for determining the content of probe packets,
 including sending new or retransmitted data based on the application's
 priorities.
 
-If no new data or unacknowledged data is available to send, an ack-eliciting
-packet SHOULD be sent.  Sending a retransmittable frame ensures that any in
-flight packets are acknowledged or declared lost in a timely manner.  If no
-ack-eliciting packet is sent, any packets currently in flight should be
-declared lost to avoid repeatedly arming and firing the PTO timer.
+When a PTO timer expires, new or previously-sent data may not available to send,
+and data may still be in flight.  Under these conditions, a sender MUST mark any
+packets still in flight as lost.  This can happen for example when data is sent
+on a stream which is then reset by a sender, and a PTO timer expires after this
+stream is reset.  A sender can be blocked from sending new data in the future if

If the stream is reset, there is still ack-eliciting data pending, the RESET_STREAM frame. When that frame is sent, a new PTO would be sent.

Does this case that would trigger your scenaior: if you sent X (could be s STREAM frame or something else) and then a PTO fires and you retransmit X, but shortly after you receive an ACK for the first transmission. But then PTO fires for the retransmission.

-- 
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/2212#pullrequestreview-186826809

---

From: ianswett <[email-masked]>
Date: Wed, 19 Dec 2018 18:23:10 -0800

ianswett commented on this pull request.

I agree about streams and RESET_STREAM, but if you were only sending MESSAGE frames, then you can easily hit this issue.

-- 
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/2212#discussion_r243139314

---

From: ianswett <[email-masked]>
Date: Wed, 19 Dec 2018 18:24:32 -0800

So I think Jana's example is not really the best one, but I do think this is a problem.

-- 
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/2212#discussion_r243139538

---

From: ianswett <[email-masked]>
Date: Wed, 19 Dec 2018 18:29:06 -0800

I think I'd prefer swapping the preference order I wrote, and say you SHOULD declare all packets lost, and if not, you MUST send an ack-eliciting packet to determine whether any packets were really lost?

I think we need a better example.  Too bad MESSAGE/DATAGRAM is just a 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/2212#pullrequestreview-186828709

---

From: janaiyengar <[email-masked]>
Date: Wed, 19 Dec 2018 19:40:45 -0800

janaiyengar commented on this pull request.

Hm, good point. So how can we end up in this situation then? Do we have any example?

-- 
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/2212#discussion_r243148594

---

From: janaiyengar <[email-masked]>
Date: Wed, 19 Dec 2018 19:43:24 -0800

@ianswett : If we say SHOULD, we need to say under what conditions an implementation might depart from the SHOULD. Specifically, in this case, we need to be able to say why an implementation might not declare all lost. I couldn't think of a good enough reason to not do this, which is why I went with a MUST.

I can remove the example, but if we can't come up with an example, this isn't a problem. @martinduke : did you have a better example?

-- 
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/2212#issuecomment-448852420

---

From: martinduke <[email-masked]>
Date: Wed, 19 Dec 2018 20:13:34 -0800

I like this change, in principle.

I think the current editor's draft suffers from a little conceptual muddle. In TCP, losses, retransmissions, and congestion responses are all tightly coupled. For good reason, the draft backs off on the congestion response bit, and also delays losses, but not always retransmissions. As I indicated in #2103, separating retransmissions and losses creates some ambiguity. I like the idea of just declaring stuff lost. It's conceptually cleaner.

That said, declaring everything lost, rather than the things we're retransmitting, seems like overkill.

-- 
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/2212#issuecomment-448860464

---

From: martinduke <[email-masked]>
Date: Wed, 19 Dec 2018 20:19:12 -0800

Correction: I like the change that means that all retransmitted packets are declared lost first. However, your change reopens the deadlock condition that @ianswett was trying to fix. That is, PTO, retransmission, ack of original packet, PTO. In this case there really is absolutely nothing to send, and nothing to declare lost. My impression was that @ianswett's change would encourage you to send a PING or something. That seems to have been lost in this PR.

-- 
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/2212#issuecomment-448861209

---

From: martinduke <[email-masked]>
Date: Wed, 19 Dec 2018 20:21:24 -0800

To summarize, here is my preferred logic for the lossdetect timer:

if (new data available)
     send it in a new packet
else 
     declare in-flight packets lost and try to retransmit them, until you find one that still actually has contents
    if we didn't find any
           send a ping.

-- 
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/2212#issuecomment-448861459

---

From: janaiyengar <[email-masked]>
Date: Wed, 19 Dec 2018 21:40:36 -0800

@martinduke : This PR has the outcome you are looking for. Basically, on a PTO, if you have something to retransmit, you will. If you have nothing to retransmit, Ian's PR suggests that you basically send a PING to elicit an ACK.  This PR calls them lost instead, so inflight is down to 0 immediately (if inflight is down to 0, you are not blocked anymore when you need to send new app data).

Basically, this PR says:
```
    if (new or unacked data available)
        send it in a new packet
    else
        mark unacked data as lost (give up on this data)
```
At the end, you either have a packet in flight (and a PTO armed), or you have nothing in flight (and no PTO armed).  The point is that you don't need to send anything if you don't have anything to send. You mark what was inflight as lost because it's actually reasonable to do so (it's been long enough).

In terms of #2103 , let's have that discussion there. I don't think there's conceptual muddling here. It's possible that I'm missing it entirely, but I don't see the muddle (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/2212#issuecomment-448880337

---

From: janaiyengar <[email-masked]>
Date: Wed, 19 Dec 2018 21:41:00 -0800

@martinduke ^

-- 
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/2212#discussion_r243160788

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 20 Dec 2018 00:26:35 -0800

kazuho commented on this pull request.

Doesn’t this happen when you are doing poorman’s FEC; i.e sending two consecutive packets containing same data? Then, if the fast packet gets ACKed and the second one doesn’t, then there’d be nothing to send when PTO expires.

-- 
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/2212#discussion_r243186849

---

From: MikkelFJ <[email-masked]>
Date: Thu, 20 Dec 2018 01:52:38 -0800

Overall this makes sense, but what if you are on a fat pipe sending lots of data, and peer ACK's infrequently, and the last ACK is lost when the sender finishes sending. Then you have to retransmit a lot of data.

-- 
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/2212#issuecomment-448938583

---

From: MikkelFJ <[email-masked]>
Date: Thu, 20 Dec 2018 01:53:55 -0800

mikkelfj commented on this pull request.

```suggestion
When a PTO timer expires, new or previously-sent data may not be available to send,
```

-- 
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/2212#pullrequestreview-186918884

---

From: janaiyengar <[email-masked]>
Date: Thu, 20 Dec 2018 13:35:22 -0800

a7b0f3699c6a341a2aa2a6e9a281dba06cdd6f80  add MAY re-arm PTO

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

---

From: ianswett <[email-masked]>
Date: Thu, 20 Dec 2018 13:36:20 -0800

> @@ -496,11 +496,15 @@ MAY use alternate strategies for determining the content of probe packets,
 
+and data may still be in flight.  A sender can be blocked from sending new data

```suggestion
 and packets may still be in flight.  A sender can be blocked from sending new data
```

-- 
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/2212#pullrequestreview-187194498

---

From: ianswett <[email-masked]>
Date: Thu, 20 Dec 2018 13:38:32 -0800

+in the future if data is left in flight with no PTO armed.  Under these

```suggestion
 in the future if packets are left in flight with no PTO armed.  Under these
```

-- 
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/2212#pullrequestreview-187195211

---

From: janaiyengar <[email-masked]>
Date: Thu, 20 Dec 2018 13:41:21 -0800

66c435b4bae996e7cae2d74bd59ed7b1d68acfff  more rephrasing

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2212/files/a7b0f3699c6a341a2aa2a6e9a281dba06cdd6f80..66c435b4bae996e7cae2d74bd59ed7b1d68acfff

---

From: ianswett <[email-masked]>
Date: Thu, 20 Dec 2018 13:41:46 -0800

> @@ -496,11 +496,12 @@ MAY use alternate strategies for determining the content of probe packets,
 
-If no new data or unacknowledged data is available to send, an ack-eliciting
-packet SHOULD be sent.  Sending a retransmittable frame ensures that any in
-flight packets are acknowledged or declared lost in a timely manner.  If no
-ack-eliciting packet is sent, any packets currently in flight should be
-declared lost to avoid repeatedly arming and firing the PTO timer.
+When a PTO timer expires, new or previously-sent data may not be available to
+send, and data may still be in flight.  A sender can be blocked from sending new

```suggestion
 send, and packets may still be in flight.  A sender can be blocked from sending new
```

-- 
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/2212#pullrequestreview-187196230

---

From: janaiyengar <[email-masked]>
Date: Thu, 20 Dec 2018 13:43:03 -0800

302f3df6b6d2f41ff8224a5c092c6e9243502208  more simple

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2212/files/66c435b4bae996e7cae2d74bd59ed7b1d68acfff..302f3df6b6d2f41ff8224a5c092c6e9243502208

---

From: ianswett <[email-masked]>
Date: Thu, 20 Dec 2018 13:44:27 -0800

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/2212#pullrequestreview-187197071

---

From: janaiyengar <[email-masked]>
Date: Thu, 20 Dec 2018 13:44:39 -0800

8e1c599d517cee2dbe86f74b61194b2ab02217e1  comma

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2212/files/302f3df6b6d2f41ff8224a5c092c6e9243502208..8e1c599d517cee2dbe86f74b61194b2ab02217e1

---

From: ianswett <[email-masked]>
Date: Thu, 20 Dec 2018 13:45:05 -0800

-- 
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/2212#pullrequestreview-187197269

---

From: janaiyengar <[email-masked]>
Date: Thu, 20 Dec 2018 13:48:15 -0800

Merged #2212 into ianswett-tlp-deadlock.

-- 
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/2212#event-2039481103