QUIC - Our schedule and scope

[Mark Nottingham <[e-mail]>]

Working Group Participants,

Since the Working Group is now approximately one year old, it's a good time to step back and consider how well our work is proceeding.

As chairs, we've been concerned about successfully delivering QUIC since we started this effort. Introducing what is effectively a new transport protocol for the Internet that incorporates not only reliability, congestion control and multiplexing, but also encryption and key exchange, 0RTT handshakes, and what is effectively yet another version of HTTP is a tall order, especially when we started without broad implementation or deployment experience beyond a single vendor.

The nature of our discussions has also caused us some concern, since we seem to range over a variety of topics that are difficult to pin down, thanks to the interdependencies between them. We've explicitly given the editors license to make bold changes in this start-up period as a way to move forward, but even with that, we've struggled to manage our workload -- currently at 170 open issues, with every sign of growing.

Our charter instructs us to deliver the "core" four documents in March 2018, five months away. Many in the Working Group have viewed that milestone as aspirational, but it's becoming clear that on our current course, we'll be lucky to deliver QUIC in 2019.

In our considered view that is unacceptable, because it requires a commitment (in time and effort) that many implementers and engineers will be unwilling to make -- thus impacting the quality of participation we see, and therefore the quality (and success) of QUIC.

To address this, we think two things are necessary:

1) Our Milestone for delivering the "core" QUIC documents (plus applicability and manageability statements) to the IESG should be moved to December 2018, with the understanding that this is a deadline we intend to meet.

2) V1 of QUIC should *only* address the use case of HTTP.

This has a few implications:

* Proposals for changes that are not realistically achievable in the timeline of #1 will be rejected on that basis, because the WG has consensus that the schedule is important.

* V1 will need to document the "invariants" of QUIC -- i.e., the parts on the wire that will not change -- to allow other use cases to be addressed by V2 and beyond.

* Discussion of anything else (including issues, drafts, proposals) that doesn't address the needs of HTTP-over-QUIC will be postponed until after V1 has shipped. 

It's important to understand that this approach is predicated on the notion that QUIC is not the one chance that we have to evolve transport protocols; rather, it represents the start of an evolution, to be followed by any number of new versions that are enabled by assuring that the extensibility and versioning mechanisms are appropriately "greased" (i.e., we take measures to assure that they are available in the future; in other words, counter-ossification).

Please discuss on-list; we'll also be covering this in Singapore, and will call for consensus after gathering further input there.

Regards,

- Your Chairs, Lars Eggert and Mark Nottingham