QUIC - Our schedule and scope

Mark Nottingham <mnot@mnot.net> Fri, 27 October 2017 06:27 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B7513B105 for <quic@ietfa.amsl.com>; Thu, 26 Oct 2017 23:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=KbuMhiZ6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NdpywrPx
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U-fJqfFwSh2 for <quic@ietfa.amsl.com>; Thu, 26 Oct 2017 23:27:03 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB544139B9F for <quic@ietf.org>; Thu, 26 Oct 2017 23:27:02 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3AB7420A5D; Fri, 27 Oct 2017 02:27:02 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 27 Oct 2017 02:27:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=zUxxHDZQ7l80G64Sx3M5wD3ePND2Iest5gm5Z7rW390=; b=KbuMhiZ6 S0vji5IcQPsZAqDVNCC2UFdifOY6JLPsNx/1pMoRZ8+xP4cUoIfw5FV2UWHMq6Du C0JBCL7VnVG9MB1tiHuRjJn9nL/6nKQaQK5GqjPkbEZtNkRHg4UosTzKExOXytBh SEMDtruA4pGIUeGO8cj/mhPNOEyPqvoLM+hJbLFpa5PPNJIRoIT0PKCzQaCsCbTE rNTVBkC7KqFNhKGid84/AqZHnzu9CpqfelvjibRzxlPELeANT4yIfl8fWThLMyWU ttd1s7AMUW9zVZb63WVkHovuXhTsvbCms6irOHL8FCc7uoLSTxD/fjEE7hCyI6/Y 1yKP5s44qpN+eQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=zUxxHDZQ7l80G64Sx3M5wD3ePND2I est5gm5Z7rW390=; b=NdpywrPxc6J4GleHK/wq+MRbn6A3X/NC1oldtx+7k6A85 yOKFh7O3ScQsS66e2t2jlIsV4rM7FaGMzDThbO8Zybh2BZS3Q3bbQV7r3DY5gF5h sUWzMatGboBmgWm8q6HhabUFtI7ZJrxuFOzjPccRQor9+iWPJB0bRtGh//8v1mmS OQPhV3h3zu3pO26QLxPLH1xh00FHzqy6fk9z5KbhMBtOaIFZsAynWVibpHxrEkQ4 9fPXuPLXxbMPCZPBl8S/dKy9aTrVk4QhJWPKHNRoa8waJKgtySSjUX3lUO0B8/FL JpisaJk45tqa419BQuccbjQF7IX+xO/GBeH27y72A==
X-ME-Sender: <xms:ttHyWXhX-CAqX-TxDOCqk9kYE1tCYkQSAEwGAyCGuW64PmC7rvPUSA>
Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 190BA7E139; Fri, 27 Oct 2017 02:27:00 -0400 (EDT)
From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Subject: QUIC - Our schedule and scope
Message-Id: <BCAD8B83-11F7-4D4A-B7B3-FCBF8B45CBB4@mnot.net>
Date: Fri, 27 Oct 2017 17:26:58 +1100
Cc: Lars Eggert <lars@netapp.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
To: QUIC WG <quic@ietf.org>
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Tq33kWYZM9_y1F3iCfV3pjVO9Hg>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Oct 2017 06:27:05 -0000

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