RE: QUIC - Our schedule and scope

Mike Bishop <Michael.Bishop@microsoft.com> Fri, 27 October 2017 23:52 UTC

Return-Path: <Michael.Bishop@microsoft.com>
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 E9AD013AF2F for <quic@ietfa.amsl.com>; Fri, 27 Oct 2017 16:52:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, 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 (1024-bit key) header.d=microsoft.com
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 gIovvJPRtF89 for <quic@ietfa.amsl.com>; Fri, 27 Oct 2017 16:52:31 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0137.outbound.protection.outlook.com [104.47.41.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E30713F487 for <quic@ietf.org>; Fri, 27 Oct 2017 16:52:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=51kDdC1ACXTjh8fU7/s8GYDFJZ8apOGvdGS+hxo4+uY=; b=DnMsHdluS2L6OTTyyM7z2H/hFEEMPrVPjfRsk/LYpbvHF9uGvctMjhwV82P1RbC3my+EOH7uryUKJ7tGVx46wJN2uk/krwiV5L2Bq1FxlE/vGp0p3wwYg9L2c60y4s4g75uonS7kBH0R7Ns0ri3PPXeuhhGYMrCJ5gwqOptN900=
Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0191.namprd21.prod.outlook.com (10.173.52.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.197.0; Fri, 27 Oct 2017 23:52:28 +0000
Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.20.0197.006; Fri, 27 Oct 2017 23:52:28 +0000
From: Mike Bishop <Michael.Bishop@microsoft.com>
To: Mark Nottingham <mnot@mnot.net>, Patrick McManus <pmcmanus@mozilla.com>
CC: QUIC WG <quic@ietf.org>, Lars Eggert <lars@netapp.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Subject: RE: QUIC - Our schedule and scope
Thread-Topic: QUIC - Our schedule and scope
Thread-Index: AQHTTuyheooSNpGQN0mRPLjjogNQzqL3zoAAgACAwwCAAA224A==
Date: Fri, 27 Oct 2017 23:52:28 +0000
Message-ID: <MWHPR21MB01412C34B445DE223A89F0B1875A0@MWHPR21MB0141.namprd21.prod.outlook.com>
References: <BCAD8B83-11F7-4D4A-B7B3-FCBF8B45CBB4@mnot.net> <CAOdDvNqdXLXEQff03t_YSLMpUpeT74E6XuAMh_C8GNiMM9f_Uw@mail.gmail.com> <52293976-62BE-4420-B0D1-27BAE3A3A556@mnot.net>
In-Reply-To: <52293976-62BE-4420-B0D1-27BAE3A3A556@mnot.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:2::51f]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR21MB0191; 6:cf0pOPfRSlxcr/QwB9XLHIY1kfIJ4JVLlAYf2fbkzdA6dyqW/T2HGslU7ccd6A5Xut9incQSLyglgPvjJQIb8UKTJCKKSSWU6rWYDxgtbFbNiORsmX8u4Rs/RscybKQxQ+9ZD5kTeGlWjdIqgfP5scvUht9jwUNul/EBhcwC1HtwabFmKExELy1lOa4EzDLoGth3sq0fDNp5xa9CBR3jokwHb45Khq3a1o94/U5TQkOVti8CD8VMmmvjeCKFhAHNJ+5zS3srAzu4i1r13eF+H2mN7+Rro6MUnJ7FReXtV0SiHSU16VcyJomBUkTGdJTNcHc/RHCCouFRgreKBV4bBSczRSI7ZplSX6ZqCqkonpA=; 5:ukaKdzzX2CF4atxct8BPbXksyf/RM0aJeFv2slPpcB6k+Gh3zkzysex5cuhbdRY+oLYBQvATZ1YI223PLOF3pDo8/fYdqW8jf8Xr6tVEWc6T93plfaasENePiAq14oXKQVnVEXHScb35g0id/v7v3cx1II6O8Wjeep/M6kYLJDg=; 24:MvN1Ea563zu9GVTOme/YJq16mdhB65KaZKoq1i/u+3m/FoZoarL4hH0cvrprr5lgmLSEw5MRhWX/Y9I+A5EdSkHLoObXZM0D5sdJD4Q3vDY=; 7:Ftc2csQJOXJVy16vJT+CL87x5+y6ARwdAJuj2hQoEFUPUnHTWoNs/n+CEuEn3DdeGxT3F5NauHVIZGjxjU3kLMFAD/SPF4XjErkD6Sv/R70YuTY1Wz+JfYae2x61UIXp6Hf3MmGXlbqPkVsFTiOjMZyJwGMZ+grvLsHvlldysx/nbdoMz528ADOXF5aP5RmRLp3+sIfa0kMI4BEqDv1b7lHs9wEm3R/a3UdEHQHQMe1yvmcwboWUADX6q07yr9lw
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 841d6ffa-0ee9-46b7-459d-08d51d95c822
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603238); SRVR:MWHPR21MB0191;
x-ms-traffictypediagnostic: MWHPR21MB0191:
x-exchange-antispam-report-test: UriScan:(189930954265078)(100405760836317)(219752817060721);
x-microsoft-antispam-prvs: <MWHPR21MB01916296AB46CBF5BFEFAE21875A0@MWHPR21MB0191.namprd21.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(3231020)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0191; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0191;
x-forefront-prvs: 0473A03F3F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(47760400005)(53754006)(199003)(189002)(13464003)(24454002)(7520500002)(81166006)(561944003)(10090500001)(478600001)(25786009)(3280700002)(86612001)(5660300001)(3660700001)(76176999)(8676002)(54356999)(81156014)(2950100002)(101416001)(6306002)(97736004)(99286003)(102836003)(6116002)(189998001)(68736007)(106356001)(74316002)(53546010)(229853002)(9686003)(8936002)(7696004)(50986999)(22452003)(105586002)(39060400002)(33656002)(72206003)(966005)(2906002)(316002)(55016002)(8990500004)(6436002)(14454004)(54906003)(6506006)(110136005)(7736002)(4326008)(53936002)(86362001)(6246003)(575784001)(10290500003)(305945005)(77096006)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0191; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 841d6ffa-0ee9-46b7-459d-08d51d95c822
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 23:52:28.6493 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0191
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/v9BlXBB_dOFa32nPZZd-gnUvTdk>
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 23:52:34 -0000

I'm with Patrick.  While I do believe that HTTP/2 stayed on the right side of the line most of the time, I have heard other people in the HTTP community who very vocally expressed their opinion that we put finishing on time above being willing to re-examine issues as broader experience arose.  To some extent, that's self-fulfilling -- the longer the process takes, the less something we reached consensus on 20 months ago is guaranteed to represent the consensus of the currently-active participants, and we'll naturally have to rehash the same discussions whenever the composition of the group changes too much.

I'm supportive of reiterating that our "first and best" customer for v1 will be HTTP, and implementing a policy of tabling non-HTTP-blocking issues until v2.  I don't believe that's inconsistent with our current charter, other than to recognize that there may be more such issues than just multipath.  As the saying goes, shipping is a feature, and it's going to be more important than some other features in our backlog.  But the right path is to reach consensus on that prioritization, not to set a date (even a revised one) and say we're going to the IESG on that date come what may.

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham
Sent: Friday, October 27, 2017 3:55 PM
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: QUIC WG <quic@ietf.org>; Lars Eggert <lars@netapp.com>; Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Subject: Re: QUIC - Our schedule and scope

Hi Patrick,

> On 28 Oct 2017, at 2:13 am, Patrick McManus <pmcmanus@mozilla.com> wrote:
> 
> Hi All,
> 
> First, the observation that elapsed time impacts participation and participation impacts quality is a good observation. Finishing faster (I personally want to go way way faster) is consistent with that and we should look at how we're organized to help make that a reality. Thanks for doing that.
> 
> I'm also not quite as pessimistic as the chairs are. I don't really think this is a linear process - as we get more input from more implementations I think the process will naturally accelerate. The challenge at that later stage will be on not re-opening issues that we have reached consensus on. That's different than the challenge we've been going through for the last year; for the last year we've been building up the basic blocks from an explicitly 0-consensus starting point. Its both not surprising, and a good thing, that many issues have been given scrutiny during that phase.
> 
> 
> On Fri, Oct 27, 2017 at 2:26 AM, Mark Nottingham <mnot@mnot.net> wrote:
> 
>> To address this, we think two things are necessary:
> 
> Just for clarification, you're suggesting these 2 bullets as updates in some form to the wg charter? 

The milestones are a charter update, but chairs can submit revised milestones with approval by the AD, as always. 

I don't think (2) requires a charter update, but if that makes people more comfortable, we can talk about it.


>>  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.
> 
> This needs to be severely unpacked and I do not support it in the way I'm interpreting it.

Understood. We anticipated some discussion. :)


> I think the only way we're going to finish quickly and still create a good product is if all the participants are focused on getting to yes. A shot clock process fix isn't going to get a high quality result - we need an attitude fix :)

I agree, and that's a better way to say it. Thanks.

For those who weren't there, HTTP/2 had a similar focus on "getting to yes", through an understanding that our milestones were serious. It was not "consensus at any cost", it was an agreement that we wanted to ship something we agreed on in a reasonable amount of time. That agreement informed the decisions of individual WG participants -- but in a positive way, as you outline.


> The current charter says "Note that consensus is required both for changes to the current protocol mechanisms and retention of current mechanisms. In particular, because something is in the initial document set does not imply that there is consensus  around the feature or around how it is specified." This remains an important property for the evolution of IETF QUIC. We need to work through all the details as a working group.. I think we can do it faster, but not by inventing an arbitrary forcing function.
> 
> A firm timebox severely undermines the consensus process via simple gamificiation to 'run out the clock' in favor of existing text. That is not in the interest of the end result or getting consensus in a multi-stakeholder process. Indeed it probably increases the chances for a disastrous last call period. However, getting to yes is in everybody's interest. That's a much better motivator.

If you see someone acting strategically like that, please bring it to our attention; it indicates participation in bad faith, and will need to be dealt with.


> I think a better path would be for the chairs to more aggressively declare rough consensus at an earlier stage of discussion than is typically done. I'm not suggesting a different threshold of consensus, just less indulgence in letting issues play all the way out in hopes of convergence. Perhaps also an appeal to all WG members to consider the implications of expressing an opinion on a topic .. Every issue does not need to be a poll for everyone's opinion.. save it for places where your opinion makes a material difference to you. (i.e. acknowledge that two people will disagree on what is a bikeshed vs what is meaningful and stay out of it in the name of progress if you are on the bikeshed side).
> 
> I have no objection to updating the milestone delivery date to something more reasonable, but I do think elevating schedule to be a higher order concern than consensus on the RFC content is wrong.

To be clear -- this does not magically give the chairs the ability to ignore or circumvent the process. We can't elevate anything higher than consensus.

We're asking for the WG to gain consensus that it wants to take the milestone seriously, to inform its further discussions. We'll still need to gather consensus on other things, and if the WG forms a new consensus that a particular proposal merits exceeding the milestone, it can do so. And of course we'll still need to gain consensus on what we put in the documents (and what we leave out).


> I think your second suggestion, scoping around HTTP for v1, is more likely to get us to a successful finish. As we get later in this process, it will be more important.
> 
>  
>> * 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.
> 
> Browsing through the archives I actually don't see very many issues that are totally non-http (certainly < 10%). But there probably are quite a few that are simpler to resolve if only http is taken into account.

Indeed.

--
Mark Nottingham   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mnot.net%2F&data=02%7C01%7Cmichael.bishop%40microsoft.com%7C0ceb5fbd79e84c7e3b1e08d51d8dba4a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636447416919107375&sdata=egqQsHDuy89iTrPcB%2FdMnBaTMFJPn4%2F%2Ftw5ZncLRmgk%3D&reserved=0