Subject: [quicwg/base-drafts] max_ack_delay should be in us, not ms (#3363)

From: ianswett <[email-masked]>
Date: Fri, 17 Jan 2020 18:18:21 -0800

The presentation on low latency TCP options presents a way to convey max ack delay of ms, us and ns.  I don't think we need to do ns(?) in QUIC, but it's clear datacenter use cases will want us, so I believe we should change from ms to us.
https://datatracker.ietf.org/meeting/99/materials/slides-99-tcpm-tcp-low-latency-option-00

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 19 Jan 2020 22:25:38 -0800

This is a big fat design issue that will have a serious impact on existing implementations.  It sounds perfectly reasonable, but we'll need to run the process.

-- 
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/3363#issuecomment-576125521

---

From: ianswett <[email-masked]>
Date: Mon, 20 Jan 2020 11:18:32 -0800

Yes, I agree it's a design issue.  

I confirmed with the TCP team at Google and they agreed microseconds was a better choice than millis.

I will say that we can punt this and make the extension Jana and I are working on specify it in us, but that seems a bit hacky to me given we haven't yet shipped QUIC v1.

-- 
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/3363#issuecomment-576401021

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 20 Jan 2020 17:11:00 -0800

We did discuss this a while ago when we decided to use ms here, and we thought it was quite reasonable. (I cannot recall the arguments, I'll have to dig up the issue.) There's also a limit of 2^14 on this, which will have to change if you wanted to go down to microseconds.

Thinking about this, I agree with @martinthomson: I don't think we should be opening up a design issue for consistency if it doesn't solve any other issues.

(FWIW, @ianswett, let's work on getting the extension accepted first before making changes in core spec to accommodate 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/3363#issuecomment-576476620

---

From: ianswett <[email-masked]>
Date: Mon, 20 Jan 2020 18:12:08 -0800

I did a quick search for microseconds and couldn't find anything about the tradeoff of ms vs us, but maybe you'll have better luck:
https://github.com/quicwg/base-drafts/issues?utf8=%E2%9C%93&q=is%3Aissue+microseconds

-- 
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/3363#issuecomment-576488627

---

From: Lars Eggert <[email-masked]>
Date: Mon, 20 Jan 2020 22:56:02 -0800

I think the argument was that the number would be smaller = use less bits. (Not that I care much.)

-- 
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/3363#issuecomment-576543940

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Jan 2020 00:47:55 -0800

Yeah, that was the idea, but on the presumption that values below 1ms wouldn't have a huge effect on performance.  But this is now part of the PTO calculation.

Right now, we could have had up to 63ms in one byte.  With the proposed change, you get 4 bytes if you want to signal 25ms.  But that is once per connection, and hardly the end of the world.  Reduce the value below 16ms to save two bytes.

It's a bit weird that it is possible to advertise a very small value without first measuring RTT to the peer, but I guess that this is what narrow deployment contexts are all about.  The question is to what extent we think that this becomes too specialized for general purpose use.  We are, after all, designing for the big "I" Internet and advertising max_ack_delay of 10us is hardly suited to trans-continental use.

An alternative would be to to define an extension with the smaller, more granular value.  That might say: if sRTT < X, then I will reduce max_ack_delay to Y.  Or variations on that theme.

-- 
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/3363#issuecomment-576578435

---

From: ianswett <[email-masked]>
Date: Tue, 21 Jan 2020 08:05:23 -0800

Thanks for the comments.  I think it makes sense to discuss this more once the extension draft @janaiyengar  and I wrote is published, since that allows updating max_ack_delay in us.  It's possible that's enough and then we should just close this issue and move on.

-- 
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/3363#issuecomment-576752202

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 23 Jan 2020 20:02:00 -0800

OK. Closing in triage, then.

-- 
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/3363#issuecomment-577982356

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 23 Jan 2020 20:01:57 -0800

Closed #3363.

-- 
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/3363#event-2976032541