Subject: Re: [quicwg/base-drafts] Changing the Default QUIC ACK Policy (#3529)

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 01 Jun 2020 08:38:57 -0700

Thanks kazuho, 1/8 or 1/4 cwnd seems reasonable, as does using Ack 2 for the first part of slow start ... that closed to what we proposed. And yes there will anyway be cases where any default does not work.

If QUIC decides to retain Ack 2, can we at least capture that Ack 2 with QUIC doesn't have the same return path performance as Ack 2 with TCP - so that people know that less frequent Acts are something to think about from the start?

I'm doing a talk in PANRG this week, and have decided to talk-through this topic (I was already going to talk about things related to return paths). That'll give people a view of some data - and a little thought about the implications this has for QUIC, and whether there is an incentive for network device to thin QUIC to restore performance.

-- 
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/3529#issuecomment-636928554

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 01 Jun 2020 16:10:05 -0700

@gorryfair : I'd be in support of saying that ack thinning happens for TCP and cite those studies, and that in the absence of that, there might be throughput consequences for QUIC. I think we've said exactly that in other words in #3706, but if we want to say more there, that's fine with me. That would make this an editorial issue, but I'm entirely happy to do more words there.

I am against changing the recommendation here for another arbitrary recommendation. I think the right approach is to allow endpoints to specify this during a connection, which is where the extension is helpful. As @kazuho notes, our hope is that the extension gets widely deployed.

If you want to make the argument for the extension to become part of the base draft, that's a different conversation, but that's not the one we're having 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/issues/3529#issuecomment-637172880

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 01 Jun 2020 16:43:04 -0700

Attempting to summarise the current status of this issue as a chair: there appears to have been a fair amount of discussion about making a design change, with representatives both in favour and against. 

It appears there is no omnipotent default policy, choosing an optimal one depends on many factors.

The editors have landed an editorial change that attempts to better describe the rationale behind the QUICS's **current** design and highlights some of the factors. There may be further editorial improvements but they no not need to block the design issue. The proposal therefore is to close this issue with no design change.

-- 
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/3529#issuecomment-637183262

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Jun 2020 00:23:27 -0700

Closed #3529.

-- 
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/3529#event-3423413796