Final DATA frames

Mike Bishop <mbishop@evequefou.be> Thu, 06 December 2018 18:57 UTC

Return-Path: <mbishop@evequefou.be>
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 BE81A130E50 for <quic@ietfa.amsl.com>; Thu, 6 Dec 2018 10:57:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level:
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.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 458NSQiFfK5e for <quic@ietfa.amsl.com>; Thu, 6 Dec 2018 10:57:15 -0800 (PST)
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720127.outbound.protection.outlook.com [40.107.72.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5884130F15 for <quic@ietf.org>; Thu, 6 Dec 2018 10:57:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ob94op0KQQaZHshGYCnoJbTmtbaFWTwB2s5ocQCjm3s=; b=rIOrbEDCpB1iylapIHlVXiLxoBUnQVtHoLQkrYItXcH79y7WBkBHNZFe7gkbXjx2j4cqzLUz8p2JBlr+Ev5+CfaBBmcL0e+ryQ16v3E0ft7vCCZue5iMFLux9K47z51rlPMnTEHPUNpNZhXbo/b8Kqu5FMHFPrJSN53xgX9r5zc=
Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.171.20) by CY4PR22MB0134.namprd22.prod.outlook.com (10.169.186.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.19; Thu, 6 Dec 2018 18:57:13 +0000
Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::e456:e301:9ed5:5f3a]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::e456:e301:9ed5:5f3a%6]) with mapi id 15.20.1382.020; Thu, 6 Dec 2018 18:57:13 +0000
From: Mike Bishop <mbishop@evequefou.be>
To: HTTP Working Group <ietf-http-wg@w3.org>, IETF QUIC WG <quic@ietf.org>
Subject: Final DATA frames
Thread-Topic: Final DATA frames
Thread-Index: AdSNk3kwILOjnml1ST+SUILFzVEMug==
Date: Thu, 06 Dec 2018 18:57:13 +0000
Message-ID: <CY4PR22MB0983449A975232468AF3675FDAA90@CY4PR22MB0983.namprd22.prod.outlook.com>
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=mbishop@evequefou.be;
x-originating-ip: [38.134.241.6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR22MB0134; 6:rxwweGFBIQgCeWNi29LAFxWyHCK5m2RUczAi6lQf4Cc+QbAmCJIiab44UMiJBuWOprvCQW2pHoHB+afoadnrfoLo+1XATFnANRq87IT75On/XRRPHlpM0GVs0ezZgy+dSZgwqAKzpIqWim97O3aTWgpAzuMEbTxSe19BHBZJzcHnEmUyf4wO2HCf3dRpGOPSsrrWt0EiW/KUzPDsA9Ac3Mwujg+TkGMaAEkxrmZcpq1uug/Fq8h8GrjoDu94nuYU5i7uabu345Julq5xeBMMTTQFqCef4R8ZoRkR7Lh/qR9T/n7tSz3/TeBdHCMoyn6OkprMeoc9b37lniKVzef1xOP8Y7FDpsZ5WFsbcVS3H/MnYoznSEhchHA8+UHsUfiHS35qFqgqOkKdTvYDzfbSSPddIAi7Y4p9VUBxzPAJDjnHMI0yKjIoP3rZh+F9+fyzDuaXG0ocFo82fQHcwo8JlQ==; 5:BgCYOyYekW6FmsfT8j9ls3zC0HYBtf8OGtkPWICcoVi2kmy/KyYvd2oUBKKQe37SF5bCkK+d0OA9NrRmuPqcnB1ossYkwmhYF0tyJ85kREE+6ZRKaEdzZMguu9q4il3ZM+gUCIfcLdM+c/k1uubxOPwiKA3bkwpVqAoHTgW7sdg=; 7:JRt8ikrSXW5I/Xbe15i0Z7O/RqfCrnfcka481UAw+BoW/y4tdNSk4qaB5efsWyg2v/WeXGIE/UxkZkez8lj/se1BZUdnDOnM668HDfcl3tzr9V//48rEsrrTiJDCpCUhXxgIzwiSolpj+rHwCDtOkg==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 05bd0b16-07af-4b2d-c57d-08d65baca27c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(7021145)(8989299)(5600074)(711020)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:CY4PR22MB0134;
x-ms-traffictypediagnostic: CY4PR22MB0134:
x-microsoft-antispam-prvs: <CY4PR22MB01347C4D3F3093A386FEBBECDAA90@CY4PR22MB0134.namprd22.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231455)(999002)(944501520)(4982022)(52105112)(10201501046)(148016)(149066)(150057)(6041310)(2016111802025)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6043046)(201708071742011)(7699051)(76991095); SRVR:CY4PR22MB0134; BCL:0; PCL:0; RULEID:; SRVR:CY4PR22MB0134;
x-forefront-prvs: 087894CD3C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(39830400003)(136003)(346002)(376002)(199004)(189003)(236005)(7116003)(8676002)(102836004)(6436002)(26005)(74316002)(256004)(68736007)(14444005)(106356001)(105586002)(71190400001)(186003)(3480700005)(14454004)(71200400001)(33656002)(7696005)(99286004)(5660300001)(7736002)(6506007)(66066001)(97736004)(316002)(74482002)(110136005)(25786009)(486006)(81156014)(81166006)(8936002)(2906002)(53936002)(86362001)(476003)(6116002)(3846002)(790700001)(54896002)(6306002)(9686003)(55016002)(508600001)(606006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0134; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: S00jwrwrVTgGSyEcE+OzZvVTR8h3qiLxn6g5MImducVG7t+MemPrq9VC9t3iiv2H6AI8NesaHly9oH/AC3mJ+MCY4xuGuafqASiLl2kKdISIFmfvRVwWEbyre3iK2UTlLiQv2h1ogw9Sks1jZRl4E6c6jDKxdoe3jitAKJvb+PlcgPkTVWzhrAY9MEpuxoIxOt6wrSETOGk1B1OwMBtSKgyd0HAD20fRhaI+Si1/vy0NcmBqm+JBxQsHmYLeuyjy93DCRVgQS+EpHbEr092N9cx/EkLUZKOMGhxfIsgxbVxuG+c9VsuaKzxN28eMLt79pdxbjPo1Tkyq1gaw5RtZdDrv9zz29RkWerYYtz6MIfs=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR22MB0983449A975232468AF3675FDAA90CY4PR22MB0983namp_"
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 05bd0b16-07af-4b2d-c57d-08d65baca27c
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2018 18:57:13.5790 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0134
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/DoOsokfs8i5n7BlQddlu69MGKIA>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 06 Dec 2018 18:57:19 -0000

One other change to draw the working groups' attention to, on the opposite end of the stream from initial PRIORITY frames:

Issue #1885<https://github.com/quicwg/base-drafts/issues/1885> points out that, as in HTTP/2, it is inefficient to have to length-prefix each chunk of a response which is being generated incrementally.  In H2, this is unavoidable, because the frames are also the unit of multiplexing.  In H3, the QUIC STREAM frames are always length-prefixed, but we can have very large HTTP-layer frames because they're within a QUIC stream.  This was briefly mentioned in Bangkok.

There are multiple possible approaches to making this better:

  *   Move DATA off-stream.  Considered too extreme a change for this stage of the process and not helpful in all cases, but this can be implemented as an extension.  (See this unsubmitted draft<https://github.com/MikeBishop/quic-external-data>.)
  *   Frames of length 0 extend to the end of the stream.  This seemed like the architecturally cleanest way to solve it, but the prospect of arbitrary frames whose length isn't known from the beginning was potentially challenging for some implementations.
  *   DATA frames of length 0 extend to the end of the stream.  This is a more scoped change, but special-cases the DATA frame.

After discussion on the issue and on the submitted PR (#2098)<https://github.com/quicwg/base-drafts/pull/2098>, the consensus seemed roughly split between the latter two options, but most participants in the discussion seemed amenable to either.  I've merged the PR, which changed the behavior only of DATA frames.

However, Martin pointed out<https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444763104> that this discussion has been entirely on GitHub, and that perhaps an opportunity for list discussion was in order.  If there's not WG consensus to proceed with this change at all, I'll revert it.  If there's consensus to use a different solution instead, I'll create a follow-up PR.

Thanks,
Mike Bishop