I mostly agree with what others have said here. For the record, my view was that the WG should define what draft-ietf-quic-version-negotiation calls "compatible" version negotiation (i.e., where the Initial was valid for both version N and N+1) but not "incompatible" negotiation. However, the WG consensus was to negotiate neither. I believe it is possible to add version negotiation safely to QUIC after v1 is published, as evidenced by the fact that a design for this already exists in draft-ietf-quic-version-negotiation. ISTM that this falls into the category of "informed WG decisions".
To clarify one point, Jana writes: "If anyone else deploys a vN, the only way we are providing to use it is through Alt-Svc." This is true, but as noted above, the mechanism defined in the current draft the WG is working on would allow a version N+1/version N client to safely offer version N+1 to servers even without an alt-svc hint, which I believe is the right VN target (this is what, for instance, TLS allows). -Ekr On Thu, Jan 7, 2021 at 7:16 AM Mike Bishop <[email protected]> wrote: > To expand on the Alt-Svc case slightly; we removed the “version hint” ALPN > extension from HTTP/3, but later made a decision that an ALPN token can > imply a QUIC version, so offering a set of ALPNs implies the set of > supported QUIC versions. > > > > *From:* QUIC <[email protected]> *On Behalf Of *Jana Iyengar > *Sent:* Thursday, January 7, 2021 2:39 AM > *To:* Martin Thomson <[email protected]> > *Cc:* WG Chairs <[email protected]>; [email protected]; > The IESG <[email protected]>; Lars Eggert <[email protected]>; QUIC WG < > [email protected]>; Benjamin Kaduk <[email protected]> > *Subject:* Re: Benjamin Kaduk's Discuss on draft-ietf-quic-transport-33: > (with DISCUSS and COMMENT) > > > > Ben, > > > > The working group chose actively to make this decision. We had a broken > version negotiation in the spec, and after several long discussions, we > decided to remove the VN process out of the v1. > > > > As it stands, in the worst case, if we find that we cannot do a safe > version negotiation within QUIC, we are stuck with a wasted version field > and a VN packet in the protocol. We can still build and deploy future > versions of QUIC, we just won't be able to negotiate their use within QUIC. > > > > Given that we have a draft in progress, I don't believe that we'll end up > in that state, but even if we do, it's not an unsafe state. The working > group has consensus to move with v1 being incomplete in this regard, > because it's not unsafe. > > > > To be clear, we aren't deferring safety of QUIC v1 (this document and this > protocol) to a future mechanism. We're deferring safety of the version > negotiation mechanism (which we don't have) to when we actually build that > mechanism. If we don't succeed, all we lose are the wasted bits in v1 and > we won't be able to negotiate a different version within QUIC. > > > > If anyone else deploys a vN, the only way we are providing to use it is > through Alt-Svc. That is how major HTTP/3 deployments deploy multiple QUIC > versions today. That allows us to deploy multiple QUIC versions without > needing VN. > > > > Am I helping, or is there a different point that I'm missing? > > > > - jana > > > > On Wed, Jan 6, 2021 at 11:21 PM Martin Thomson <[email protected]> wrote: > > Excision performed in the service of brevity. > On Thu, Jan 7, 2021, at 17:54, Benjamin Kaduk wrote: > > Yes. Do we have any reason to believe that non-standards-track versions > > will or will not intend to coexist with v1? I, at least, do not have any > > data on that question either way. I think this relates to my (3) above > -- > > are we assuming that the problem of downgrade protection only becomes > > relevant when there is specifically an IETF v2? > > We have no information, but that indicates more that we have time to work > on a solution. > > > I agree that it's not necessarily limited to QUIC, though even having > > something that only works within the QUIC ecosystem would be better than > > nothing. It would be surprising to define a protocol with verisons and a > > Version Negotiation packet but end up with technical flaws that prevent > > that packet from working properly, though. > > I am confident that we have enough of an escape valve that we will be able > to define new versions securely. As is the working group (who I am certain > will speak up if they disagree). > > > I think it would be fruitful to try to drill a little more into > > what assumptions we are making when we say (okay, I'm synthesizing a bit, > > but I believe this is the sentiment) that "it is safe to defer > availability > > of this mechanism until a future version of the protocol exists". > > If only we hadn't already discussed this at length. > > > (I recognize that answering that last one may end up being nearly as > hard to > > answer as actually solving the problem.) > > I think that we know the answer in the general sense, just not in the > specific sense of being able to define the bits and manage operational > concerns and other protocol design constraints. > > > My main goal here is to have some reasonable level of confidence that we > > are not putting ourselves in a position that will be hard or impossible > to > > get out of in the future. Depending on what assumptions we are making, > it > > may be very easy or somewhat less easy to achieve such confidence, but > > deferring entirely to future versions of the protocol without information > > on how or when such version(s) will appear leaves me without much > > confidence on that front. > > The working group reached that confidence. I don't know how much effort > I'm able to devote now to helping you reach that state. Perhaps other > participants would like to offer their help now. > >
