Subject: Re: [quicwg/base-drafts] Padding ACK-only packets (#837)

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Nov 2017 00:04:23 +0000 (UTC)

The problem with no limit at all is that it doesn't address the concern about the exemption.  Specifically the part where it is unbounded.  Could we make a recommendation, similar to the one we have regarding an initial congestion window?  Outside of extreme corner cases (like the ones I mentioned, or cases like @martinduke described), this should hurt and the cost is only a reduction in throughput for those cases.  I think that we can affort to make the exemption pretty generous.

-- 
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/837#issuecomment-343332458

---

From: ianswett <[email-masked]>
Date: Fri, 10 Nov 2017 00:11:32 +0000 (UTC)

I was thinking of recommending something like "When congestion control does not allow sending data, ACK_FRAMEs should be limited to a max of X bytes in size."  One option for X is the max size of a TCP ack frame?  Or the total TCP options space?  Or some arbitrary value.

This allows us to recommend something implementable without doing anything that is too clever.  WDYT?

-- 
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/837#issuecomment-343333665

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Nov 2017 00:19:54 +0000 (UTC)

Yeah, that sounds reasonable, but it doesn't limit the rate especially well.

Maybe permit a total overflow of something like a small multiple (2x to 5x) of the size of a typical TCP ACK, and maybe up to INIT_CWND/MSS times (i.e., 4 or 10).  Just multiply the two values out.  Nothing fancy, just a number that is based on things that a) match TCP practice as much as possible, and b) use parameters that reflect current practice as it evolves.

-- 
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/837#issuecomment-343335074

---

From: ianswett <[email-masked]>
Date: Fri, 10 Nov 2017 00:24:32 +0000 (UTC)

I think the rate limiting is separate, and should be in the section I'm currently updating in PR#907.  TCP permits acking every packet(unless it only contains an ack), though most implementations do some form of delayed ack, so as long as the size of acks is in the TCP range and we're not sending more often, we're in well explored territory.

-- 
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/837#issuecomment-343335816

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Nov 2017 00:36:57 +0000 (UTC)

That sounds reasonable to me.

We should be careful though.  QUIC ACK-only packets will be larger than TCP ACKs because of all the overhead.  So we will be sending a bit more.  A minimal ACK frame is 4 octets in QUIC, which isn't bad, but the packet header (13) and AEAD expansion (16) makes it 73 octets in comparison to 40 for a basic TCP ACK.  That's nudging double the size (maybe this gets worse with SACK and extensions, so it's not a big deal).

The consequence being that we might induce congestion more easily if the congestion properties are massively asymmetric.  That's probably not worth any lost sleep, but we might add a note.

-- 
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/837#issuecomment-343338049