Subject: [quicwg/base-drafts] Don't send PING in Initial or Handshake (#2642)

From: ianswett <[email-masked]>
Date: Tue, 23 Apr 2019 07:48:52 -0700

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

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

-- Commit Summary --

  * Don't send PING in Initial or Handshake

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2642.patch
https://github.com/quicwg/base-drafts/pull/2642.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/2642

---

From: Marten Seemann <[email-masked]>
Date: Tue, 23 Apr 2019 07:51:16 -0700

marten-seemann approved this pull request.

There's this weird edge case where you might run out of cwnd, because PADDING counts towards in-flight but is not ack-eliciting, but it seems safe to ignore that one. If you don't receive and acknowledgment for that many packets right at the beginning of the connection, something is going seriously wrong anyway.

-- 
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/2642#pullrequestreview-229603713

---

From: ianswett <[email-masked]>
Date: Tue, 23 Apr 2019 14:55:32 +0000 (UTC)

That would actually resolve itself, because at some point, the client would send a Handshake packet with data in it, and cause all the outstanding PADDING packets to be acked.  If all the client's packets are lost and the server is stuck in deadlock, the handshake is doomed anyway.

-- 
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/2642#issuecomment-485838801

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Apr 2019 16:09:54 -0700

It's probably worth acknowledging the edge case and just saying that this protocol doesn't do anything about that.  Note that the case we're concerned about should involve the server sending tons of data, which gives it plenty of opportunity to provide the client with an ACK that will unstick 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/pull/2642#issuecomment-486006705

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 30 Apr 2019 15:35:51 -0700

LGTM, once you've added the note about congestion.

-- 
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/2642#issuecomment-488140313