Subject: Re: [quicwg/base-drafts] When the sender is using standard Reno congestion control, ack every ~2 packets (#1428)

From: ianswett <[email-masked]>
Date: Thu, 12 Jul 2018 17:32:32 +0000 (UTC)

Jana and I discussed this today at lunch and we think the best approach is for the sender to communicate a value for the max number of retransmittable packets or bytes received before sending an immediate ack.

Number of packets seems simpler, but the resource we're trying not to constrain is CWND, which is in bytes, so that seems more correct.  I suspect either will work fine in typical circumstances.

Given we recommend Reno currently, the default value would probably be 2 packets or 2400 bytes.

-- 
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/issues/1428#issuecomment-404589813

---

From: MikkelFJ <[email-masked]>
Date: Thu, 12 Jul 2018 10:43:05 -0700

bytes seem more future proof

-- 
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/issues/1428#issuecomment-404592862

---

From: mirjak <[email-masked]>
Date: Thu, 12 Jul 2018 11:58:48 -0700

+1 for communicating the value

-- 
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/issues/1428#issuecomment-404615970

---

From: ianswett <[email-masked]>
Date: Sat, 14 Jul 2018 10:15:07 -0700

Jana and I were discussing this, and I believe we should update the TLP calculation to assume an immediate ack(similar to TCP assuming immediate acks for every two packets) if more than the specified number of bytes are in flight.

-- 
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/issues/1428#issuecomment-405037058

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 17 Jul 2018 18:45:02 -0700

I am not sure I understand the issue here. Even if the sender is using Reno, it should do appropriate byte counting without any limits (since we are requiring pacing). If this is the case why does it matter if  there is stretch ACKing? The issue is not the number of ACKs that need to be generated but that ACKs might get delayed. Any ACKing scheme should generate an immediate ACK after processing a batch of packets. We should recommend that the receiver generate an immediate ACK if it processes more than 2 packets in the batch, but that it could go slower if it is willing to live with slower congestion window growth and less RTT / congestion feedback to the sender.

-- 
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/issues/1428#issuecomment-405782031

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 18 Jul 2018 09:00:04 -0700

So supportive of the general function. However, my question is if it is in bytes, how does that interact with path MTU discovery. If on starts at the default 1280 bytes PMTU and one actually have a 4K path MTU network. Then something that was configured for 10 packets will suddenly end up acking every 3-4 packets.  

-- 
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/issues/1428#issuecomment-405983628

---

From: Nick Banks <[email-masked]>
Date: Wed, 18 Jul 2018 09:04:03 -0700

@gloinul assuming the value can be updated dynamically, and isn't just a transport parameter, couldn't you send the update **in** your PMTUD probe packet? If the packet makes it and gets acknowledged, then everything is good. If the packet was too big, the packet doesn't make it, doesn't get acknowledged and then the peer doesn't even know you tried to increase it.

-- 
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/issues/1428#issuecomment-405985137

---

From: ianswett <[email-masked]>
Date: Wed, 18 Jul 2018 11:06:11 -0700

For both this and explicit max ack delay, the ability to update would be very useful.  I'm not sure if that should be done via an UPDATE_TRANSPORT_PARAMS frame as I proposed for initial stream flow control, or something else.

-- 
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/issues/1428#issuecomment-406022813

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 18 Jul 2018 18:14:19 +0000 (UTC)

@nibanks I don't think driving it from the probe packet necessary is the right way of updating it. That as result of acknowledging a probe does not necessarily result in the PMTU be updated there and then. I rather see other ways. 

-- 
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/issues/1428#issuecomment-406025310