Subject: [quicwg/base-drafts] Discuss considerations for max_ack_delay (#2186)

From: janaiyengar <[email-masked]>
Date: Fri, 14 Dec 2018 12:22:18 -0800

Conversations with implementers suggests that it might be useful to clearly discuss considerations for how a receiver might choose max_ack_delay. Specifically, the receiver should  communicate worst case delay, since communicating something smaller can result in spurious retransmissions. Some guidance should be added.

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

---

From: Praveen Balasubramanian <[email-masked]>
Date: Sun, 16 Dec 2018 09:42:47 -0800

A receiver SHOULD add a perturbation on top of the actual max ack delay. This value should be the OS timer granularity (typically 15.6 msec) or at least 2 msec when platform supports fine grained timers. This implies that a receiver which has turned off ACK delays, still needs to advertise a non-0 value in the transport parameter. 

Should a sender add the perturbation itself when it sees the value 0 or absence of the transport parameter?

-- 
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/2186#issuecomment-447661889

---

From: janaiyengar <[email-masked]>
Date: Sun, 16 Dec 2018 10:30:35 -0800

@pravb: I think this is good. I think SHOULD is the right level here -- there might be conditions where a receiver knows its delay bounds well enough.

As you noted in #2114, this is a departure from how we've traditionally thought about responsibilities, since in TCP this is entirely sender-side.  This is probably important to emphasize, as a rationale for why we're doing this differently in QUIC.

-- 
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/2186#issuecomment-447665161

---

From: janaiyengar <[email-masked]>
Date: Sun, 16 Dec 2018 10:31:42 -0800

@pravb: 15.6 ms is an oddly specific timer granularity ;-)

-- 
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/2186#issuecomment-447665239

---

From: ianswett <[email-masked]>
Date: Mon, 17 Dec 2018 08:54:10 -0800

There is text that you should include any timer delays in the max ack delay when we define the transport param in the transport doc, but not elsewhere:
"This value SHOULD include the receiver's expected delays in alarms firing. For example, if a receiver sets a timer for 5ms and alarms commonly fire up to 1ms late, then it should send a max_ack_delay of 6ms. If this value is absent, a default of 25 milliseconds is assumed."

Ideally I'd like to ensure specifying a max ack delay of 0 degrades to suboptimal, but reasonable behavior.  That's one of the reasons we limited the adjustment of RTT by max_ack_delay.

-- 
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/2186#issuecomment-447916646

---

From: ianswett <[email-masked]>
Date: Mon, 17 Dec 2018 08:57:05 -0800

Somewhat related, editorially.  Jana was going to move the ack sending text from recovery into transport, because now it's split between two spots and there's already at least one inconsistency.

The text about max_ack_delay is currently in 3 spots from what I can tell, so maybe it'd be nice to unify that as well?

-- 
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/2186#issuecomment-447917740