Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08164130EF4 for ; Fri, 5 Oct 2018 05:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2SQOnAjoppG for ; Fri, 5 Oct 2018 05:22:49 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D535F130EB9 for ; Fri, 5 Oct 2018 05:22:48 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 366D5341C21; Fri, 5 Oct 2018 14:22:47 +0200 (CEST) X-Iway-Path: 0 Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/14501.17478); Fri, 5 Oct 2018 14:22:46 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Fri, 5 Oct 2018 14:22:46 +0200 (CEST) Received: from [195.176.110.242] (account ietf@trammell.ch HELO public-docking-etx-1035.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 69468058; Fri, 05 Oct 2018 14:22:46 +0200 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D3A572D7-1B88-4460-822F-701F0647E782"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Spin bit as a negotiated option Date: Fri, 5 Oct 2018 14:22:45 +0200 In-Reply-To: Cc: "mbishop@evequefou.be" , "alexandre.ferrieux@orange.com" , "kazuhooku@gmail.com" , "quic@ietf.org" , "huitema@huitema.net" To: Marcus Ihlar References: <14531_1538460420_5BB30B04_14531_237_4_c0f3a391-9897-80b0-575b-aa73edad0d52@orange.com> <3E3DBC15-FE42-47CF-AF7A-1F2597ED2390@eggert.org> <24019_1538484216_5BB367F8_24019_26_1_8e6b0d8e-78f0-56c7-e731-da2ff22cb194@orange.com> <08A9C80F-59E6-46EE-A4D4-1F78F5085CF7@eggert.org> <9737_1538485723_5BB36DDB_9737_147_1_82e0e028-b0e8-5e09-7bd5-e66db97c556a@orange.com> <32072_1538492813_5BB3898D_32072_266_1_8380ff40-29fe-269b-8ed7-4331c9e53f4d@orange.com> <45751C2A-9F6C-4447-8D70-11ABE8C07F8D@trammell.ch> <21082_1538561186_5BB494A2_21082_335_1_26ed0978-a314-37d1-3c97-5924d62ef539@orange.com> <4582_1538649993_5BB5EF89_4582_187_1_98109893-8492-6a58-0534-3fc4eaa09dd9@orange.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 12:23:01 -0000 --Apple-Mail=_D3A572D7-1B88-4460-822F-701F0647E782 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Kazuho, Marcus, all, I am of two minds about this proposal. I like it, because: - it exercises the version negotiation machinery in a way beyond = greasing, i.e. such that the negotiated information actually has an = impact on the operation of the protocol. That is worth it for itself, = spin bit or no. - it makes deploying and debugging the spin bit easier -- when = negotiating the spin bit then not using it is a protocol error, then = subtle errors in spin bit implementation don't require fully deployed = heuristic measurement devices to detect. - it is an explicit signal (both to the path and the other endpoint) = about intent with respect to measurability. As Marcus notes, this makes = it easier to reject flow state for non-spinning flows early, which eases = measurement in the (likely) case that some smallish (1-10%) of flows in = the Internet actually spin. I'm less happy about the complexity implied: - in any (non-VEC) implementation of a negotiated spin bit, the = negotiation code will dwarf the code for the signal it's negotiating, = which seems wrong. - if we decide to support other client behaviors for other measurement = goals in the future, it pushes the complexity of deciding what to = measure to the endpoints, as opposed to placing that complexity at the = midpoint. I get that this seems like a good compromise for those who are queasy = about the spin bit for whatever reason. But personally, I see this more = as a good way to meaningfully exercise version control (IMO a hard = requirement for V1) than as a good way to control the use of the spin = bit. Cheers, Brian > On 5 Oct 2018, at 12:15, Marcus Ihlar = wrote: >=20 > 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=C2=B4s 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. >=20 > Marcus >=20 > -----Original Message----- > From: QUIC On Behalf Of Mike Bishop > Sent: den 5 oktober 2018 00:40 > To: alexandre.ferrieux@orange.com; Kazuho Oku > Cc: Brian Trammell ; IETF QUIC WG ; = Christian Huitema > Subject: RE: Spin bit as a negotiated option >=20 > 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. >=20 > 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. >=20 > -----Original Message----- > From: QUIC On Behalf Of = alexandre.ferrieux@orange.com > Sent: Thursday, October 4, 2018 3:47 AM > To: Kazuho Oku > Cc: Brian Trammell ; IETF QUIC WG ; = Christian Huitema > Subject: Re: Spin bit as a negotiated option >=20 > 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 = ? >=20 > If so, how do you envision segmenting the version number space ? >=20 > - direct enumeration: >=20 > 0x00000001 =3D v1dry > 0x00000002 =3D v1 + spinbit > 0x00000003 =3D v1 + spinbit + VEC >=20 > - low order bits for options: >=20 > 0x000001XX =3D v1 + option XX > 0x000002YY =3D v2 + option YY >=20 > 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 ? >=20 > On 10/04/18 11:50, Kazuho Oku wrote: >> Hi, >>=20 >> Thank you for starting the discussion specific to how we could >> possibly negotiate the use of spin bits. >>=20 >> 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. >>=20 >> 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). >>=20 >> I see the following benefits to using the version field as a method = to >> negotiate the use of spin bits. >>=20 >> 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. >>=20 >> 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 :-) >>=20 >> The blocker to this approach has been version negotiation requiring = an >> additional round-trip, but that is going to be resolved by #1755. >>=20 >> 2018=E5=B9=B410=E6=9C=883=E6=97=A5(=E6=B0=B4) 19:06 = : >>>=20 >>> 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. >>>=20 >>> If the consensus is that we must allow for such situations, then >>> there are two >>> possibilities: >>>=20 >>> (a) weak spec language (MAY WISH TO or similar) =3D> many >>> implementations will simply drop it >>>=20 >>> (b) negotiated option where the negotiation mechanism is mandatory >>>=20 >>> 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: >>>=20 >>> - in the first few exchanges of the 5-tuple, use the three bits for >>> option negotiation >>>=20 >>> - then use them as defined by the selected option >>>=20 >>> Example encodings: >>>=20 >>> 000 : nothing >>> 001 : spin bit alone : S00 >>> 010 : spin bit + VEC : SVV >>> ... : other extensions >>>=20 >>> 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. >>>=20 >>>=20 >>>=20 >>>=20 >>> = _____________________________________________________________________ >>> ____________________________________________________ >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>=20 >>=20 >=20 >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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. >=20 > 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. >=20 --Apple-Mail=_D3A572D7-1B88-4460-822F-701F0647E782 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlu3V5UACgkQihK3vwvq RqNmgxAApSDTPZne+fBh5KEUGatQsxa5I5d9VSEoIc7T78FLRUn5piQr/HR4hzYu 47/LqXTb/B64LThxH4Bobbdzc9tQiJUnybQKC+fKzMVR5RQpEm+aWZ/YKlsJXlBC FZU5XVWB9h3LEUCMhe6QYkqjEBBPxyQ9k5iXDF9mZyR2qsVKOSil9Fj2VCn4jHY8 PvTDVcEHS0Ffy/dB0FDCd6nHUSTrsCuNrZjbWK5l9OYlAlbomrpjToNW9IJQMWDs Us96+K4H7AZNYSxWcrE8aEYel6ZWVBwOuOonaSgP2IfzWurXVJcUtCacJv//IU2x a6CfrQd0PcjPyXyr/Cfa+QcbHEWKzpcMTGsb031sn99k1bYaSZemexZlGJzOS1j5 k1r6HElPZQOeYBwVHhRyzvQ+ULnZBzDAublJdVRd+zjpV+L0DGPpF8ASSQafxkJ3 znI0TFzLrpjfMeZ+Pwz/7YnpOqHddtxg/vGAys2wd0IefMOAqtSx+Sp6UIIxLn2n BqzrnnVUJFTmpQNvInUmSx1t+Bgiw6mpFjXVPWm25aRoKBkTkA8aWAYUjY9sQVUg eCKdy6yCzdcM27Mmc/m2Z0cWP2ij9SzbRg3rGsFvpk+qjpObtXjJzZGiEMm/ITfx wY5PBe0vxIC7mP96U5rhGk1r4oMcUnPLxnrLwJWG0SeBFOlf+Vw= =mRHG -----END PGP SIGNATURE----- --Apple-Mail=_D3A572D7-1B88-4460-822F-701F0647E782--