Re: [QUIC] h2 mapping - extensions

Mike Bishop <Michael.Bishop@microsoft.com> Fri, 11 November 2016 18:10 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 900B7129C0E for <quic@ietfa.amsl.com>; Fri, 11 Nov 2016 10:10:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level:
X-Spam-Status: No, score=-2.022 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_HELO_PASS=-0.001, 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 7ux9DeuoKjrx for <quic@ietfa.amsl.com>; Fri, 11 Nov 2016 10:10:50 -0800 (PST)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0117.outbound.protection.outlook.com [104.47.42.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A450129C0F for <quic@ietf.org>; Fri, 11 Nov 2016 10:10:50 -0800 (PST)
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=dtkRacf5xpkMLnTXqFtqIXan0/XWHSg9QZ+a9C2pQnU=; b=Cg8cfQNp9w9VwqCm2uyu8eYuUmKQ832V5QOW07mZ+esEq/mjB8ggWkKXh0xiIG7Fb5Ewsv4fKA4W2yYFn6FnV5t/WoAiaygwuHLlIegNBRjJK3n2c+hZ54rGXuFO5nn0a1iHxqBgjczYMVUhnC6p4fDCPW6goBmrWW5kTcG1iTo=
Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Fri, 11 Nov 2016 18:10:46 +0000
Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0707.006; Fri, 11 Nov 2016 18:10:46 +0000
From: Mike Bishop <Michael.Bishop@microsoft.com>
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Thread-Topic: [QUIC] h2 mapping - extensions
Thread-Index: AQHSNhrWVkwvFIuWr0eoGbjCghGjY6DN7XKAgAACUICAADTogIAC3/cAgABN1QCAAJg9gIAAGG2AgAAEPACAAAGNgIAABFgAgAAAdQCAAI4iYIAA+cGAgACK3+A=
Date: Fri, 11 Nov 2016 18:10:46 +0000
Message-ID: <BN6PR03MB27089A7D6F4E42020CF46B4E87BB0@BN6PR03MB2708.namprd03.prod.outlook.com>
References: <CAOdDvNpGf7bcwt3Nyqk0_HPPSoXE-w8ZeYEdo4c76vpuXku0mg@mail.gmail.com> <CAGD1bZa94aJ1C8iqxe4MNrWFsC0mVMYwvTujpBVbL2RyFPwmMw@mail.gmail.com> <CAOdDvNo3YnR2h4aTDFGeRg7Q5t3-DOFPmdAqUeBkncOz1mF=EA@mail.gmail.com> <CAGD1bZaiePu6GJYUUr5GtvD=Ge5_POMtSqdZDKjUxaVa1iO5QA@mail.gmail.com> <CAOdDvNoxC-SQPg9m61vp3P-mqX+YxZVot7Zj9NyXShSPf5J+3Q@mail.gmail.com> <CABkgnnU+Z3q7zZTwKk=f=C1UmZ1Pabd9irL1q5MmU-MDuVqGfA@mail.gmail.com> <027EDB63-EE7D-4318-B6B7-F2D7F3566FB9@lukasa.co.uk> <CABkgnnXdcA3ns5mg3ARC-6C319-wK5gb29iRFWwbSgXPa7Q+xg@mail.gmail.com> <CAKcm_gPhWO_VMn8jWc8NYPV7ikrUvSdTvjQ8i-MmWF+wZWvoHA@mail.gmail.com> <059ACE09-87F2-4705-BDA7-7A2EF712AE25@lukasa.co.uk> <AD23849D-A316-48B4-AEF3-030029B39726@greenbytes.de> <C6297140-3DE8-488B-9644-37C1C474158B@lukasa.co.uk> <BN6PR03MB27084EA442F6464A6A85C51B87B80@BN6PR03MB2708.namprd03.prod.outlook.com> <927B27C6-473C-483D-A13F-DD7FDEC05723@greenbytes.de>
In-Reply-To: <927B27C6-473C-483D-A13F-DD7FDEC05723@greenbytes.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com;
x-originating-ip: [198.134.93.254]
x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:H2kG25mrjUBfS75JnvGqdTTKRThRBpu0iMlmCn6pujLZtRHhdQiEXvEX5C5Ui/253aGCIGcYDTAq7/olaG68jxB1ZeeYZETIw7qL31uiNjNyjbkdHpUhAcWWerP1oVIAxB1fWxu1mclClyJ7F2yH7aOjns4+q6e6joiEtQFe5KXXkfguUBrdfTRb/pGUWwCEHGS/cVWleIDRk08Gs/TEZjHEjZroceHDWzXnf2hyEA1k55BifffyUnmHZPN1DQpX5niyKSY+eWXk1qBK8mjov1YpPbnKh08/OI6c+F5bHiUwUd/1Oa1knOLgjw4AU3aAqZVPdDxhoRfPKmrfk4qOvoWlW1qxRm85zWNslOSdOQQZuxM3GsRT7jdvA35EUc11
x-ms-office365-filtering-correlation-id: a29e484a-fd17-464d-2550-08d40a5e0f34
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2708;
x-microsoft-antispam-prvs: <BN6PR03MB2708FFEAE42F63B9C65A5D2387BB0@BN6PR03MB2708.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(211936372134217);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6045074)(6040176)(6060229)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6046074)(6061226); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708;
x-forefront-prvs: 012349AD1C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(189002)(24454002)(199003)(13464003)(7846002)(99286002)(110136003)(586003)(305945005)(50986999)(5660300001)(76176999)(229853002)(9686002)(6916009)(68736007)(81156014)(97736004)(4326007)(7696004)(8936002)(3846002)(87936001)(74316002)(6116002)(2906002)(33656002)(102836003)(101416001)(2950100002)(77096005)(81166006)(10090500001)(66066001)(10290500002)(7736002)(189998001)(8676002)(92566002)(54356999)(2900100001)(5005710100001)(3280700002)(93886004)(3660700001)(8990500004)(86362001)(105586002)(106116001)(76576001)(86612001)(106356001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2016 18:10:46.1829 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/pWROFowc0EWZLudjksDDv6pQ-hg>
Cc: Ian Swett <ianswett@google.com>, Cory Benfield <cory@lukasa.co.uk>, Patrick McManus <pmcmanus@mozilla.com>, Jana Iyengar <jri@google.com>, "quic@ietf.org" <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
Subject: Re: [QUIC] h2 mapping - extensions
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
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, 11 Nov 2016 18:10:57 -0000

Yes, #5 is basically draft-natarajan-http-over-sctp with a better multi-stream-based transport.  :-)  And while it's a valid option, there's been enough claimed benefit from header compression and a binary format that it's also not my preference.

-----Original Message-----
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] 
Sent: Friday, November 11, 2016 1:50 AM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Cory Benfield <cory@lukasa.co.uk>; Jana Iyengar <jri@google.com>; Ian Swett <ianswett@google.com>; quic@ietf.org; Martin Thomson <martin.thomson@gmail.com>; Patrick McManus <pmcmanus@mozilla.com>
Subject: Re: [QUIC] h2 mapping - extensions


> Am 10.11.2016 um 20:28 schrieb Mike Bishop <Michael.Bishop@microsoft.com>:
> [...]
> It seems like there are a couple paths we can go here:
> 	• HTTP/2 runs over a QUIC stream, modulo changes
> 	• Every request gets a stream; Frames related to request maintain order
> 		• Requires framing within each stream
> 		• Requires changes to HPACK
> 	• Every frame type gets a stream
> 		• Cross-type dependencies (SETTINGS, HPACK) become problematic
> 	• Every frame gets a stream
> 		• Neuters QUIC’s stream-based flow control, since you can no longer throttle individual requests
> 		• Means arbitrarily-large HTTP/2 frames could be permitted without breaking multiplexing
>  
> The present draft is #1.  Combining #3 & #4 gives some flexibility, but then requires knowing on a per-frame type behavior which behavior is needed.  I currently lean toward #2, but I’m willing to be convinced otherwise.  Taking #2 to the extreme, you’re no longer carrying HTTP/2 or anything that pretends to be HTTP/2 – you’re defining a fresh way to carry HTTP using a new transport, and most extensions probably need to be redefined if they still apply.

I think #2 is the only way forward on this list that will end up with a HTTP transport that has comprehensible properties for the caller. (Well, apart from #1 maybe, but who wants that?)

For completeness sake, there is also #5:
- Every request is done in HTTP/1.1 format on a QUIC stream
- A special QUIC stream is used for signalling only

>  
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Cory Benfield
> Sent: Thursday, November 10, 2016 2:27 AM
> To: Stefan Eissing <stefan.eissing@greenbytes.de>
> Cc: Jana Iyengar <jri@google.com>; Ian Swett <ianswett@google.com>; quic@ietf.org; Martin Thomson <martin.thomson@gmail.com>; Patrick McManus <pmcmanus@mozilla.com>
> Subject: Re: [QUIC] h2 mapping - extensions
>  
>  
> On 10 Nov 2016, at 10:25, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
>  
> 
> Am 10.11.2016 um 11:09 schrieb Cory Benfield <cory@lukasa.co.uk>:
> 
> 
> 
> On 10 Nov 2016, at 10:04, Ian Swett <ianswett@google.com> wrote:
> 
> If a single frame type always required in order delivery, but you didn't want HOL blocking on everything, you could use a stream per frame type. 
> 
> As such, any given HTTP/2 frame would need to specify if in-order delivery is necessary, and if so, they should be sent on a single stream.  Otherwise, a stream per frame can be used.  That seems fairly generalizable to me?
> 
> I don’t think it resolves SETTINGS though. H2’s SETTINGS frame includes some connection-wide values that affect all other frames (e.g. SETTINGS_MAX_FRAME_SIZE), so with SETTINGS as written in 7540 it needs to be possible to sort all frames into “before ACK” and “after ACK” if that setting is changed: otherwise it’s very difficult to police the frame size.
> 
> A monotonic counter on SETTINGS could perhaps be used to this effect, but it’d require that all frames carry that counter on them and probably that frames from older settings regimes be discarded after a certain period of time. I’m not entirely sure that that’s a good plan, but it’s the first one that leaps out at me.
> 
> Urgh. But if there is no notion of "before" and "after" between frames on different quic streams, as I understand it, the even this counter would not help. As it affects all frames? or?
>  
> The counter helps only because you identify what SETTINGS regime applies to any given frame. This could also probably be done using some of QUICs packet-tracking and loss-recovery mechanisms (when there are no more frames under SETTINGS regime 3 undelivered we can now forget about SETTINGS regime 3), but I agree: this is pretty gross and I don’t think it’s a good idea. Just a strawman to kick around.