RE: QUIC - Our schedule and scope

[Roni Even <[e-mail]>]

Hi,
I am OK with the proposal and support the need to focus on what is relevant for the first release supporting HTTP/2 over QUIC.

I have some concerns about
"* 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."

My understanding is that the objective is to design a general Transport Protocol that is not only for HTTP/2.

HTTP/2 is a one specific use case (client server case) while there are already other use cases in the pipe described in individual drafts (RTP, DNS, Multicast, unreliable streams,...). 
I think we must be very careful when defining the "invariants" to allow for other uses. For example look at https://tools.ietf.org/id/draft-aboba-avtcore-quic-multiplexing-00.txt  that tries to discuss one issue in the QUIC point to point case.

Roni 

> -----Original Message-----
> From: QUIC [mailto:[e-mail]] On Behalf Of Mark Nottingham
> Sent: יום ו 27 אוקטובר 2017 09:27
> To: QUIC WG
> Cc: Lars Eggert; Spencer Dawkins at IETF
> Subject: QUIC - Our schedule and scope
> 
> 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