Subject: [quicwg/base-drafts] No way to communicate a change in ack delay (#912)

From: ianswett <[email-masked]>
Date: Sun, 12 Nov 2017 00:06:29 +0000 (UTC)

Currently the recovery draft specifies a default ack delay of 25ms, which may be slightly too low in some environments and much too high in others(ie: datacenters).  In order to implement efficient loss recovery, the peer needs to know what ack delay is being used.  This should be communicated via transport params.

A similar proposal exists to add this to TCP, we should ensure it exists in QUIC as well.
https://www.ietf.org/proceedings/97/slides/slides-97-tcpm-tcp-options-for-low-latency-00.pdf

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

---

From: ianswett <[email-masked]>
Date: Wed, 15 Nov 2017 02:37:00 +0000 (UTC)

Discussion at IETF 100 included noting that this needs to be the max ack delay, and not an effort to communicate the exact delay in all circumstances.  Also, if it's in transport params, then it's not encrypted.  There was interest in communicating this to better inform TLP, however.

-- 
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/912#issuecomment-344467741

---

From: pravb <[email-masked]>
Date: Thu, 16 Nov 2017 06:00:48 +0000 (UTC)

Yes this is a deficiency in TCP and makes TLP less effective in cases where there is a single tail packet outstanding. I would request that we at least communicate the max ACK delay value in transport parameters. I would think communicating any changing values over time is optional and I would be fine with that not being included in V1. I also think it is likely that most implementations will simply pick a constant value for ACK delay rather than a dynamically tuned one. 

-- 
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/912#issuecomment-344824527

---

From: pravb <[email-masked]>
Date: Thu, 16 Nov 2017 06:03:54 +0000 (UTC)

I don't want to conflate this with another related issue but communicating the maximum stretch ACking value back to sender can also be useful to implement ACK clocked congestion control like Reno. Today TCP implementations are using different thresholds for ABC and in many cases are sub-optimally growing the cwnd. 

-- 
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/912#issuecomment-344825002