Subject: [quicwg/base-drafts] Merge normative -spin-exp text into -transport (#2369)

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

#2364 proposes to merge the normative part of -spin-exp (how to generate the signal, and how to probabalistically participate) into -transport.

There appears to be some lack of clarity on the Bangkok consensus on the ; per @larseggert let's discuss this here on this issue (and the list) instead of in 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/issues/2369

---

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

There are a few apparently-open questions (which I thought were resolved, and apparently @ihlar too, since he submitted #2384); my understanding of the state is in __bold__ below:

1. Is the plan to __(a) merge the spin bit text into -transport__ or to (b) publish spin-exp as a separate RFC.

2. If 1(b), is the intended status of the spin bit __(a) Proposed Standard__ or Experimental (as the spin bit must be __Proposed Standard__ if 1(a)).

This understanding derives from the state of discussions after the London and Bangkok meetings (copied from #2364 comments):

- 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 (which is what #2364 does). This plan together the discussion about 2119 language made it clear to me that the spin bit would be Proposed Standard.

-- 
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/2369#issuecomment-457130052

---

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

(also from the #2364 discussion...) FWIW, I do think that advanced heuristics for deriving metrics from the spin bit signal are properly experimental, but since that's generalized measurement methodology work, it rather belongs in IPPM than QUIC (note this is a personal opinion, without IPPM chair hat). Most of the simple how-to-measure text currently in spin-exp should move into the (informational) -manageability draft, and my understanding as editor is that a PR for that is forthcoming (addressing quicwg/ops-drafts#58).

-- 
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/2369#issuecomment-457132448

---

From: mirjak <[email-masked]>
Date: Thu, 24 Jan 2019 01:52:45 -0800

My understanding was always that the plan was to merge this into the transport doc and never that the the spin-exp is meant to be published as an own doc. The chairs only hold us at some point to create an own doc (instead of trying to get an PR up to date) such that it is easier to people to experiment until we have a final decision and merge it in.

We even had a hum on this in Bangkok:

6. To include the spin bit in the specification, as laid out here. Some decisions can still be made.

Yes: Strong hum (4-5 hums for inclusion, no against)

No: Medium-Strong hum (less)

I asked at the end of the session if we are ready to merge and got a yes. I don't know what this discussion is about because we really have already clear consensus here. I will close the issue.

-- 
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/2369#issuecomment-457135370

---

From: Marcus Ihlar <[email-masked]>
Date: Thu, 24 Jan 2019 09:53:27 +0000 (UTC)

I agree with the statements above, and I cannot recollect that option b was ever discussed.

-- 
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/2369#issuecomment-457135588

---

From: Marten Seemann <[email-masked]>
Date: Thu, 24 Jan 2019 01:56:32 -0800

Not sure about the process and the formalities, but since the spin-bit is an optional feature, and several implementations are not planning to implement it, I think it would improve the readability of the already very long transport document (141 pages!) to keep it clearly separated in its own document. This would relieve implementers from having to skip over irrelevant text.

-- 
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/2369#issuecomment-457136673

---

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

on review of the minutes, agree with @mirjak: paging @martinthomson and @janaiyengar with their editor hats on: once you're awake can you have a look and close this issue?

-- 
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/2369#issuecomment-457140701

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 24 Jan 2019 02:18:37 -0800

I am not sure if "including spin-bit in the specification" means including it in the transport draft, considering the fact that we already have multiple documents that specify the QUIC protocol: invariants, transport, TLS, recovery. Having another document seems to be a natural way of integrating a specific feature.

Among the documents, I think it might be natural to assume that the transport document would have the shortest lifetime, while there is fair chance that TLS and recovery documents will be reused in QUIC v2. I'd also assume the spin-bit draft to have a longer lifetime, because I do not think we want to change the definition of the spin bits for each QUIC version.

That seems to be one reason to prefer having spin bit as a separate draft regardless of the status of the document. Is there a specific reason to incorporate the spin-bit specification into the transport draft?

-- 
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/2369#issuecomment-457144113

---

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

That's an interesting perspective.
On that note though, an argument for describing how to set the bit in the transport draft is that version specific changes to the protocol will require updates to the text on how to set the bit.
We might see things like mulitpath, reliability modes with vastly different acking schemes etc, which could have direct impact on how/if/when to filp bits.

Also, it is only the normative text that would be included in the transport draft and that's not a large amount of text at all. 

Finally, there are two pieces of text relating to the bit that we want to publish, the normative part which is short and intended for implementors and text on how to detect the bit and how/what to measure etc. That second piece is the one which will require more text and is likely of less interest to implementors, therefore a good fit for it would be the manageability 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/issues/2369#issuecomment-457190877

---

From: Loganaden Velvindron <[email-masked]>
Date: Thu, 24 Jan 2019 10:23:24 -0800

@britram yes, I'm working on it. I'm reading the latest changes that are proposed and adjusting accordingly for https://github.com/quicwg/ops-drafts/issues/58

-- 
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/2369#issuecomment-457303320

---

From: hardie <[email-masked]>
Date: Thu, 24 Jan 2019 18:30:30 +0000 (UTC)

On Thu, Jan 24, 2019 at 2:18 AM Kazuho Oku <[email-masked]> wrote:

> I am not sure if "including spin-bit in the specification" means including
> it in the transport draft, considering the fact that we already have
> multiple documents that specify the QUIC protocol: invariants, transport,
> TLS, recovery. Having another document seems to be a natural way of
> integrating a specific feature.
>
> Among the documents, I think it might be natural to assume that the
> transport document would have the shortest lifetime, while there is fair
> chance that TLS and recovery documents will be reused in QUIC v2. I'd also
> assume the spin-bit draft to have a longer lifetime, because I do not think
> we want to change the definition of the spin bits for each QUIC version.
>
> That seems to be one reason to prefer having spin bit as a separate draft
> regardless of the status of the document. Is there a specific reason to
> incorporate the spin-bit specification into the transport draft?
>
The transport draft is the logical place to say that the bit is taken and
to give a pointer to what it is taken for.  I think keeping the normative
text on how to exercise the bit in the transport draft is cleaner.  It may
change in some later version, but this is the v1 meaning of that bit and
its states.

It is not an invariant, in other words, but a v1 feature that may not be
continued in later versions.  That's not quite experimental in the usual
sense--a change to the meaning would occur in later versions.  (You could,
of course, later have a security draft say that even v1 ought to refrain
from spinning, should some issue occur, but that wouldn't change what
spinning meant)

Ted

> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/2369#issuecomment-457144113>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5KjEzrC9dqRFyQi9wXsKCS6IRQD6ks5vGYh7gaJpZM4aQb9w>
> .
>

-- 
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/2369#issuecomment-457305764

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 25 Jan 2019 18:50:37 -0800

So, to be clear, the document split is an entirely editorial decision;
let's not conflate that with discussions about whether spin is PS or not.
Of course, if spin is not PS, then the answer is clear, but even if spin is
PS, whether it remains in a separate document or not is still an editorial
discussion.

I'm happy to have this discussion in Tokyo, but we need to clearly separate
the two discussions.

Please note that the recovery draft is standards track, but it is a
separate document.  Being in a separate document is meaningful for things
that can modularly be separated, esp since the transport document is
already quite long at the moment.

On Thu, Jan 24, 2019 at 10:30 AM hardie <[email-masked]> wrote:

> > <
> https://github.com/quicwg/base-drafts/issues/2369#issuecomment-457144113>,
> > or mute the thread
> > <
> https://github.com/notifications/unsubscribe-auth/ABVb5KjEzrC9dqRFyQi9wXsKCS6IRQD6ks5vGYh7gaJpZM4aQb9w
> >
> > .
> >
>
> —
> You are receiving this because you were mentioned.
> <https://github.com/quicwg/base-drafts/issues/2369#issuecomment-457305764>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AKjg1DoiyxpWo39ZPTuM5ehu8LC7EZh6ks5vGfvFgaJpZM4aQb9w>
> .
>

-- 
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/2369#issuecomment-457794896

---

From: hardie <[email-masked]>
Date: Sun, 27 Jan 2019 14:17:22 -0800

On Fri, Jan 25, 2019 at 6:50 PM Jana Iyengar <[email-masked]>
wrote:

> So I went back to the recording on this (
https://youtu.be/s3aiyJI1xdU?t=5644) and the rough consensus was "to
include the spin bit in the specification".  To my mind, I think that is
clear that the consensus declared there and confirmed on the list was to
have it at the same level as the spec (so, PS).

Amusingly, if you listen past the negotiation section which follows, Mirja
asks whether that means spin bit should get merged into the transport
document.  Not to spoil the ending,  Lars answered yes and then immediately
back tracked to make this an editorial decision, which got general approval.

> the two discussions.
>
> I really don't want to discuss the question of PS vs. experimental in
Tokyo.  I am happy to express my preferences to the editors of the draft on
which I would prefer as a reader, but I think that this is an editorial
decision was settled back in Bangkok.

> And I think that is the crux of the discussion.  Having decided that we
are doing this for version one, I don't think it is useful to call out the
behavior of this bit as separate enough to require an independent doc, any
more than I would suggest doing that for address validation or connection
migration, each of which also could be carved out.

Ted

> >,
> https://github.com/quicwg/base-drafts/issues/2369#issuecomment-457305764>,
> > or mute the thread
> > <
> https://github.com/notifications/unsubscribe-auth/AKjg1DoiyxpWo39ZPTuM5ehu8LC7EZh6ks5vGfvFgaJpZM4aQb9w
> >
> > .
> >
>
> —
> You are receiving this because you commented.
> <https://github.com/quicwg/base-drafts/issues/2369#issuecomment-457794896>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5DXIJKqqH6qVtI20dkmVvSZiMWzBks5vG8J7gaJpZM4aQb9w>
> .
>

-- 
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/2369#issuecomment-457959473

---

From: Brian Trammell <[email-masked]>
Date: Mon, 28 Jan 2019 04:01:08 -0800

In advance of the Tokyo meeting, I came in here to say what @hardie said. On review the std/exp question was pretty clearly answered in BKK.

I personally don't care deeply whether the normative bits of the spin bit live in -transport or in their own document, though I don't buy the arguments for doing so. Addressing @marten-seemann's point: yes, -transport is big (but, after the recent editorial rework, *much* easier to navigate, so there's that). #2364 seems to weigh in at ~2 old-style pages, so while all efforts to reduce document size are appreciated, I don't think not adding the spin bit generation language will make a material difference. Other strictly-optional features of the transport protocol are not separated out. For example, connection migration is strictly-speaking optional on the client side, and is far more complicated both technically and editorially, such that a separate document on connection migration might even make the entire set of final documents more usable. But nobody has yet suggested that (and, to make it very clear, I am not suggesting that either).

-- 
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/2369#issuecomment-458105065

---

From: Roni Even <[email-masked]>
Date: Mon, 28 Jan 2019 09:02:20 -0800

I think like Marcus that the normative text should be in the transport document. It is a short text and this way it will be clearer to the reader.

-- 
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/2369#issuecomment-458214590