Subject: [quicwg/base-drafts] Send after receiving an ACK (#3047)

From: ianswett <[email-masked]>
Date: Tue, 17 Sep 2019 15:59:56 -0700

Fixes #2604
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3047

-- Commit Summary --

  * Send after receiving an ACK

-- File Changes --

    M draft-ietf-quic-recovery.md (5)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3047.patch
https://github.com/quicwg/base-drafts/pull/3047.diff

-- 
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/pull/3047

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 17 Sep 2019 18:28:07 -0700

I would be inclined to having "SendOnePacket" before "SendAsCwndAllows" as we discussed on the issue. WDYT?

-- 
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/pull/3047#issuecomment-532478955

---

From: ianswett <[email-masked]>
Date: Tue, 17 Sep 2019 18:30:58 -0700

In a world governed by congestion controllers with pacing, I'm not sure that makes sense?  It seems to pull over some TCP ideas, but I'm not sure they're relevant here?  Certainly a congestion controller could decide to always send a packet after loss, but can we leave that up to the congestion controller?

-- 
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/pull/3047#issuecomment-532479549

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 17 Sep 2019 19:29:29 -0700

So, yes to pacing, but there are impls that won't do pacing. Even with pacing, there's now an additional delay in recovering from this packet loss -- loss recovery time is increased by pacing_delay (which will be higher now that the loss has occurred). Allowing the sender to send out 1 packet immediately minimizes the chances of loss repair delay at the receiver.

-- 
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/pull/3047#issuecomment-532491358

---

From: ianswett <[email-masked]>
Date: Tue, 17 Sep 2019 19:38:39 -0700

There is a section for the congestion controller below.  I think this is a response it can choose to have, rather than incorporating it into the loss recovery/detection pseudocode?

-- 
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/pull/3047#issuecomment-532493156

---

From: ianswett <[email-masked]>
Date: Wed, 18 Sep 2019 11:13:27 -0700

Thinking more about this, I really like having congestion control, loss detection, and what to send as separate parts of QUIC.  I'm hesitant to couple them more tightly.

-- 
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/pull/3047#issuecomment-532802883