Subject: [quicwg/base-drafts] OnPacketsLost for Nonretransmittable Packets (#2015)

From: Nick Banks <[email-masked]>
Date: Fri, 16 Nov 2018 13:16:24 -0800

Why isn't `OnPacketsLost` called for nonretransmittable packets? Just because you don't retransmit the information contained in the packet, doesn't mean it's loss wasn't an indication of a congestion event, right? If you send an ACK only packet, then three data packets after it, and you then get an ACK for just the data packets, shouldn't you consider there have been a congestion event?

-- 
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/2015

---

From: MikkelFJ <[email-masked]>
Date: Fri, 16 Nov 2018 13:25:04 -0800

Likely because nonretransmittable packets do not count towards bytes in flight. I believe several has stated recently that it is unfortunate that these packets do not contribute to the congestion window, but it is the most pragmatic approach.

-- 
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/2015#issuecomment-439532846

---

From: Nick Banks <[email-masked]>
Date: Fri, 16 Nov 2018 13:39:53 -0800

But I'm arguing that determining if there was a congestion event should be independent of how many retransmittable bytes the packet contains. It would be trivial enough to update the pseudo code.

-- 
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/2015#issuecomment-439537488

---

From: MikkelFJ <[email-masked]>
Date: Fri, 16 Nov 2018 13:44:10 -0800

At least you'd have to update OnPacketSent as well. But if you count nonretransmittable packets and there is no retransmittable packet in front, you might miscalculate the available bandwidth because you do not get timely feedback.

-- 
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/2015#issuecomment-439538549

---

From: Nick Banks <[email-masked]>
Date: Fri, 16 Nov 2018 13:45:44 -0800

Yes, a few places would have to be updated, but it's really just moving the `if (unacked.retransmittable):` line into the `OnPacketsLost` function, only subtracting the bytes in flight if retransmittable.

-- 
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/2015#issuecomment-439538928

---

From: ianswett <[email-masked]>
Date: Tue, 20 Nov 2018 10:20:24 -0800

This was chosen as an effort to be similar to TCP, which does not consider loss of ACK-only packets as a congestion event.  

As @mikkelfj pointed out, ACK-only packets don't count towards bytes in flight, so it seems odd to me to consider the loss of them a congestion event.

I can imagine changing this, but if in doubt, I think adhering closely to what TCP does makes sense.

-- 
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/2015#issuecomment-440379141

---

From: janaiyengar <[email-masked]>
Date: Wed, 21 Nov 2018 15:01:28 -0800

Yup, this is a pragmatic decision.  Note that the chances that there's congestion and that the only packets that get dropped are non-retransmittable ones is very low.

-- 
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/2015#issuecomment-440840743

---

From: Praveen Balasubramanian <[email-masked]>
Date: Wed, 21 Nov 2018 18:28:36 -0800

With TCP typically ACKs get piggybacked since each data packet carries the ACK number. For a TCP that is generating data, generating pure ACKs is a rarity. And its very hard to detect a pure ACK loss in TCP. 
 
I assume even with QUIC, unless the implementation goes out of its way, ACKs should get piggybacked  with data? If ACKs are always sent separately then I would question this decision since unlike TCP they are occupying network bandwidth. At the least we should document that ACKs must be piggybacked whenever possible.

-- 
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/2015#issuecomment-440893766

---

From: MikkelFJ <[email-masked]>
Date: Thu, 22 Nov 2018 01:14:27 -0800

Are you sure? With, say, SFTP download, what data should the client piggyback ACK onto?

-- 
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/2015#issuecomment-440962799

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 23 Nov 2018 15:01:35 -0800

@pravb 
> I assume even with QUIC, unless the implementation goes out of its way, ACKs should get piggybacked with data? If ACKs are always sent separately then I would question this decision since unlike TC…

This seems to be related to #1977.

IMHO, it might be better to state that an endpoint SHOULD NOT send pure ACKs more than one per two packets being received. I say this because some QUIC stacks might use a split design, where ACKs are generated in the kernel (for more timely response) while generating retransmittable packets in the userland.

-- 
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/2015#issuecomment-441327531

---

From: Marten Seemann <[email-masked]>
Date: Fri, 23 Nov 2018 19:55:31 -0800

I agree with @pravb here, we should recommend that ACKs should always be piggybacked, unless there is no data sent. For me, this seemed to be the fix for #1977, otherwise you're just cheating your own congestion controller and sending more data into the network than your cwnd allows.

-- 
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/2015#issuecomment-441341563

---

From: ianswett <[email-masked]>
Date: Mon, 26 Nov 2018 07:18:25 -0800

In the "Sending ACKs" section of the transport draft, it currently says:

"A sender SHOULD bundle ACK frames with other frames when possible."

There are cases when sending an ACK for every packet is the right thing to do, such as in response to a PING on an otherwise idle connection, so I don't think it's practical to say that you should not send one ACK per retransmittable packet received in some cases.

-- 
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/2015#issuecomment-441675192

---

From: janaiyengar <[email-masked]>
Date: Mon, 26 Nov 2018 22:34:58 -0800

I'm closing this. Please reopen if anyone thinks further discussion is warranted.

-- 
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/2015#issuecomment-441944991

---

From: janaiyengar <[email-masked]>
Date: Mon, 26 Nov 2018 22:34:59 -0800

Closed #2015.

-- 
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/2015#event-1988686632