Subject: Re: [quicwg/base-drafts] Explicitly communicate and include ACK delay in RTO computations (#981)

From: ianswett <[email-masked]>
Date: Thu, 12 Jul 2018 10:33:28 -0700

Jana, Martin and I are increasingly thinking this is worth adding, so unparking 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/981#issuecomment-404590098

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 17 Jul 2018 19:01:38 -0700

Just a heads up that per a recent discussion with Yuchung, MAD is no longer being pursued for TCP.  

-- 
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/981#issuecomment-405784508

---

From: ianswett <[email-masked]>
Date: Thu, 19 Jul 2018 07:34:36 -0700

Thanks Praveen, when I talked to Neal, it sounded like the top two concerns about MAD for TCP were deployability related.

The third was an inability to update the value later in the connection if the initial value was too large or too small.  I think that's still an issue with the proposal to put it in transport params.  I'm a fan of adding an UPDATE_TRANSPORT_PARAMS frame to fix this and a few other cases we'd like to update values, but I can imagine other solutions.

-- 
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/981#issuecomment-406298096