Re: Specifying Range in Link preload header for HTTP/2 Push?

Roger Pantos <rpantos@apple.com> Wed, 10 July 2019 03:25 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391D012011C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 9 Jul 2019 20:25:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.752
X-Spam-Level:
X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 DPrJQ76Olm0l for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 9 Jul 2019 20:25:44 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (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 1E5A71200E5 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 9 Jul 2019 20:25:43 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hl3CL-0003Pi-0P for ietf-http-wg-dist@listhub.w3.org; Wed, 10 Jul 2019 03:23:13 +0000
Resent-Date: Wed, 10 Jul 2019 03:23:13 +0000
Resent-Message-Id: <E1hl3CL-0003Pi-0P@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <rpantos@apple.com>) id 1hl3CJ-0003Ox-6K for ietf-http-wg@listhub.w3.org; Wed, 10 Jul 2019 03:23:11 +0000
Received: from nwk-aaemail-lapp02.apple.com ([17.151.62.67]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <rpantos@apple.com>) id 1hl3CF-0004Jr-Rm for ietf-http-wg@w3.org; Wed, 10 Jul 2019 03:23:10 +0000
Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6A3MI6T057959; Tue, 9 Jul 2019 20:22:46 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=qsg+hUcId2ySaG/s/U+KuNhccjLBuTEt6WTGLyGBI78=; b=I189WrzKjLd65Brg/INcvEGqCXdBIvZgoGjAOaTeCR7ut0QsRZlejheMWW7uh+R/CFuC bvEdOee4AA0WLgHav7qgXEUBEDQzAY3CbTHuIhpABZ+vS66SMi5+nx6N/NE8beqtm9h2 7P5gaDhWpnaG7GgtO+wrbH+2++betMrVV4snN6cmcoVuVmuUl/3D6vFB8q8VK/WitkQm lkYUptRvP0oJNXXQZhAvGBa+6fSFjTHqvHW4IYbYuC5pdgxntAySt+71aL7yM/WEa+PW ytAmb3GftL+uYlXEvzmLhx4DBgLKNSIkMuKPlFgc8aCMnyngOs+u3d6Whrrx6camcML/ Lg==
Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2tjr7pbvvx-12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 09 Jul 2019 20:22:45 -0700
Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PUE007U5PDS3320@ma1-mtap-s02.corp.apple.com>; Tue, 09 Jul 2019 20:22:43 -0700 (PDT)
Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PUE00000P1KEF00@nwk-mmpp-sz12.apple.com>; Tue, 09 Jul 2019 20:22:42 -0700 (PDT)
X-Va-A:
X-Va-T-CD: a9ab50ab4460b3b526044e1c109cc39d
X-Va-E-CD: ebec9d363cb3e9032b1aa455ca769df0
X-Va-R-CD: c7d42333b7d05fd8c8092e8412552c6e
X-Va-CD: 0
X-Va-ID: eec43635-738d-4f51-b18a-3f4f79f67604
X-V-A:
X-V-T-CD: a9ab50ab4460b3b526044e1c109cc39d
X-V-E-CD: ebec9d363cb3e9032b1aa455ca769df0
X-V-R-CD: c7d42333b7d05fd8c8092e8412552c6e
X-V-CD: 0
X-V-ID: 593f31a3-e1fe-4f85-8fb4-b2dc5c73c110
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-10_01:,, signatures=0
Received: from [17.234.80.130] (unknown [17.234.80.130]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PUE00DD8PB2V130@nwk-mmpp-sz12.apple.com>; Tue, 09 Jul 2019 20:21:03 -0700 (PDT)
Sender: rpantos@apple.com
Content-type: multipart/alternative; boundary="Apple-Mail=_2FA26474-95A5-41D1-B247-336E3EE20C1B"
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3566\))
From: Roger Pantos <rpantos@apple.com>
In-reply-to: <D2C627CF-C1D3-459E-8489-CD0530A30A9B@apple.com>
Date: Tue, 09 Jul 2019 20:21:01 -0700
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <C1CBCD79-7D43-4346-AD79-11658F848126@apple.com>
References: <63CAE7E1-34E9-42DA-A7DD-1E17223032AE@apple.com> <CALGR9oaNnSKp-a8tj+7ojc_g+AhJQ4jF5Z738mjhXhoesfYqLg@mail.gmail.com> <CC99D5CA-1C8B-4200-A6D4-059ABCD6DBA8@apple.com> <D2C627CF-C1D3-459E-8489-CD0530A30A9B@apple.com>
To: Leif Hedstrom <lhedstrom@apple.com>
X-Mailer: Apple Mail (2.3566)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-10_01:, , signatures=0
Received-SPF: pass client-ip=17.151.62.67; envelope-from=rpantos@apple.com; helo=nwk-aaemail-lapp02.apple.com
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: AWL=0.000, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1hl3CF-0004Jr-Rm 722d27ae8a6d6b62aedbd59c24e2db75
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Specifying Range in Link preload header for HTTP/2 Push?
Archived-At: <https://www.w3.org/mid/C1CBCD79-7D43-4346-AD79-11658F848126@apple.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36780
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>


> On Jul 9, 2019, at 7:01 PM, Leif Hedstrom <lhedstrom@apple.com> wrote:
> 
> 
> 
> On Jul 9, 2019, at 19:05, Roger Pantos <rpantos@apple.com <mailto:rpantos@apple.com>> wrote:
> 
>> 
>> 
>>> On Jul 9, 2019, at 4:03 PM, Lucas Pardue <lucaspardue.24.7@gmail.com <mailto:lucaspardue.24.7@gmail.com>> wrote:
>>> 
>>> Hi Roger,
>>> 
>>> On Tue, 9 Jul 2019, 21:36 Roger Pantos, <rpantos@apple.com <mailto:rpantos@apple.com>> wrote:
>>> Greetings HTTP experts,
>>> 
>>> I’m interested in employing HTTP/2 Push of Range requests for media streaming. It seems like the core h2 protocol handles this well enough; the PUSH_PROMISE can contain a Range header, and at the very least if that ends up in the client push cache then a request for that exact Range should match.
>>> 
>>> That being said, I’d also like to signal the push request to downstream HTTP caches. Push is typically signaled via the Link header with rel=preload, but https://www.w3.org/TR/preload/ <https://www.w3.org/TR/preload/> doesn’t seem to define signaling and associated Range.
>>> 
>>> Has anyone defined a Link extension to signal an associated Range?
>>> 
>>> I've spoken informally to some people on related topics. I presume this is related to Apple's LHLS? Or in lay speak, one approach to low-latency HTTP-based streaming. It'd be great to have a reference to cite when talking around the topic.
>> 
>> That’s right. Here’s a link to the current white paper: https://developer.apple.com/documentation/http_live_streaming/protocol_extension_for_low-latency_hls_preliminary_specification <https://developer.apple.com/documentation/http_live_streaming/protocol_extension_for_low-latency_hls_preliminary_specification>
>> 
>>>  
>>> If not, would anyone object to the following Link extension?
>>> 
>>> range-link-extension = “range” = ranges-specifier
>>> 
>>> where ranges-specifier is defined in RFC 2616.
>>> 
>>> An example would be:
>>> 
>>> Link: </media.mp4>; rel=preload; as=video; type=video/mp4; range=1380-14226
>>> 
>>> 
>>> thanks,
>>> 
>>> Roger Pantos
>>> Apple Inc.
>>> 
>>> The general impression I've observed is that such a range signal in Link would be useful to a number of services, and that there would be benefit in adopting a common signal.
>>> 
>>> Furthermore, while the use of server push might have debatable benefits for the web browsing use case. I'm led to believe that it has affirmative uses in this streaming model. Again, some evidential data would be really interesting. 
>> 
>> The use of Push in our LL-HLS design eliminates one round trip per (partial) media segment downloaded. We’ve got data that shows round trip times to media servers can exceed 100 (or even 200) ms, particularly on cellular networks, even in the U.S. 
>> 
>> When playing at very low delay-from-live (2s or less), the client can only buffer around 1s ahead of the playhead (because that’s all there is). New segments must be loaded in a timely fashion to prevent playback from stalling. Speeding that up by 10% of the overall budget is a significant win. 
>> 
>> In addition, keeping the TCP send pipe full improves lost-packet recovery performance of the primary resource that accompanies the push (via fast retransmit).
>> 
>>> 
>>> Finally, server push and caching is an interesting area that might benefit from some more information. Some of the WG might be interested in how this gets implemented in your use case.
>> 
>> Certainly. I’d be happy to answer as I’m able to.
> 
> FWIW, server push sort of dictates that you can write the object to cache if I recall.

Absolutely. That’s what we want.

> 
> That much said, caching partial objects can be tricky at best. Do you treat each range as a unique object ?

That’s the simplest approach, and it should work pretty well for LL-HLS. From a cache point of view it’s effectively the same as the non-byterange case, where each partial segment has its own URL.

> If so, how do you avoid an explosion in various range sizes?

There shouldn’t be much of an explosion. The byte ranges pushed are determined by the origin, and there won’t be more than about 20 per URL. So it hopefully won’t hurt cache search performance too much.

> If you try to combine partial objects into one larger object,  the cache code tend to get tricky (we gave up in ATS).
> 
> This is probably something worthwhile discussing to understand the implications both on servers and clients. It’s non trivial, but definitely interesting!

Agreed,


Roger.

> 
> Cheers,
> 
> — Leif 
> 
>> 
>> If there’s nothing currently defined, what would be the next step? To write an Internet-Draft specifying the Link extension?
>> 
>> (I’m also interested in a way for a server to indicate that pushed resources are to be strictly ordered (such as via a dependency tree). Today, multiple pushes get multiplexed at the default priority. But that’s a different discussion.)
>> 
>> 
>> Roger.
>> 
>>> 
>>> Cheers
>>> Lucas