Subject: [quicwg/base-drafts] Simplify stateless retry (#817)

From: ekr <[email-masked]>
Date: Mon, 02 Oct 2017 15:24:14 -0700

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

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

-- Commit Summary --

  * Simplify stateless retry. There's no reason for it to contain ACKs
  * Revise text a bit

-- File Changes --

    M draft-ietf-quic-transport.md (8)

-- Patch Links --

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

---

From: ekr <[email-masked]>
Date: Mon, 02 Oct 2017 15:25:16 -0700

@ekr pushed 1 commit.

fcb91e3  Grrr... Line length

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/817/files/03db4e3ffc8aee5cba8bd78535db7e291fd7a5d2..fcb91e33ada1c14743fb268decb2c4691fafe8a3

---

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Oct 2017 13:01:44 -0700

martinthomson commented on this pull request.

> @@ -618,10 +618,11 @@ any version negotiation that occurred (see {{version-negotiation}}).  The client
 MAY also retain any observed RTT or congestion state that it has accumulated for
 the flow, but other transport state MUST be discarded.
 
-The payload of the Server Stateless Retry packet contains STREAM frames and
-could contain PADDING and ACK frames.  A server can only send a single Server
-Stateless Retry packet in response to each Client Initial packet that is
-receives.
+The payload of the Server Stateless Retry packet contains a single
+STREAM frame on stream 0 with offset 0 containing the server's
+cryptographic stateless retry material. It MUST NOT contain any other
+frames. Any future stream frames from the server will also start at
+stream offset 0.

Nit: STREAM frames.  Also,  this somewhat implies that ALL STREAM frames will have an offset of 0.  I think that you mean that the NEXT STREAM frame starts at an offset of 0.

-- 
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/817#pullrequestreview-66879179

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Oct 2017 22:41:20 +0000 (UTC)

@martinthomson pushed 1 commit.

372c1e6  capitalize STREAM

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/817/files/fcb91e33ada1c14743fb268decb2c4691fafe8a3..372c1e6c942ec496474677a1e141d4c2afcd8702

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Oct 2017 22:41:32 +0000 (UTC)

Merged #817.

-- 
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/817#event-1287080070

---

From: Marten Seemann <[email-masked]>
Date: Sun, 15 Oct 2017 23:52:03 -0700

Why am I not allowed to include an ACK for the Client Initial here? This would provide the Client with a first RTT measurement.
Furthermore, I’d like to avoid special code that makes sure that this single packet doesn’t contain any other frames.

-- 
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/817#issuecomment-336795709

---

From: ianswett <[email-masked]>
Date: Mon, 16 Oct 2017 15:20:51 +0000 (UTC)

Marten brings up a good point.  Having an early RTT signal is really nice both to avoid tail latency and spurious retransmits.  If you've sent multiple client initials, you don't know which this is in response to.

-- 
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/817#issuecomment-336920880

---

From: Patrick McManus <[email-masked]>
Date: Mon, 16 Oct 2017 14:46:28 -0700

the packetnumber of the SSR is the packetnumber of the CI that triggered it.. and now that we don't do re-randomization that should be deterministic. so that's essentially an ACK, right?

-- 
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/817#issuecomment-337053266

---

From: ianswett <[email-masked]>
Date: Mon, 16 Oct 2017 23:33:16 +0000 (UTC)

I didn't realize that's true, but if so, that would be sufficient for an RTT sample.  It is a non-standard path for RTT measurement, but SSR is a sort of special case, since you're essentially creating a whole new connection, so I'm ok with that in this case.

-- 
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/817#issuecomment-337073731

---

From: Marten Seemann <[email-masked]>
Date: Mon, 16 Oct 2017 16:37:12 -0700

But why do we need to create a special case here? Why is it explicitly forbidden to include an ACK?

-- 
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/817#issuecomment-337074309

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Oct 2017 03:16:11 +0000 (UTC)

Let's open an issue on this.  I had assumed that the Retry would be sent immediately, so the ACK delay wouldn't factor into the RTT calculation.

-- 
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/817#issuecomment-337105663