Re: QUIC - Our schedule and scope

[Ian Swett <[e-mail]>]

I think pushing back the date for the core documents to December 2018 and
focusing on finishing HTTP-over-QUIC is the right choice for all the
reasons you outline above.

On Fri, Oct 27, 2017 at 2:26 AM, Mark Nottingham <[e-mail]> wrote:

> 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
>