Re: Spin bit as a negotiated option

[Kazuho Oku <[e-mail]>]

2018年10月4日(木) 19:46 <[e-mail]>:
>
> Thanks Kazuho. Using version numbers directly was an obvious choice, but so far
> I was discouraged by strong language in the spec, saying 0x00000001 was the
> unavoidable point of convergence after all 0xFF0000XX experiments. So in essence
> you're proposing to weaken that a bit, right ?

I am not sure if we have reached consensus that QUICv1 should use
0x00000001 as the one and only number for the version number field.

My understanding is that it is simply written as such because I-D is a
draft of a RFC. A RFC needs to clarify the value of version number
field it uses, and I-D needs to have a paragraph that amends on how
the draft-versions uses the field.

>
> If so, how do you envision segmenting the version number space ?
>
>   - direct enumeration:
>
>         0x00000001 = v1dry
>         0x00000002 = v1 + spinbit
>         0x00000003 = v1 + spinbit + VEC
>
>   - low order bits for options:
>
>         0x000001XX = v1 + option XX
>         0x000002YY = v2 + option YY

I do not think we can segment the version number space, because IMO it
essentially means making spin bits an invariant. My understanding is
that spin bits is something specific to v1.

QUICv1 might use different values on the version number field to
represent if spin bits is (or other signals are) available, but that
does not mean that v2 will expose the same signals or they would use
the version number field for indicating that.

If it is the case that the use of 0x1xx for V1 might give people the
impression that the lower bits are used to indicate the availability
of unencrypted signals across multiple versions, I think starting from
0x00000001 (i.e. the one you describe as "direct enumeration") would
be preferable.

>
> Also, are we sure that this explosion won't weigh on the new VN scheme, inducing
> slower convergence due to longer lists on either side ?

I do not think that is an issue for v1, because what currently at
stake is if we should assign one or two extra version numbers (i.e.
one for spin bit, and possibly another for spin+vec as a separate
draft).

If folks agree to expose other signals that requires a "configuration"
to be exposed as well, then they can define a new version number that
introduces a new field to the long header format for exposing the
"configuration."

>
> On 10/04/18 11:50, Kazuho Oku wrote:
> > Hi,
> >
> > Thank you for starting the discussion specific to how we could
> > possibly negotiate the use of spin bits.
> >
> > Regarding the topic, my preference goes to using the version number
> > field of the long header for negotiating the presence of spin bits, or
> > any additional signal being exposed to the network.
> >
> > For example, QUICv1 without spin bit could use version 0x101, and v1
> > with spin bit could use 0x102. In the future, we can assign a
> > different version number for QUICv1 with multiple spin + VEC (or
> > people interested in testing the feature can designate a private
> > version number even before that).
> >
> > I see the following benefits to using the version field as a method to
> > negotiate the use of spin bits.
> >
> > 1. One of the concern regarding spin bits has been that they could
> > lead to ossification. Spin bits are not part of the Invariants, but if
> > the observation tools start looking at those bits without checking the
> > version number field, we will have the pressure to not change how the
> > bits are used. Using the version number to indicate the presence of
> > spin bits is the best approach to resolve such concern.
> >
> > 2. We have hoped to roll out multiple versions of QUIC in a small
> > interval so that the version number field does not get ossified. The
> > best solution is obviously to roll out two flavors of the protocol
> > that uses different version numbers at the same time. We will have a
> > real-world use of version negotiation from day one, because we are in
> > a condition where implementors have different opinions on if they
> > should support spin bit :-)
> >
> > The blocker to this approach has been version negotiation requiring an
> > additional round-trip, but that is going to be resolved by #1755.
> >
> > 2018年10月3日(水) 19:06 <[e-mail]>:
> >>
> >> On 10/03/18 09:58, Brian Trammell (IETF) wrote:
> >> > Backing off the MUST for now for such situations is IMO a good tradeoff,
> >> > though, especially since we only need fractions of a percent of deployment to
> >> > start seeing useful signal for baseline/anomaly measurement of large
> >> > aggregates.
> >>
> >> If the consensus is that we must allow for such situations, then there are two
> >> possibilities:
> >>
> >>   (a) weak spec language (MAY WISH TO or similar) => many implementations will
> >> simply drop it
> >>
> >>   (b) negotiated option where the negotiation mechanism is mandatory
> >>
> >> In the vein of (b), Christian suggested offline to introduce negotiation to
> >> allow for experimentation of the remaining two reserved bits. Then may be we can
> >> synthesize both ideas by the following proposal:
> >>
> >>   - in the first few exchanges of the 5-tuple, use the three bits for option
> >> negotiation
> >>
> >>   - then use them as defined by the selected option
> >>
> >> Example encodings:
> >>
> >>   000 : nothing
> >>   001 : spin bit alone : S00
> >>   010 : spin bit + VEC : SVV
> >>   ... : other extensions
> >>
> >> The negotiation mechanism allows both endpoints to force 000.
> >> And since it is in the clear first byte, it allows on-path observers to identify
> >> the option without resorting to heuristics; this helps in the case of a small
> >> support ratio.
> >>
> >>
> >>
> >>
> >> _________________________________________________________________________________________________________________________
> >>
> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> >> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> >>
> >> This message and its attachments may contain confidential or privileged information that may be protected by law;
> >> they should not be distributed, used or copied without authorisation.
> >> If you have received this email in error, please notify the sender and delete this message and its attachments.
> >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> >> Thank you.
> >>
> >
> >
>
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>


-- 
Kazuho Oku