Subject: [quicwg/base-drafts] Remove STOP_WAITING frame (#358)

From: ianswett <[email-masked]>
Date: Mon, 06 Mar 2017 13:12:23 -0800

First pass at removing the STOP_WAITING frame.  Intends to resolve #66 .
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Remove STOP_WAITING frame

-- File Changes --

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

-- Patch Links --

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

---

From: ianswett <[email-masked]>
Date: Mon, 06 Mar 2017 13:18:38 -0800

@ianswett pushed 1 commit.

f8602e1  Update draft-ietf-quic-transport.md

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

---

From: ianswett <[email-masked]>
Date: Mon, 06 Mar 2017 13:19:28 -0800

660d171  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/358/files/f8602e1c137c5deddce3d50ba722f36d4decaea3..660d171732a7979f82f6e21ce8d3c353a1ca75f6

---

From: Martin Thomson <[email-masked]>
Date: Mon, 06 Mar 2017 20:50:03 -0800

martinthomson requested changes on this pull request.

> @@ -1209,13 +1208,13 @@ well as which packets are considered missing.  The ACK frame contains between 1
 and 256 ACK blocks.  ACK blocks are ranges of acknowledged packets.
 
 To limit the ACK blocks to the ones that haven't yet been received by the
-sender, the sender periodically sends STOP_WAITING frames that signal the
-receiver to stop acknowledging packets below a specified sequence number,
-raising the Least Unacked packet number at the receiver.  A sender of an ACK
-frame thus reports only those ACK blocks between the received Least Unacked and
-the reported Largest Acknowledged packet numbers.  The endpoint SHOULD raise the
-Least Unacked communicated via future STOP_WAITING frames to the most recently
-received Largest Acknowledged.
+sender, the sender SHOULD track the ack ranges in acks that have been

> the sender SHOULD track which ACK frames have been acknowledged by its peer.  Once an ACK frame has been acknowledged, the packets that it acknowledges do not need to be acknowledged again.

> @@ -1209,13 +1208,13 @@ well as which packets are considered missing.  The ACK frame contains between 1
 and 256 ACK blocks.  ACK blocks are ranges of acknowledged packets.
 
 To limit the ACK blocks to the ones that haven't yet been received by the
-sender, the sender periodically sends STOP_WAITING frames that signal the
-receiver to stop acknowledging packets below a specified sequence number,
-raising the Least Unacked packet number at the receiver.  A sender of an ACK
-frame thus reports only those ACK blocks between the received Least Unacked and
-the reported Largest Acknowledged packet numbers.  The endpoint SHOULD raise the
-Least Unacked communicated via future STOP_WAITING frames to the most recently
-received Largest Acknowledged.
+sender, the sender SHOULD track the ack ranges in acks that have been
+acked and no longer include them in future ACKs.  In order to handle cases
+where the receiver is not sending data, and hence does not expect it's acks to
+be acked, it may bundle a PING frame with an ack approximately once per RTT to
+gain confirmation of it's ACKs being delivered.  The receiver SHOULD track no

"MAY bundle"

I would say at most once per RTT.  Note that PING is a frame type that triggers the "useless frame" accounting in some implementations, so recommending its use is something we should be very cautious with..

> @@ -1209,13 +1208,13 @@ well as which packets are considered missing.  The ACK frame contains between 1
 and 256 ACK blocks.  ACK blocks are ranges of acknowledged packets.
 
 To limit the ACK blocks to the ones that haven't yet been received by the
-sender, the sender periodically sends STOP_WAITING frames that signal the
-receiver to stop acknowledging packets below a specified sequence number,
-raising the Least Unacked packet number at the receiver.  A sender of an ACK
-frame thus reports only those ACK blocks between the received Least Unacked and
-the reported Largest Acknowledged packet numbers.  The endpoint SHOULD raise the
-Least Unacked communicated via future STOP_WAITING frames to the most recently
-received Largest Acknowledged.
+sender, the sender SHOULD track the ack ranges in acks that have been
+acked and no longer include them in future ACKs.  In order to handle cases
+where the receiver is not sending data, and hence does not expect it's acks to
+be acked, it may bundle a PING frame with an ack approximately once per RTT to
+gain confirmation of it's ACKs being delivered.  The receiver SHOULD track no
+more than 255 ack ranges because they are not expressible on the wire, and 
+MAY limit the number of ack ranges to a smaller value.

I'm not sure about this last sentence.  It needs to better motivate its existence.   If what you are saying is that you need to track acknowledgments of acknowledgments and that needs to have limits, then you probably need more meat on that.

I think that this probably wants to be in a more general section on what you need to track on a per-packet basis.  For STREAM, you need to track what span of data was included in a packet.  For ACK, you need to track what span of acknowledgments were included in the packet.  For RST_STREAM, you need to track which stream resets were included in a packet.  I wonder if that isn't something that is best suited for the packetization section.

Note also that what you say isn't strictly correct: you can send more ranges simply by sending more ACK frames.

-- 
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/358#pullrequestreview-25397513

---

From: ianswett <[email-masked]>
Date: Tue, 07 Mar 2017 08:25:44 -0800

ianswett commented on this pull request.

Done.

-- 
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/358#discussion_r104710727

---

From: ianswett <[email-masked]>
Date: Tue, 07 Mar 2017 08:37:47 -0800

1615423  Martin's comments.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/358/files/660d171732a7979f82f6e21ce8d3c353a1ca75f6..1615423e1acf05ace242c0429908021cf1fb2b0e

---

From: ianswett <[email-masked]>
Date: Tue, 07 Mar 2017 08:39:07 -0800

Ok, changed the wording substantially.

-- 
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/358#discussion_r104714661

---

From: ianswett <[email-masked]>
Date: Tue, 07 Mar 2017 08:40:24 -0800

Thanks.

-- 
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/358#discussion_r104715032

---

From: janaiyengar <[email-masked]>
Date: Tue, 07 Mar 2017 13:59:50 -0800

janaiyengar commented on this pull request.

> @@ -1208,14 +1207,16 @@ Receivers send ACK frames to inform senders which packets they have received, as
 well as which packets are considered missing.  The ACK frame contains between 1
 and 256 ACK blocks.  ACK blocks are ranges of acknowledged packets.
 
-To limit the ACK blocks to the ones that haven't yet been received by the
-sender, the sender periodically sends STOP_WAITING frames that signal the
-receiver to stop acknowledging packets below a specified sequence number,
-raising the Least Unacked packet number at the receiver.  A sender of an ACK
-frame thus reports only those ACK blocks between the received Least Unacked and
-the reported Largest Acknowledged packet numbers.  The endpoint SHOULD raise the
-Least Unacked communicated via future STOP_WAITING frames to the most recently
-received Largest Acknowledged.
+To limit ACK blocks to those that haven't yet been received by the sender,

haven't --> have not

> @@ -1208,14 +1207,16 @@ Receivers send ACK frames to inform senders which packets they have received, as
 well as which packets are considered missing.  The ACK frame contains between 1
 and 256 ACK blocks.  ACK blocks are ranges of acknowledged packets.
 
-To limit the ACK blocks to the ones that haven't yet been received by the
-sender, the sender periodically sends STOP_WAITING frames that signal the
-receiver to stop acknowledging packets below a specified sequence number,
-raising the Least Unacked packet number at the receiver.  A sender of an ACK
-frame thus reports only those ACK blocks between the received Least Unacked and
-the reported Largest Acknowledged packet numbers.  The endpoint SHOULD raise the
-Least Unacked communicated via future STOP_WAITING frames to the most recently
-received Largest Acknowledged.
+To limit ACK blocks to those that haven't yet been received by the sender,
+the receiver SHOULD track which ACK frames have been acknowledged by its peer.
+Once an ACK frame has been acknowledged, the packets it acknowledges SHOULD not
+be acknowledged again.  In order to handle cases where the receiver is not

"In order to" --> "To"

> @@ -1208,14 +1207,16 @@ Receivers send ACK frames to inform senders which packets they have received, as
 well as which packets are considered missing.  The ACK frame contains between 1
 and 256 ACK blocks.  ACK blocks are ranges of acknowledged packets.
 
-To limit the ACK blocks to the ones that haven't yet been received by the
-sender, the sender periodically sends STOP_WAITING frames that signal the
-receiver to stop acknowledging packets below a specified sequence number,
-raising the Least Unacked packet number at the receiver.  A sender of an ACK
-frame thus reports only those ACK blocks between the received Least Unacked and
-the reported Largest Acknowledged packet numbers.  The endpoint SHOULD raise the
-Least Unacked communicated via future STOP_WAITING frames to the most recently
-received Largest Acknowledged.
+To limit ACK blocks to those that haven't yet been received by the sender,
+the receiver SHOULD track which ACK frames have been acknowledged by its peer.
+Once an ACK frame has been acknowledged, the packets it acknowledges SHOULD not
+be acknowledged again.  In order to handle cases where the receiver is not
+sending retransmittable data, and hence does not expect to receive acks, it
+MAY bundle a PING frame with an ack at most once per RTT to gain confirmation

"with an ack" --> "with an ACK frame"

> @@ -1208,14 +1207,16 @@ Receivers send ACK frames to inform senders which packets they have received, as
 well as which packets are considered missing.  The ACK frame contains between 1
 and 256 ACK blocks.  ACK blocks are ranges of acknowledged packets.
 
-To limit the ACK blocks to the ones that haven't yet been received by the
-sender, the sender periodically sends STOP_WAITING frames that signal the
-receiver to stop acknowledging packets below a specified sequence number,
-raising the Least Unacked packet number at the receiver.  A sender of an ACK
-frame thus reports only those ACK blocks between the received Least Unacked and
-the reported Largest Acknowledged packet numbers.  The endpoint SHOULD raise the
-Least Unacked communicated via future STOP_WAITING frames to the most recently
-received Largest Acknowledged.
+To limit ACK blocks to those that haven't yet been received by the sender,
+the receiver SHOULD track which ACK frames have been acknowledged by its peer.
+Once an ACK frame has been acknowledged, the packets it acknowledges SHOULD not
+be acknowledged again.  In order to handle cases where the receiver is not
+sending retransmittable data, and hence does not expect to receive acks, it
+MAY bundle a PING frame with an ack at most once per RTT to gain confirmation
+of ACKs being delivered.  In order to limit receiver state or the size of ACK

"In order to" --> "To"

> @@ -1208,14 +1207,16 @@ Receivers send ACK frames to inform senders which packets they have received, as
 well as which packets are considered missing.  The ACK frame contains between 1
 and 256 ACK blocks.  ACK blocks are ranges of acknowledged packets.
 
-To limit the ACK blocks to the ones that haven't yet been received by the
-sender, the sender periodically sends STOP_WAITING frames that signal the
-receiver to stop acknowledging packets below a specified sequence number,
-raising the Least Unacked packet number at the receiver.  A sender of an ACK
-frame thus reports only those ACK blocks between the received Least Unacked and
-the reported Largest Acknowledged packet numbers.  The endpoint SHOULD raise the
-Least Unacked communicated via future STOP_WAITING frames to the most recently
-received Largest Acknowledged.
+To limit ACK blocks to those that haven't yet been received by the sender,
+the receiver SHOULD track which ACK frames have been acknowledged by its peer.
+Once an ACK frame has been acknowledged, the packets it acknowledges SHOULD not
+be acknowledged again.  In order to handle cases where the receiver is not
+sending retransmittable data, and hence does not expect to receive acks, it
+MAY bundle a PING frame with an ack at most once per RTT to gain confirmation
+of ACKs being delivered.  In order to limit receiver state or the size of ACK

"of ACKs being delivered" --> "of ACK frames being delivered"

-raising the Least Unacked packet number at the receiver.  A sender of an ACK
-frame thus reports only those ACK blocks between the received Least Unacked and
-the reported Largest Acknowledged packet numbers.  The endpoint SHOULD raise the
-Least Unacked communicated via future STOP_WAITING frames to the most recently
-received Largest Acknowledged.
+To limit ACK blocks to those that haven't yet been received by the sender,
+the receiver SHOULD track which ACK frames have been acknowledged by its peer.
+Once an ACK frame has been acknowledged, the packets it acknowledges SHOULD not
+be acknowledged again.  In order to handle cases where the receiver is not
+sending retransmittable data, and hence does not expect to receive acks, it
+MAY bundle a PING frame with an ack at most once per RTT to gain confirmation
+of ACKs being delivered.  In order to limit receiver state or the size of ACK
+frames, a receiver MAY limit the number of ack ranges and stop acknowledging
+packets without getting an ACK acked, with the knowledge this may slightly
+increase spurious retransmits.

I would suggest using "ACK frames" for the noun and "acknowledge" for the verb in general. Suggestion on this particular sentence: see if you can break it up into two sentences. It's a bit of a run-on.

-- 
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/358#pullrequestreview-25640914

---

From: ianswett <[email-masked]>
Date: Tue, 07 Mar 2017 14:03:03 -0800

Also resolves #178 

-- 
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/358#issuecomment-284874478

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Mar 2017 19:45:23 -0800

@martinthomson pushed 1 commit.

f2df307  Reword ACK acking text, integrate Jana's comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/358/files/1615423e1acf05ace242c0429908021cf1fb2b0e..f2df307815d37aefc94662e7cae9b6de104514d1

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Mar 2017 19:47:01 -0800

I have updated this based on Jana's comments, and rebased.  I'll merge this as discussed.  @ianswett, feel free to post comments here and I'll fix them directly.

-- 
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/358#issuecomment-284938619

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Mar 2017 19:47:02 -0800

martinthomson 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/358#pullrequestreview-25691916

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Mar 2017 20:06:16 -0800

Merged #358.

-- 
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/358#event-990757885

---

From: ianswett <[email-masked]>
Date: Wed, 08 Mar 2017 08:28:02 -0800

Thanks Martin, looks great!

-- 
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/358#issuecomment-285090364