Subject: [quicwg/base-drafts] Add psuedocode for ACK sending logic in recovery (#1716)

From: ianswett <[email-masked]>
Date: Wed, 29 Aug 2018 18:00:12 -0700

Once #1428 is resolved, I believe I can construct fairly simple pseudocode for the ack sending algorithm and I believe this is worthwhile.

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

---

From: MikkelFJ <[email-masked]>
Date: Wed, 29 Aug 2018 23:18:28 -0700

Would it be pissible to have both a Reno style and a rate based style algorithm - or at least a refence?

-- 
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/1716#issuecomment-417202720

---

From: ianswett <[email-masked]>
Date: Thu, 30 Aug 2018 12:30:23 +0000 (UTC)

There are no IETF standard rate based algorithms I'm aware of, but my real objection would be that the recovery doc could become very long.  I think the example of Reno is simple to understand and covers the important differences between TCP and QUIC that may effect congestion control implementations?

-- 
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/1716#issuecomment-417301983

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Aug 2018 17:16:57 -0700

Like the rest of this document, Reno-like is a baseline, and we have consensus on doing that.  The spectrum of possibilities are not limited by what we specify here, but we do have to specify something that is known to be good for the Internet.  If nothing else, describing more than one algorithm would be a schedule risk.

-- 
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/1716#issuecomment-417508729