Subject: Re: [quicwg/base-drafts] Send after receiving an ACK (#3047)

From: ianswett <[email-masked]>
Date: Mon, 18 Nov 2019 21:55:34 -0800

@ianswett pushed 1 commit.

a6370e8431ea1498cb08e9a6383cb908432ece81  Send up to IW

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3047/files/704402513b18fec9a1597b538d00ab8a9d1219dd..a6370e8431ea1498cb08e9a6383cb908432ece81

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 19 Nov 2019 02:43:29 -0800

janaiyengar commented on this pull request.

> @@ -1031,9 +1031,8 @@ OnAckReceived(ack, pn_space):
     OnPacketAcked(acked_packet.packet_number, pn_space)
 
   DetectLostPackets(pn_space)

Detection of a lost packet at a minimum signals that one packet left the network. This is the logic by which TCP sends a packet immediately on loss detection. It allows a sender to recover from a single packet loss immediately. Do you think we should deviate from what TCP does 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/3047#discussion_r347849825

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 19 Nov 2019 02:50:35 -0800

> @@ -1031,9 +1031,10 @@ OnAckReceived(ack, pn_space):
 
   DetectLostPackets(pn_space)
-
+  // Immediately attempt to send, but never more than the
+  // initial window in a single burst.
+  SendUpToIWPacketsAsCongestionControllerAllows()

What's the rationale for sending a burst here? And if the congestion controller allows more, why limit to IW?

-- 
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/3047#pullrequestreview-318943127

---

From: ianswett <[email-masked]>
Date: Tue, 19 Nov 2019 06:59:36 -0800

ianswett commented on this pull request.

The intent is is not to send a burst, but rather to limit any sending to the IW, as specified in the normative text: 

"Implementations MUST either use pacing or limit such bursts to the initial congestion window, which is recommended to be the minimum of 10 * max_datagram_size and max(2* max_datagram_size, 14720)), where max_datagram_size is the current maximum size of a datagram for the connection, not including UDP or IP overhead."

-- 
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/3047#discussion_r347973629

---

From: ianswett <[email-masked]>
Date: Tue, 19 Nov 2019 07:04:13 -0800

I want to keep when to send(congestion control) and loss detection separate.  Stating that you always send one packet in this pseudocode commingles the two.

Also, we have no normative text that indicates sending a packet after receiving an ACK is the right thing to do here, so putting it in the pseudocode would make the pseudocode out of sync with the text.  If you think we should allow sending a packet because TCP does, then the right thing to do is file an issue and then write a PR that updates the text and the pseudocode.

-- 
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/3047#discussion_r347976726