RE: Higher layer comments on stream 0 proposal, WG schedule, and gQUIC

Lucas Pardue <Lucas.Pardue@bbc.co.uk> Wed, 23 May 2018 21:47 UTC

Return-Path: <Lucas.Pardue@bbc.co.uk>
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 3FA45127010 for <quic@ietfa.amsl.com>; Wed, 23 May 2018 14:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 mjt1RPSSbITt for <quic@ietfa.amsl.com>; Wed, 23 May 2018 14:47:09 -0700 (PDT)
Received: from mailout1.telhc.bbc.co.uk (mailout1.telhc.bbc.co.uk [132.185.161.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E84E1201F8 for <quic@ietf.org>; Wed, 23 May 2018 14:47:09 -0700 (PDT)
Received: from BGB01XI1010.national.core.bbc.co.uk (bgb01xi1010.national.core.bbc.co.uk [10.161.14.14]) by mailout1.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w4NLl72R011569; Wed, 23 May 2018 22:47:07 +0100 (BST)
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1010.national.core.bbc.co.uk ([10.161.14.14]) with mapi id 14.03.0361.001; Wed, 23 May 2018 22:47:07 +0100
From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
To: Ted Hardie <ted.ietf@gmail.com>, IETF QUIC WG <quic@ietf.org>
Subject: RE: Higher layer comments on stream 0 proposal, WG schedule, and gQUIC
Thread-Topic: Higher layer comments on stream 0 proposal, WG schedule, and gQUIC
Thread-Index: AQHT8tMTqawdr9+Tv0OIrhKYX9dM0KQ92Rhq
Date: Wed, 23 May 2018 21:47:05 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB3F654@bgb01xud1012>
References: <CA+9kkMA0QnSmvbGOktngU+B-eC7CJFXLicEZfxQga6m6Z+gJLQ@mail.gmail.com>
In-Reply-To: <CA+9kkMA0QnSmvbGOktngU+B-eC7CJFXLicEZfxQga6m6Z+gJLQ@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.19.161.212]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23862.002
x-tm-as-result: No--1.103400-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/DOPsD9u7R1N0eXU9h7bWFi2MLFo>
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: Wed, 23 May 2018 21:47:11 -0000

Hi Ted,

Thanks for your thoughts.

> My back of the envelope calculation is that this means at least one more cycle of specification and interop will be required before we get back to where we are with draft -11, and that estimate is because I'm in a hopeful mood that Sean and Eric can move the required work in TLS along.  A more practical Ted would see this as adding at minimum 6 months to the schedule.  The changes in TLS are also large enough that I expect that the deployment time to see significant penetration of the new libraries to be longer than it would be for the previous design.   Call it 9 months, with 3 months of error bar.

I can't talk to the merit of this proposal in relation to QUIC transport. As somebody greatly interested in application mapping (with a WIP HTTP/QUIC implementation) I have concerns that progress in this area keeps being pushed back. We have little interop experience in this area to feed back to transport. 

A particular sore point is that the handshake-oriented changes have weak relation to QUIC "steady state', upon which application mappings depend. E.g. Draft 09 and 12 differ little in handling of STREAM frames. 

Regards
Lucas