Re: Spin bit as a negotiated option

[Kazuho Oku <[e-mail]>]

2018年10月5日(金) 21:27 Brian Trammell (IETF) <[e-mail]>:
>
>
>
> > On 5 Oct 2018, at 12:56, Marcus Ihlar <[e-mail]> wrote:
> >
> > I see your point, but I don´t believe it is a particularly realistic scenario.
> > It is in the interest of the network operators to ensure that their subscribers has as good and consistent experience.
> > Blackholing versions of QUIC has the potential of completely disrupting services and introduce inconsistent behavior.
> > The spinbit is intended as a tool to assist troubleshooting and quality monitoring. Explicitly introducing potentially poor network experience with the hopes that your troubleshooting / monitoring capabilities improves is a really bad idea, even for the most cynical network operator.
>
> + a whole lot to this. Treating middleboxes as a byzantine adversary is a useful thought experiment to determine the corner cases in a protocol, but I do not think we are well served by treating all arbitrary aims and capabilities on path as equally likely.
>
> At the end of the day, every one of the middleboxes that we curse for their ossification was bought and sold because the operator deploying it believed it solved a problem they had, so analyzing the space of likely *intentional* behaviors reduces to an analysis of the business case for each of those behaviors.
>
> I frankly don't see the business case for a spin-bit-blocking middlebox that wouldn't just block QUIC wholesale.

In addition to what Alexandre and Marcus have pointed out, I would
like to second what Brian has stated here.

There are business-related reasons to prefer TCP over QUIC. There are
middlebox vendors selling TCP traffic-shaping middleboxes that claim
to reduce the consumed bandwidth (by reducing the number of
retransmits, utilizing the information about the condition of the
mobile network). There are (still!) networks that give preferential
treatment to non-TLS HTTP because they can deploy transparent,
compressing proxies.

Compared to those cases, spin bit has very weak reason for
preferential treatment (i.e. troubleshooting and quality monitoring).

Besides, the endpoints would also have the choice to expose fake
signal once we start seeing networks blocking QUIC without the spin
bit. Actually, that is the status-quo, in which we do not have any
negotiation. To put it the other way, the endpoints lose nothing by
using the version number field for exposing the availability of the
signal.

> But I'm not a middlebox vendor, so maybe I'm just missing something.
>
> Now, there may be some *unintentional* breakage because some middlebox vendor only happens to analyze traffic that spins when trying to reverse-engineer QUIC, and decides that the non-spinning version is just grease and blocks it. But that seems to me to be more an argument to robustly exercise version negotiation from day one than anything else.
>
> Cheers,
>
> Brian
>
> > From: Marten Seemann <[e-mail]>
> > Sent: den 5 oktober 2018 12:33
> > To: Marcus Ihlar <[e-mail]>
> > Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> > Subject: Re: Spin bit as a negotiated option
> >
> > The problem with using a specific version for implementations that use and don’t use the spin bit is that middleboxes can effectively enforce usage of the spin bit version by blackholing every packet advertising a version that doesn’t use the spin bit. If only a few middleboxes do that, this would force *all* implementations to avoid these versions.
> > Implementations that don’t want to expose their RTT would then have to negotiate a version that is supposed to use the spin bit, but then grease the corresponding bits in order to preserve their privacy. Of course, this would only work if the peer doesn’t enforce compliance. Otherwise, we’ll end up in a world where it’s basically impossible to opt-out of the spin-bit.
> >
> > On Fri, Oct 5, 2018 at 12:15 Marcus Ihlar <[e-mail]> wrote:
> > Hi,
> > I like this approach since it allows us to disregard non-spinning flows by simply observing the initial handshake. This saves us quite some work.
> > On the heuristics part, we cannot get away from it, even if we see the spin version in the initial handshake as there´s no guarantee that an endpoint will set the bit properly anyway.
> > However, for the version where the intent to use spinbit is explicit it actually makes sense for an endpoint to treat non-participating behavior as a protocol error.
> >
> > Marcus
> >
> > -----Original Message-----
> > From: QUIC <[e-mail]> On Behalf Of Mike Bishop
> > Sent: den 5 oktober 2018 00:40
> > To: [e-mail]; Kazuho Oku <[e-mail]>
> > Cc: Brian Trammell <[e-mail]>; IETF QUIC WG <[e-mail]>; Christian Huitema <[e-mail]>
> > Subject: RE: Spin bit as a negotiated option
> >
> > So long as this is the only thing being negotiated, it's not too bad.  If we want to negotiate other things, it quickly gets out of hand.  One could plausibly argue that the spin bit is special in that we actually want parties observing the transaction to understand which option has been selected.
> >
> > It's important to remember, though, that this is information you get only at the beginning of a new connection.  If there's migration or NAT rebinding, it's not guaranteed (and in fact, not intended) than you can correlate it back to a particular previous handshake.  You'll still either need heuristics to identify whether the spin bit is actually in use, or you'll need to ignore any traffic for which you didn't see the handshake.
> >
> > -----Original Message-----
> > From: QUIC <[e-mail]> On Behalf Of [e-mail]
> > Sent: Thursday, October 4, 2018 3:47 AM
> > To: Kazuho Oku <[e-mail]>
> > Cc: Brian Trammell <[e-mail]>; IETF QUIC WG <[e-mail]>; Christian Huitema <[e-mail]>
> > Subject: Re: Spin bit as a negotiated option
> >
> > 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 ?
> >
> > 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
> >
> > 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 ?
> >
> > 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