Subject: [quicwg/base-drafts] Moving text on spinbit into transport (#2364)

From: Marcus Ihlar <[email-masked]>
Date: Wed, 23 Jan 2019 07:25:43 -0800

Text on spinbit that is necessary for implementors moved/added to transport draft.

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

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

-- Commit Summary --

  * Initial text proposal for adding spin bit to transport specification.
  * Merge pull request #1 from gloinul/spinbit
  * Updated text on spinbit
  * reviewed version
  * Merge branch 'master' of https://github.com/quicwg/base-drafts
  * Updated formatting

-- File Changes --

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

-- Patch Links --

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

---

From: ianswett <[email-masked]>
Date: Wed, 23 Jan 2019 12:49:40 -0800

ianswett commented on this pull request.

> @@ -3948,8 +3993,33 @@ Fixed Bit:
 
 Spin Bit (S):
 
-: The sixth bit (0x20) of byte 0 is the Latency Spin Bit, set as described in
-  {{!SPIN=I-D.ietf-quic-spin-exp}}.
+: The third most significant bit (0x20) of byte 0 is the Latency Spin Bit.

I think this would be easier to read if either all the text was here or if this referenced the section above.  Given it's a lot of text, I tend to think the latter is better.

-- 
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/2364#pullrequestreview-195736721

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 23 Jan 2019 14:31:49 -0800

janaiyengar requested changes on this pull request.

Much of this text is already present in draft-ietf-quic-spin-exp, which is referenced from the current text. What is the goal of this PR?

-- 
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/2364#pullrequestreview-195777032

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Jan 2019 17:09:23 -0800

I think that this is one editorial discussion where I would like to see some discussion.

For me, the question of document organization is secondary to a question of status.  I think that we should target the spin bit document at experimental status, not proposed standard, which would make keeping the split between documents much more appropriate.  I'm sure that others will disagree with this position, so I think that discussion is very much warranted.

Incidentally, the change from exp to std in the document is in a commit entitled "typofix", done late last year by @britram.  I was - until just now when I checked - under the impression that the goal was an experimental RFC.  I suspect that we had a discussion on this point that settled on standards track, but I'm just remembering badly.

After that, then I think we want to talk about where this slots into the current document.  I'm not sure that the place that is selected here is right, but I want to get the big ticket questions out of the way first.

-- 
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/2364#issuecomment-457027594

---

From: Roni Even <[email-masked]>
Date: Wed, 23 Jan 2019 23:28:47 -0800

I think the text should be in the transport document but in my view it will be better as subsection 17.3.1 titled spin bit

-- 
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/2364#issuecomment-457095015

---

From: Brian Trammell <[email-masked]>
Date: Thu, 24 Jan 2019 00:33:32 -0800

haven’t had a chance to review the PR in detail yet, should do so today.

On document status, my understanding is:

- in London, we decided to adopt the spin bit as an experimental feature within the working group to generate more experience to inform an eventual adoption decision.

- in Bangkok, we achieved rough consensus to adopt the feature into the base protocol. The plan as I understood it is that documents were to be held separate until the spin-exp document reflected Bangkok consensus and the transport document was done with large-scale technical changes, after which they would be merged. This plan together the discussion about 2119 language made it clear to me that the spin bit would be proposed standard.

This PR does the merge, because the conditions (less transport change in the future, spin bit now reflects the consensus about probabilistic participation) have been met.

While general guidelines on on-path use of the signal belongs in the (informational) manageability draft, details about how exactly to generate metrics from this signal are IMO more experimental, and probably fit better over in IPPM (personal opinion, not a ruling from the chair)

-- 
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/2364#issuecomment-457110759

---

From: Lars Eggert <[email-masked]>
Date: Thu, 24 Jan 2019 00:52:22 -0800

Let's put this on the agenda for Tokyo

-- 
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/2364#issuecomment-457116141

---

From: Brian Trammell <[email-masked]>
Date: Thu, 24 Jan 2019 00:53:20 -0800

(FWIW, I'm not in Tokyo, and not remote -- unavoidable conflict with a final project review at the Commission)

-- 
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/2364#issuecomment-457116421

---

From: Lars Eggert <[email-masked]>
Date: Thu, 24 Jan 2019 00:54:22 -0800

@britram can anyone participate who you trust to defend your views?

-- 
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/2364#issuecomment-457116720

---

From: Lars Eggert <[email-masked]>
Date: Thu, 24 Jan 2019 00:54:38 -0800

Also, we need to start an issue on this rather than commenting on the PR

-- 
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/2364#issuecomment-457116787

---

From: Brian Trammell <[email-masked]>
Date: Thu, 24 Jan 2019 01:10:26 -0800

britram requested changes on this pull request.

This is good, modulo a few changes to 2119 language that I think better reflect BKK consensus.

> @@ -2818,6 +2825,44 @@ encoded as a single byte with the value 0x01.  An endpoint MAY treat the receipt
 of a frame type that uses a longer encoding than necessary as a connection error
 of type PROTOCOL_VIOLATION.
 
+## Latency Spin Bit {#spin-bit}
+
+The latency spin bit enables passive latency monitoring from observation points
+on the network path throughout the duration of a connection. The spin bit is
+only present in the short packet header, since it is possible to measure the
+initial RTT of a connection by observing the handshake. Therefore, the spin bit
+will appear after version negotiation and connection establishment are
+completed. On-path measurement and use of the Latency Spin Bit is further
+discussed in {{QUIC-MANAGEABILITY}}.
+
+The spin bit utilizes a single bit in the first byte of the short header. The
+location of the bit and procedures for how to set it by clients and servers are
+defined in {{short-header}}.
+
+Implementations MAY select to not implement the full spin bit functionality. In

I think I'd phrase this differently: "the spin bit is an optional feature. implementations that implement MUST implement it as specified in this document."

> +will appear after version negotiation and connection establishment are
+completed. On-path measurement and use of the Latency Spin Bit is further
+discussed in {{QUIC-MANAGEABILITY}}.
+
+The spin bit utilizes a single bit in the first byte of the short header. The
+location of the bit and procedures for how to set it by clients and servers are
+defined in {{short-header}}.
+
+Implementations MAY select to not implement the full spin bit functionality. In
+that case they are only REQUIRED to implement what is defined for the spin bit
+when it is disabled.
+
+Each endpoint unilaterally decides if the spin bit is enabled or disabled for a
+connection. Implementations SHOULD allow administrators of clients and servers
+to disable the spin bit either globally or on a per-connection basis. Even when
+the spin bit is not disabled by the administrator implementations SHOULD disable

IIRC consensus here sounded like MUST probabalistically disable, since we will want to provide cover traffic in the long term, not only for non-implementing endpoints but also for flows that decide to disable it. I'd justify the MUST because it affects the privacy properties of the wire image (however minimal the actual effect is)

```suggestion
the spin bit is not disabled by the administrator implementations MUST disable
```

> +discussed in {{QUIC-MANAGEABILITY}}.
+
+The spin bit utilizes a single bit in the first byte of the short header. The
+location of the bit and procedures for how to set it by clients and servers are
+defined in {{short-header}}.
+
+Implementations MAY select to not implement the full spin bit functionality. In
+that case they are only REQUIRED to implement what is defined for the spin bit
+when it is disabled.
+
+Each endpoint unilaterally decides if the spin bit is enabled or disabled for a
+connection. Implementations SHOULD allow administrators of clients and servers
+to disable the spin bit either globally or on a per-connection basis. Even when
+the spin bit is not disabled by the administrator implementations SHOULD disable
+the spin bit on a randomly chosen fraction of connections. However, connections
+may be configured to explicitly enable spinning, for example in the case of

in line with the SHOULD above, this isn't a may/MAY:

```suggestion
SHOULD be configurable to explicitly enable spinning, for example in the case of
```

 Spin Bit (S):

+1 to this

> @@ -89,6 +89,13 @@ informative:
     target:
      "https://web.archive.org/web/20150315054838/http://ha.ckers.org/slowloris/"
 
+  QUIC-MANAGEABILITY:
+    title: "Manageability of the QUIC Transport Protocol"
+    author:
+      - ins: M. Kuehlewind

add `-ins: B. Trammell` as well 

-- 
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/2364#pullrequestreview-195914975

---

From: Brian Trammell <[email-masked]>
Date: Thu, 24 Jan 2019 01:16:35 -0800

okay everybody let's take the discussion over to #2369 

-- 
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/2364#issuecomment-457123549

---

From: Brian Trammell <[email-masked]>
Date: Thu, 24 Jan 2019 01:17:47 -0800

(@larseggert probably, will check; however, if discussion on #2369 doesn't converge relatively quickly then I'll want to take it to the list beforehand as well)

-- 
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/2364#issuecomment-457123915

---

From: Marcus Ihlar <[email-masked]>
Date: Thu, 24 Jan 2019 01:47:41 -0800

ihlar commented on this pull request.

Agree, that is a better phrasing

-- 
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/2364#discussion_r250529651

---

From: Marcus Ihlar <[email-masked]>
Date: Thu, 24 Jan 2019 10:00:54 +0000 (UTC)

>           Also, we need to start an issue on this rather than commenting on the PR
@larseggert I'm not sure what the issue is? 
The consensus in BKK was that the bit should be included in the standard, this PR only contains the information necessary for implementors, no text on how to interpret or process the bit on path. Simply referencing a non-milestone potentially experimental document seems a bit odd.

-- 
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/2364#discussion_r250535623

---

From: Marcus Ihlar <[email-masked]>
Date: Thu, 24 Jan 2019 02:01:36 -0800

-- 
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/2364#issuecomment-457138525

---

From: Marcus Ihlar <[email-masked]>
Date: Thu, 24 Jan 2019 08:55:10 -0800

+

Not sure why this would be a SHOULD, here we describe a case where a single connection has been explicitly configured to spin (e.g some debug or tracing mode enabled). In that case, spinning shouldn't be disabled for that specific connection as a result of the random selection process.

-- 
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/2364#discussion_r250691345

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Jan 2019 13:30:49 -0800

It looks like the changes Brian is suggesting are editorial, but I'm not entirely sure about the changes to normative language.  Can we make those after any merge?  (Or even before it, given that this seems to be a little controversial...)

-- 
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/2364#issuecomment-457364175

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Jan 2019 13:33:38 -0800

Another note, in case I miss it.  spin-exp has a contributors/acknowledgments section.  If this merges, I want to talk to Brian about who we should be acknowledging, if anyone.

-- 
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/2364#issuecomment-457365039

---

From: Brian Trammell <[email-masked]>
Date: Thu, 24 Jan 2019 14:36:40 -0800

IMO the changes to normative language are editorial (reflecting my understanding of consensus already reached); have withdrawn one suggestion on review.

re acks: The EC/SERI ack won't be necessary to bring over from spin-exp. I'm not sure what your eventual plan is for filling the Contributors section of the -transport document; if Contributors is all-committers, I can check to see who wrote the text from which this PR is derived in the original -spin document.

-- 
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/2364#issuecomment-457384758

---

From: Roni Even <[email-masked]>
Date: Thu, 24 Jan 2019 22:26:36 -0800

Hi,

Fully agree with Marcus, the text is for implementers, it is not how to analyze which will be in a spin experiment document.

Roni Even

From: Marcus Ihlar [mailto:[email-masked]] 
Sent: Thursday, January 24, 2019 12:02 PM
To: quicwg/base-drafts
Cc: Roni Even; Comment
Subject: Re: [quicwg/base-drafts] Moving text on spinbit into transport (#2364)

@larseggert <https://github.com/larseggert>  I'm not sure what the issue is?
The consensus in BKK was that the bit should be included in the standard, this PR only contains the information necessary for implementors, no text on how to interpret or process the bit on path. Simply referencing a non-milestone potentially experimental document seems a bit odd.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <https://github.com/quicwg/base-drafts/pull/2364#issuecomment-457138525> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AO62eW7mWW6Az5lkjFAb2hnIBnVUFJkcks5vGYSBgaJpZM4aPA_u> .  <https://github.com/notifications/beacon/AO62eftKEmvMr5lTmWseBjU8s4VQnQbqks5vGYSBgaJpZM4aPA_u.gif> 

-- 
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/2364#issuecomment-457469779

---

From: Lars Eggert <[email-masked]>
Date: Sun, 27 Jan 2019 06:35:47 -0800

Please discuss on #2369 and not on this PR. (Will unlock once that has concluded.)

-- 
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/2364#issuecomment-457922984

---

From: Martin Thomson <[email-masked]>
Date: Sun, 27 Jan 2019 23:05:01 -0800

martinthomson commented on this pull request.

the word "utilizes" is banned from this document
```suggestion
The spin bit uses a single bit in the first byte of the short header. The
```

+

```suggestion
could be configured to explicitly enable spinning, for example in the case of
```

+Each endpoint unilaterally decides if the spin bit is enabled or disabled for a
+connection. Implementations SHOULD allow administrators of clients and servers
+to disable the spin bit either globally or on a per-connection basis. Even when
+the spin bit is not disabled by the administrator implementations SHOULD disable
+the spin bit on a randomly chosen fraction of connections. However, connections
+may be configured to explicitly enable spinning, for example in the case of
+explicit customer support and debugging.
+The random selection process SHOULD be designed such that on average the spin
+bit is disabled for at least one eighth of network paths. The selection process
+should be externally unpredictable but consistent for any given combination of
+source and destination address and port. For instance, the implementation might
+have a static key which it uses to key a pseudorandom function over these values
+and use the output to determine whether to send the spin bit. The selection
+process performed at the beginning of the connection SHOULD be applied for all
+paths used by the connection.

Gah, this last sentence is bad.

Please move this to a subsection under the Short Header description.

 Spin Bit (S):
 
-: The sixth bit (0x20) of byte 0 is the Latency Spin Bit, set as described in
-  {{!SPIN=I-D.ietf-quic-spin-exp}}.
+: The third most significant bit (0x20) of byte 0 is the Latency Spin Bit.
+
+: When the spin bit is disabled, endpoints MAY set the spin bit to any value,

Please don't have so many paragraphs nested like this.  A forward reference to a section that includes this text would be much better.

 Spin Bit (S):
 
-: The sixth bit (0x20) of byte 0 is the Latency Spin Bit, set as described in
-  {{!SPIN=I-D.ietf-quic-spin-exp}}.
+: The third most significant bit (0x20) of byte 0 is the Latency Spin Bit.
+
+: When the spin bit is disabled, endpoints MAY set the spin bit to any value,
+and MUST accept any incoming value. It is RECOMMENDED that they
+set the spin bit to a random value either chosen independently for each packet,
+or chosen independently for each path and kept constant for that path.
+
+: If the spin bit is enabled for the connection the endpoint maintains a spin

```suggestion
: If the spin bit is enabled for the connection, the endpoint maintains a spin
```

 Spin Bit (S):
 
-: The sixth bit (0x20) of byte 0 is the Latency Spin Bit, set as described in
-  {{!SPIN=I-D.ietf-quic-spin-exp}}.
+: The third most significant bit (0x20) of byte 0 is the Latency Spin Bit.
+
+: When the spin bit is disabled, endpoints MAY set the spin bit to any value,
+and MUST accept any incoming value. It is RECOMMENDED that they
+set the spin bit to a random value either chosen independently for each packet,
+or chosen independently for each path and kept constant for that path.
+
+: If the spin bit is enabled for the connection the endpoint maintains a spin
+value, 0 or 1, and sets the spin bit in the short header to the currently stored

```suggestion
value and sets the spin bit in the short header to the currently stored
```

> @@ -3997,6 +4067,7 @@ version.  See {{QUIC-INVARIANTS}} for details on how packets from different
 versions of QUIC are interpreted.

+

```suggestion
```

-- 
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/2364#pullrequestreview-196893254

---

From: Brian Trammell <[email-masked]>
Date: Mon, 28 Jan 2019 03:35:38 -0800

britram commented on this pull request.

+1

-- 
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/2364#discussion_r251378841