HTTP/3 DATA_WITH_OFFSET frame

Samuel Hurst <samuelh@rd.bbc.co.uk> Thu, 18 February 2021 15:10 UTC

Return-Path: <samuelh@rd.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 723703A133A for <quic@ietfa.amsl.com>; Thu, 18 Feb 2021 07:10:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 kY6MW5VYiEl6 for <quic@ietfa.amsl.com>; Thu, 18 Feb 2021 07:10:06 -0800 (PST)
Received: from tlsmtp.bbc.co.uk (tlsmtp1.telhc.bbc.co.uk [132.185.161.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B51D83A1336 for <quic@ietf.org>; Thu, 18 Feb 2021 07:10:05 -0800 (PST)
Received: from gateh.lh.bbc.co.uk ([10.118.193.77]) by tlsmtp.bbc.co.uk (8.15.2/8.15.2) with ESMTPS id 11IFA2Tc018330 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Feb 2021 15:10:04 GMT
Received: from mailhub0.rd.bbc.co.uk ([172.29.120.128]) by gateh.lh.bbc.co.uk (8.14.5+Sun/8.13.6) with ESMTP id 11IFA2No014484; Thu, 18 Feb 2021 15:10:02 GMT
Received: from [172.29.197.148] (port=40338) by mailhub0.rd.bbc.co.uk with esmtp (Exim 4.92) (envelope-from <samuelh@rd.bbc.co.uk>) id 1lCkwM-0001dz-Hd; Thu, 18 Feb 2021 15:10:02 +0000
From: Samuel Hurst <samuelh@rd.bbc.co.uk>
Subject: HTTP/3 DATA_WITH_OFFSET frame
Autocrypt: addr=samuelh@rd.bbc.co.uk; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptRE1FWFZacHVSWUpLd1lC QkFIYVJ3OEJBUWRBTC9KNCtaMUVGRGNLR3ByNzdvYzZKRWVOemZXQ0t4VXBCNXJ6CnVUN0tm dHEwSTFOaGJYVmxiQ0JJZFhKemRDQThjMkZ0ZFdWc2FFQnlaQzVpWW1NdVkyOHVkV3MraUpZ RUV4WUkKQUQ0V0lRUi9NaG1CLzJtREdicVJEUUZGM3RxdVp0UWdLd1VDWFZacHVRSWJBd1VK Q1dZQmdBVUxDUWdIQWdZVgpDZ2tJQ3dJRUZnSURBUUllQVFJWGdBQUtDUkJGM3RxdVp0UWdL L0p6QVFEZUxZZjNSQVgzOTk3THgzcDZnbTZQClRCYlJSV2JVeDJ0VHovOTFzQytUREFFQTVz di9GdFdNN045VS83L0p2MDdQVkpGS0VTS3JQRENFdHBDSHdwbG0KblF5NE9BUmRWbW01RWdv ckJnRUVBWmRWQVFVQkFRZEFnVWpnZ09jb25pV0RFWkxQazBQNHVvRGtGMmZubFR1egpmSVpl dm9kTGhBNERBUWdIaUg0RUdCWUlBQ1lXSVFSL01obUIvMm1ER2JxUkRRRkYzdHF1WnRRZ0t3 VUNYVlpwCnVRSWJEQVVKQ1dZQmdBQUtDUkJGM3RxdVp0UWdLNys4QVFETFZlaW9rVlBIaUlG TXpWRzltS2dib3A1am1CQkkKazFpUWw5d0NJMVFOUVFEK0x1LzhRZnJPcjBSOGNEemUxSjlW Q0VmQmVjcjdROElHcVhCWHpZWkU4QTA9Cj1UNFJwCi0tLS0tRU5EIFBHUCBQVUJMSUMgS0VZ IEJMT0NLLS0tLS0K
To: IETF QUIC WG <quic@ietf.org>, ietf-http-wg@w3.org
Message-ID: <5c96284e-ea35-0454-3c03-225e9bb5efd9@rd.bbc.co.uk>
Date: Thu, 18 Feb 2021 15:09:54 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="a12KS9NZ2TVZ6rt0Rjms3FkvqrNzG7ioz"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/TnQZPSL53_0IpmtHKrC8D3ueIqM>
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, 18 Feb 2021 15:10:07 -0000

Hello to both the QUIC and HTTP working groups,

******
TL;DR: I've made a new extension frame (with I-D [1]) to support binary
framing of multipart range requests in HTTP/3.
******

A long time ago we started an effort to adapt the QUIC wire protocol to
be able to efficiently deliver HTTP resources to many receivers using
multicast [2]. We have been using this in our experiments with delivery
of segmented live media for some time now [3], using multipart range
requests to fill gaps from packet loss.

As part of these experiments, we discovered issues with maintaining
synchronisation between senders and receivers using HTTP/3 DATA frames
carried on an unreliable transport. In order to help mitigate this
issue, I have come up with a new DATA_WITH_OFFSET extension frame [1]
which is based on the H3 DATA frame but carries a HTTP representation
offset in the header.

Outside of the multicast work, I discovered that such a frame could be
more generally useful in terms of supporting multipart range requests in
HTTP/3. My current understanding is that a HTTP/3 endpoint that supports
range requests will perform single range requests fine, but I would
imagine that performing a multipart range request with HTTP/3 would
require both endpoints to use the existing multipart/byteranges media
type in the body response. This means that endpoints aren't able to take
advantage of features such as binary framing and header compression that
HTTP/3 and QPACK give.

I've put together a short internet draft as a starting point. Section 3
describes the extension frame itself, and section 4 describes how it is
used with multipart range responses. As part of this, I've modified the
syntax of the Content-Range response header to make it an explicit
list-based field as the current HTTP/3 spec doesn't allow you to use
more HEADERS frames between DATA frames. This extra functionality is
dependent on endpoints negotiating support with a HTTP/3 settings parameter.

Any comments or feedback are welcomed.

Best Regards,
Sam


[1]:
https://datatracker.ietf.org/doc/draft-hurst-quic-http-data-offset-frame/
[2]: https://datatracker.ietf.org/doc/draft-pardue-quic-http-mcast/
[3]:
https://www.bbc.co.uk/rd/projects/dynamic-adaptive-streaming-ip-multicast-dasm