Re: [QUIC] Version Negotiation vs. Option Negotiation

[Niklas Widell <[e-mail]>]

Hi Patrick,
Thanks for the explanation, no reason to worry then I suppose.

Cheers
Niklas

--


On 19/05/16 16:27, "Patrick McManus" <[e-mail]<mailto:[e-mail]>> wrote:

Hi Niklas,

You're basically envisioning the process that was used for versioning http/2 during standardization.. it was known as various "http2-draft-N" with a variety of N's that were negotiated at each connection setup. Each token corresponded to a specific Internet-Draft. The last version was simply renamed "h2" and the draft versions faded from the Internet.

This worked quite well at enabling experimental deployments - especially because the fallback to HTTP/1 was realistically always possible in the case there wasn't a shared version between client and server. Some deployments supported just 1 version at a time, and relied more heavily on HTTP/1 fallback, others offered a small set of options in order to get the most experience possible. This worked very well and could work for this effort too as long as the higher level service had a TCP fallback available. The Internet-Drafts also took the, un-necessary imo, step of declaring some drafts as "for implementation" and others not. There were a few deployments of non-implementable drafts anyhow between consenting peers.

During development this is a much cleaner approach than a matrix of mix and match features negotiated on a per feature basis - especially when you're trying to make sense of the data gathered from the running code.

-Patrick



On Thu, May 19, 2016 at 4:48 AM, Niklas Widell <[e-mail]<mailto:[e-mail]>> wrote:
Hi,
While I understand the need to explicitly identify versions when doing experimentation with a new protocol, I do have a couple of concerns based on the fact that QUIC assumedly will be a very widely deployed protocol:


  *   Keeping client/server versions deployed in synch is no problem if the same entity controls both endpoints and can update them freely (like Google does for QUIC in Chrome today). However, in the wild I expect different versions to be deployed, some in places where they might be very hard to upgrade (like IoT and other embedded devices). I thus see a maintenance headache to keep several simultaneous versions of QUIC server code running just to be able to serve different clients.
  *   Who will bump the version? Is it IETF?
  *   Maybe the idea is to keep increasing the version of QUIC until the QUIC specs are final, and use that final version as THE version that hosts need to implement, but then maybe that should be stated in the charter, or is it implicitly assumed?

Cheers,
Niklas Widell
Ericsson AB

--


On 18/05/16 18:03, "QUIC on behalf of Ian Swett" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

Thanks Jana, the clarification is appreciated.

On Tue, May 17, 2016 at 8:37 PM, Jana Iyengar <[e-mail]<mailto:[e-mail]>> wrote:
Greetings,

I am modifying the charter text that currently says "loss detection and recovery, congestion control, and negotiation" to say "loss detection and recovery, congestion control, version negotiation, and option negotiation", and I wanted to clarify the roles of version negotiation and option negotiation in the current version of QUIC, since it may be a source of a bit of confusion.

Version negotiation is used for determining how to read and parse a QUIC packet. Any "on-the-wire" change to the core protocol or generally any change that impacts interoperability results in a version change. Version negotiation, as described in Section 7.1 of draft-tsvwg-quic-protocol-02<https://tools.ietf.org/html/draft-tsvwg-quic-protocol-02#section-7.1>, allows the two ends to agree on the version to use for communication. This is, as Christian puts it, a "blunt" instrument, and it should be treated as such. Versioning is not generally intended to be used for negotiating the equivalent of TCP options. The expectation is that versioning will also allow continued experimentation with QUIC.

I believe that no current IETF transport has versioning.

In addition to versioning, QUIC currently exchanges transport parameters -- the equivalent of TCP options -- during the handshake. This is described, though not in much detail, in Section 9 of draft-quic-protocol-02<https://tools.ietf.org/html/draft-tsvwg-quic-protocol-02#section-9>. Examples of things that may be negotiated via these parameters include max open streams, among other things. This mechanism may be used for negotiating features as well, such as use of multipath.

The initial drafts will contain both of these mechanisms.

- jana

_______________________________________________
QUIC mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/quic



_______________________________________________
QUIC mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/quic