Subject: [quicwg/base-drafts] Don't retransmit old MAX_STREAM_DATA and MAX_DATA (#807)

From: janaiyengar <[email-masked]>
Date: Thu, 28 Sep 2017 14:31:31 -0700

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

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

-- Commit Summary --

  * Don't retransmit old MAX_STREAM_DATA and MAX_DATA
  * reflow

-- File Changes --

    M draft-ietf-quic-transport.md (6)

-- Patch Links --

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

---

From: ekr <[email-masked]>
Date: Fri, 29 Sep 2017 04:58:05 +0000 (UTC)

ekr commented on this pull request.

> @@ -2420,6 +2420,12 @@ When a packet is detected as lost, the sender re-sends any frames as necessary:
 * STOP_SENDING frames MUST be retransmitted, unless the stream has become closed
   in the appropriate direction.  See {{solicited-state-transitions}}.
 
+* The most recent MAX_STREAM_DATA frame for a stream MUST be retransmitted. Any
+  previous unacknowledged MAX_STREAM_DATA frame for the same stream SHOULD NOT
+  be retransmitted since a newer MAX_STREAM_DATA frame for a stream obviates the
+  need for delivering older ones. Similarly, the most recent MAX_DATA frame MUST
+  be retransmitted; previous unacknowledged ones SHOULD NOT be retransmitted.

I am starting to think it's a mistake to phrase this in terms of frames at all. It's the information you want to retransmit. It seems like there are lots of cases where you would be constantly updating your willingness to receive (if, say, you want to continue offering a given buffer size) but you only transmit occasionally. If I have to retransmit, why would I want to advertise stale data rather than the most current 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/807#pullrequestreview-66059262

---

From: ianswett <[email-masked]>
Date: Fri, 29 Sep 2017 05:37:27 -0700

ianswett commented on this pull request.

Agreed.  Anytime the words "retransmit frame" appear in the text, it's probably an error.  And the phrase 'retransmit packet' should occur twice: Once to tell you not to do it and once to tell you can do it for connection close packets only.

-- 
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/807#discussion_r141857547

---

From: MikkelFJ <[email-masked]>
Date: Fri, 29 Sep 2017 06:36:03 -0700

What if the connection close packet has other content?

Kind Regards,
Mikkel Fahnøe Jørgensen

On 29 September 2017 at 14.37.26, ianswett ([email-masked]) wrote:

*@ianswett* commented on this pull request.
------------------------------

In draft-ietf-quic-transport.md

> @@ -2420,6 +2420,12 @@ When a packet is detected as lost, the sender re-sends any frames as necessary:
 * STOP_SENDING frames MUST be retransmitted, unless the stream has
become closed
   in the appropriate direction.  See {{solicited-state-transitions}}.

+* The most recent MAX_STREAM_DATA frame for a stream MUST be retransmitted. Any
+  previous unacknowledged MAX_STREAM_DATA frame for the same stream SHOULD NOT
+  be retransmitted since a newer MAX_STREAM_DATA frame for a stream
obviates the
+  need for delivering older ones. Similarly, the most recent MAX_DATA
frame MUST
+  be retransmitted; previous unacknowledged ones SHOULD NOT be retransmitted.

Agreed. Anytime the words "retransmit frame" appear in the text, it's
probably an error. And the phrase 'retransmit packet' should occur twice:
Once to tell you not to do it and once to tell you can do it for connection
close packets only.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/quicwg/base-drafts/pull/807#discussion_r141857547>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AALzN2jEfOdKqCcVhKBQTurnDVsWUdX_ks5snOSFgaJpZM4Pn6qc>
.

-- 
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/807#issuecomment-333128027

---

From: ianswett <[email-masked]>
Date: Fri, 29 Sep 2017 13:40:21 +0000 (UTC)

I would recommend putting other content with a connection close, but I
don't think it'd cause issues to retransmit a connection close packet that
happened to have other content in it.

On Fri, Sep 29, 2017 at 9:36 AM, MikkelFJ <[email-masked]> wrote:

> <https://github.com/notifications/unsubscribe-auth/
> AALzN2jEfOdKqCcVhKBQTurnDVsWUdX_ks5snOSFgaJpZM4Pn6qc>
> .
>
> —
> You are receiving this because you were mentioned.
> <https://github.com/quicwg/base-drafts/pull/807#issuecomment-333128027>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ATJJcf4itEavsPoJrGpBJYoWJoHkwITeks5snPJDgaJpZM4Pn6qc>
> .
>

-- 
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/807#issuecomment-333129054

---

From: Martin Thomson <[email-masked]>
Date: Sat, 30 Sep 2017 17:05:24 -0700

As Ian says, don't put anything else in the packet with CONNECTION_CLOSE.  There are a few things that I would put in, but only maybe: RST_STREAM (so that the receiver can identify the stream that triggered the error), and PADDING.

-- 
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/807#issuecomment-333344297