Merge normative -spin-exp text into -transport

[britram]

#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 in the discussion on that PR; per @larseggert let's discuss this here on this issue (and the list) instead of in the PR.

[britram]

There are a few apparently-open questions (which I thought were resolved, and apparently @ihlar too, since he submitted #2364); 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 (b) 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 Moving text on spinbit into transport #2364 does). This plan together the discussion about 2119 language made it clear to me that the spin bit would be Proposed Standard.

[britram]

(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).

[mirjak]

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 would just recommend to close the issue.

[ihlar]

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

[marten-seemann]

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.

[britram]

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?

[kazuho]

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 intended status of spin bit. Is there a specific reason to incorporate the spin-bit specification into the transport draft?

[ihlar]

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.

[loganaden]

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

[hardie]

On Thu, Jan 24, 2019 at 2:18 AM Kazuho Oku ***@***.***> 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

…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2369 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABVb5KjEzrC9dqRFyQi9wXsKCS6IRQD6ks5vGYh7gaJpZM4aQb9w> .

[janaiyengar]

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 ***@***.***> wrote: On Thu, Jan 24, 2019 at 2:18 AM Kazuho Oku ***@***.***> 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 > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > < #2369 (comment)>, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/ABVb5KjEzrC9dqRFyQi9wXsKCS6IRQD6ks5vGYh7gaJpZM4aQb9w > > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2369 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKjg1DoiyxpWo39ZPTuM5ehu8LC7EZh6ks5vGfvFgaJpZM4aQb9w> .

[hardie]

On Fri, Jan 25, 2019 at 6:50 PM Jana Iyengar <notifications@github.com> wrote:

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.

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. I'm happy to have this discussion in Tokyo, but we need to clearly separate

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 editorial choice I would prefer as a reader, but I think that this is an editorial decision was settled back in Bangkok.

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.

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

…

On Thu, Jan 24, 2019 at 10:30 AM hardie ***@***.***> wrote: > On Thu, Jan 24, 2019 at 2:18 AM Kazuho Oku ***@***.***> > 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 > > > > — > > You are receiving this because you are subscribed to this thread. > > Reply to this email directly, view it on GitHub > > < > #2369 (comment) >, > > or mute the thread > > < > https://github.com/notifications/unsubscribe-auth/ABVb5KjEzrC9dqRFyQi9wXsKCS6IRQD6ks5vGYh7gaJpZM4aQb9w > > > > . > > > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > < #2369 (comment)>, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/AKjg1DoiyxpWo39ZPTuM5ehu8LC7EZh6ks5vGfvFgaJpZM4aQb9w > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2369 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABVb5DXIJKqqH6qVtI20dkmVvSZiMWzBks5vG8J7gaJpZM4aQb9w> .

[britram]

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).

[ronieven]

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.

[martinthomson]

I think that we did this already.