Re: [Hls-interest] LL-HLS: status-code expected in the response to the PRELOAD request

[Andrew Crowe <[e-mail]>]

Hi Roger,

Thanks for the reply. I believe that this method actually removes the
burden of parsing out range requests, and is equivalent in burden to
collapsing the individual requests whether from ranges or paths. Limelight
does currently support the suggested path based range methodology (as do
some other CDNs, I believe). However, if no other parties on this thread
are interested in this concept we're willing to conceded and make some
minimal changes to support the open ended range requests as currently
described.

Regards,
-Andrew

On Tue, Sep 8, 2020 at 1:19 PM Roger Pantos <[e-mail]> wrote:

> Hello Andrew,
>
> On Sep 2, 2020, at 11:56 AM, Andrew Crowe <[e-mail]> wrote:
>
> Hi folks,
>
> Great discussion so far. The crux of this issue is that
> https://tools.ietf.org/html/rfc7233#section-4.2 does not define the
> behavior of Content-Range requests when both the size of the object and the
> range desired are not known. When you know the size, easy, just put the
> size. When you know the range but not the size, you can use X-Y/* because
> the absolute size of the object is not necessarily involved in satisfying
> the request.
>
> The current discussion is focusing around the limitations of RFCs, and
> offering solutions that butt up against the edge of some definitions,
> possibly requiring changes or amendments to properly codify newly expected
> behavior. There may be a way around the undefined open ended range request
> behavior: Don’t have the client make range requests.
>
> What if the manifest structure were adjusted in the following manner:
>
> #EXTINF:4.000,
> v1_1-7727.m4s
> #EXT-X-PROGRAM-DATE-TIME:2020-07-28T17:37:48.771Z
>
> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s/range/0-64266",INDEPENDENT=YES
> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s/range/64267-127299"
> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s/range/127300-185109"
> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s/range/185110-245667”
> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s/range/245668-314242”
> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s/range/314243-375122"
> #EXT-X-PRELOAD-HINT:TYPE=PART,URI="v1_1-7728.m4s/range/375123-"
>
> In this adjusted manifest, we are moving the byte range information into
> part of the URL.  The origin or proxy server would be expected to translate
> the /range/X-Y into a request which targets bytes X-Y of the file
> referenced in the range data specified in the URL.  In this situation, the
> client would be expecting back a 200 response, and therefore not require a
> content-range response header and would follow any such similar
> requirements for a Chunked Transfer encoded asset request.
>
>
> I don’t love this approach because it adds a weird burden to both the
> client and the edge (as well as the origin) to recognize the equivalency of
> "v1_1-7728.m4s/range/375123-“ while it is a PRELOAD-HINT with
> "v1_1-7728.m4s/range/375123-42667” (or whatever) once it becomes a
> full-fledged part.
>
> Since the basic issue here seems to be a limitation in the current HTTP
> spec, I’m relatively happy with the 9007199254740991 hack while we wait for
> the HTTP folks to come up with a more formal solution.
>
> Note that you can achieve your basic “don’t have the client make range
> requests” objective using the non-range syntax of LL-HLS where each Partial
> Segment is given a unique URL, for instance "v1_1-7728.m4s/range/0-“,
> "v1_1-7728.m4s/range/64267-“ etc. that gets interpreted privately by the
> origin. That does cause a small amount of duplication in your edge cache at
> the leading edge, unless you do some clever cache mapping to avoid it.
>
>
> regards,
>
> Roger Pantos
> Apple Inc.
>
>
> Treating the preload assets as discrete objects should help ensure
> consistency with proxies involved and will help bypass the concern of the
> content-range header in the  RFC specs which are being called into
> question.
>
> Another alternative would be to use query terms to denote the range,
> rather than using a format such as /range/x-y
>
> Example:
>
> #EXTINF:4.000,
> v1_1-7727.m4s
> #EXT-X-PROGRAM-DATE-TIME:2020-07-28T17:37:48.771Z
>
> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s?range=0-64266",INDEPENDENT=YES
> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s?range=64267-127299"
> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s?range=127300-185109"
> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s?range=185110-245667”
> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s?range=245668-314242”
> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s?range=314243-375122"
> #EXT-X-PRELOAD-HINT:TYPE=PART,URI="v1_1-7728.m4s?range=375123-"
>
> Once again, this adjustment is meant to work around the limitations of the
> RFCs in relation to open ended range requests when the content length is
> not known in advance.
>
> Thanks,
> -Andrew (LLNW)
>
>
> On Wed, Aug 26, 2020 at 11:50 AM Pieter-Jan Speelmans <
> [e-mail]> wrote:
>
>> Hi Will
>>
>> I would indeed expect this behavior to be the case if the client is
>> configured to collapse part requests when the part hold off is configured
>> to three part duration.
>>
>> P
>>
>>
>> On Wed, 26 Aug 2020, 17:44 Law, Will, <wilaw=[e-mail]>
>> wrote:
>>
>>> @Roger – that’s good news. A clear directive within the spec will help
>>> achieve consistent player behavior as well as consistent CDN and origin
>>> response.
>>>
>>>
>>>
>>> One note on the applicability of RFC 8673 would be that it seems to
>>> apply for *any request for LL-HLS content that is open-ended,* not only
>>> for PRELOAD-HINT requests. The interesting thing about range-based
>>> addressing with LL-HLS is that the player on average only need make one
>>> request per media type per segment duration. This is true in nearly all
>>> start-up and switch conditions too, with the sole exception being when the
>>> PRELOAD-HINT represents the first part in a new segment.. The following
>>> playlist snippets illustrate this point. Can you confirm if this is the
>>> expected client behavior?
>>>
>>>
>>>
>>> *Case #1:*
>>>
>>> #EXTINF:4.000,
>>>
>>> v1_1-7727.m4s
>>>
>>> #EXT-X-PROGRAM-DATE-TIME:2020-07-28T17:37:48.771Z
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="64267@0
>>> ",INDEPENDENT=YES
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="63033@64267"
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="57810@127300"
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="60558@185110"
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="68575@245668"
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="60880@314243"
>>>
>>> #EXT-X-PRELOAD-HINT:TYPE=PART,URI="v1_1-7728.m4s",BYTERANGE-START=375123
>>>
>>>
>>>
>>> A player seeing this playlist at startup would need to make a single
>>> request of the form
>>>
>>>
>>>
>>>    GET / v1_1-7728.m4s HTTP/2
>>>
>>>    Host: example.com
>>>
>>>    Range: bytes=0-9007199254740991
>>>
>>>
>>>
>>> The origin would respond by bursting the bytes it has (up to 375123) and
>>> then releasing the remainder as each part boundary becomes available. This
>>> would give it the independent part it needs to start, plus all the segments
>>> up to and including the HINTed part.
>>>
>>>
>>>
>>>   HTTP/2 206 Partial Content
>>>
>>>    Content-Range: bytes 0-9007199254740991/*
>>>
>>>
>>>
>>>
>>>
>>> *Case #2:*
>>>
>>>
>>>
>>> #EXTINF:4.000,
>>>
>>> v1_1-7727.m4s
>>>
>>> #EXT-X-PROGRAM-DATE-TIME:2020-07-28T17:37:48.771Z
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="64267@0
>>> ",INDEPENDENT=YES
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="63033@64267"
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="57810@127300"
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="60558@185110"
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="68575@245668
>>> ",INDEPENDENT=YES
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="60880@314243"
>>>
>>> #EXT-X-PRELOAD-HINT:TYPE=PART,URI="v1_1-7728.m4s",BYTERANGE-START=375123
>>>
>>>
>>>
>>> A player seeing this playlist at startup would make a single request of
>>> the form
>>>
>>>
>>>
>>>    GET / v1_1-7728.m4s HTTP/2
>>>
>>>    Host: example.com
>>>
>>>    Range: bytes=245668-9007199254740991
>>>
>>>
>>>
>>> Origin would respond by bursting the bytes from 245668 to 375123 and
>>> then releasing the remainder as each part boundary becomes available.
>>>
>>>
>>>
>>>   HTTP/2 206 Partial Content
>>>
>>>    Content-Range: bytes 245668-9007199254740991/*
>>>
>>>
>>>
>>>
>>>
>>> *Case #3:*
>>>
>>>
>>>
>>> #EXTINF:4.000,
>>>
>>> v1_1-7727.m4s
>>>
>>> #EXT-X-PROGRAM-DATE-TIME:2020-07-28T17:37:48.771Z
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="64267@0
>>> ",INDEPENDENT=YES
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="63033@64267"
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="57810@127300"
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="60558@185110"
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="68575@245668
>>> ",INDEPENDENT=YES
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="60880@314243"
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="62485@375123"
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="61325@437608"
>>>
>>> #EXTINF:4.000,
>>>
>>> v1_1-7728.m4s
>>>
>>> #EXT-X-PRELOAD-HINT:TYPE=PART,URI="v1_1-7729.m4s",BYTERANGE-START=0
>>>
>>>
>>>
>>> This player would make a first request for
>>>
>>>
>>>
>>>    GET / v1_1-7728.m4s HTTP/2
>>>
>>>    Host: example.com
>>>
>>>    Range: bytes=245668-498933
>>>
>>>
>>>
>>> Note that this request is NOT using the RFC8673 convention for
>>> last-byte-pos, because the last-byte-pos is known. The origin would respond
>>> by adding in a content-length response header, signaling the total bytes in
>>> the content-range header and bursting all these bytes since all the content
>>> is fully available.
>>>
>>>
>>>
>>>   HTTP/2 206 Partial Content
>>>
>>>   Content-Length: 253265
>>>
>>>   Content-Range: bytes 245668-498933/498934
>>>
>>>
>>>
>>> The player would then make a second open ended range request for
>>>
>>>
>>>
>>>    GET / v1_1-7729.m4s HTTP/2
>>>
>>>    Host: example.com
>>>
>>>    Range: bytes=0-9007199254740991
>>>
>>>
>>>
>>> Origin would respond by releasing the content as each part becomes
>>> available.
>>>
>>>
>>>
>>>   HTTP/2 206 Partial Content
>>>
>>>    Content-Range: bytes 0-9007199254740991/*
>>>
>>>
>>>
>>> This is the steady state condition of the player from this point on. It
>>> keeps making a series of open-ended range requests against each new segment
>>> starting at an offset of 0. This continues until it needs to switch,
>>> encounters a discontinuity or playback pauses.  During this time it
>>> continues to update the media playlist at a period of the part duration, in
>>> order to maintain its knowledge of the internal structure of each segment
>>> and also to discover discontinuities.
>>>
>>>
>>>
>>> Cheers
>>>
>>> Will
>>>
>>>
>>>
>>>
>>>
>>> *From: *Roger Pantos <rpantos=[e-mail]>
>>> *Date: *Tuesday, August 25, 2020 at 12:38 PM
>>> *To: *"Law, Will" <[e-mail]>
>>> *Cc: *"[e-mail]" <[e-mail]>
>>> *Subject: *Re: [Hls-interest] LL-HLS: status-code expected in the
>>> response to the PRELOAD request
>>>
>>>
>>>
>>> Okay, I think that approach would work well enough. We’ll take a closer
>>> look at it once iOS 14 et al are in the can. Assuming it works out we can
>>> put a reference to that part of RFC 8673 into the EXT-X-PRELOAD-HINT
>>> section of the HLS spec.
>>>
>>>
>>>
>>> We can also update our clients to conform to that behavior, although it
>>> might take a while to land that in an iOS/macOS release..
>>>
>>>
>>>
>>>
>>>
>>> Roger.
>>>
>>>
>>>
>>> On Aug 19, 2020, at 5:11 PM, Law, Will <
>>> wilaw=[e-mail]> wrote:
>>>
>>>
>>>
>>> @Roger – re “*Note that when using H2 (or H3) that there is a fourth
>>> option, which is to return 206 and not supply any Content-Length header at
>>> all.”*
>>>
>>> This is a good point however it still leaves open the question of what
>>> content-range header should be returned. Per the H2 spec (snippet below),
>>> the requirements of HTTP/1.1 Range Requests are carried forward under
>>> HTTP/2. These requirements RFC7233 state that the “the server
>>> generating the 206 response MUST generate a Content-Range header field,”
>>> and also that the byte-range must contain a last-byte-pos value and that a
>>> value of * can be used for an unknown total length of the object but it
>>> cannot be used for last-byte-pos. Since the last-byte-pos is not known in
>>> this case, we have the same problem with H2 that we have with H1.
>>>
>>>
>>>
>>> The solution proposed by https://tools.ietf.org/html/rfc8673
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8673&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=KkevKJerDHRF9WRs8nW8Ew&m=QUdz0dxv2aY_mBTjkxa9DgyIAgM1TzH8j_w8i_spX2w&s=oMR4zfPXrho88f5S0AzpDC5z3D0bwKPKsOm2kymBHBk&e=>
>>>  would seem to work for H2 as well as it would for H1. Per this
>>> solution, the client should never make an open ended range request if it is
>>> expecting an aggregated response from a fixed offset. It should instead
>>> send a request with a very large number (9007199254740991 has been proposed
>>> in this thread) as the last-byte-pos in the range request. This would
>>> signal the server (or origin) to begin a response that starts at the
>>> requested offset and aggregates over time until the object is completely
>>> transferred.
>>>
>>>
>>>
>>>
>>> https://tools.ietf.org/html/rfc7540#section-8
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7540-23section-2D8&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=KkevKJerDHRF9WRs8nW8Ew&m=QUdz0dxv2aY_mBTjkxa9DgyIAgM1TzH8j_w8i_spX2w&s=BzKvOAFjcWwd1oNZnRb_NH1b50kZYcJ245JTW83T53g&e=>
>>>
>>> 8. HTTP Message Exchanges
>>>
>>> HTTP/2 is intended to be as compatible as possible with current uses
>>> of HTTP. This means that, from the application perspective, the
>>> features of the protocol are largely unchanged. To achieve this, all
>>> request and response semantics are preserved, although the syntax of
>>> conveying those semantics has changed.
>>>
>>> Thus, the specification and requirements of HTTP/1.1 Semantics and
>>> Content [RFC7231], Conditional Requests [RFC7232], Range Requests
>>> [RFC7233], Caching [RFC7234], and Authentication [RFC7235] are
>>> applicable to HTTP/2.
>>>
>>>
>>>
>>> -Will
>>>
>>>
>>>
>>> *From: *Roger Pantos <rpantos=[e-mail]>
>>> *Date: *Wednesday, August 19, 2020 at 1:17 PM
>>> *To: *"[e-mail]" <[e-mail]>
>>> *Subject: *Re: [Hls-interest] LL-HLS: status-code expected in the
>>> response to the PRELOAD request
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Aug 17, 2020, at 4:30 PM, Law, Will <
>>> wilaw=[e-mail]> wrote:
>>>
>>>
>>>
>>> Hello
>>>
>>>
>>>
>>> I am requesting a clarification on the expected server response status
>>> code when a client makes an open-ended range request against a media
>>> segment when playing back LL-HLS.  Consider the following media playlist
>>> snippet:
>>>
>>>
>>>
>>> #EXTINF:4.000,
>>>
>>> v1_1-7727.m4s
>>>
>>> #EXT-X-PROGRAM-DATE-TIME:2020-07-28T17:37:48.771Z
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="64267@0
>>> ",INDEPENDENT=YES
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="63033@64267"
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="57810@127300"
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="60558@185110"
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="68575@245668"
>>>
>>> #EXT-X-PART:DURATION=0.500,URI="v1_1-7728.m4s",BYTERANGE="60880@314243"
>>>
>>> #EXT-X-PRELOAD-HINT:TYPE=PART,URI="v1_1-7728.m4s",BYTERANGE-START=375123
>>>
>>>
>>>
>>> To start-up, the client would issue 6 GET range-requests , starting at
>>> the independent part The server would respond with a 206 response for each
>>> and a content-range response header indicating the range being returned.
>>>
>>>
>>>
>>> The next request would be for the PRELOAD-HINT part. This would be a GET
>>> request with a “range: 375123-“. The client is indicating it wants to
>>> receive this object starting at offset 375123 and continuing to the end of
>>> the segment.
>>>
>>>
>>>
>>> How should the origin (or proxy server) respond to this PRELOAD request?
>>> Three possible options
>>>
>>>    1. It holds back any response until the end of segment, returning at
>>>    that time a 206 response with a content-range of 375123 – T/T+1 (where
>>>    represents total size of segment). This would ruin the low latency behavior
>>>    for the client.
>>>    2. It starts an immediate response, signaling 206 with
>>>    content-range: 375123 - */*. This is actually forbidden by the RFC’s, which
>>>    indicate that the last-byte-pos cannot hold a value of “*”.
>>>    3. It starts an immediate response, signaling a 200 response and if
>>>    serving H1 to a proxy server which then serves H2 to the client, a
>>>    "Transfer-Encoding: chunked" response header.
>>>
>>>
>>>
>>>
>>>
>>> Note that when using H2 (or H3) that there is a fourth option, which is
>>> to return 206 and not supply any Content-Length header at all. This (I
>>> believe) became the expected behavior when HTTP/2 removed support for
>>> chunked transfer encoding:
>>> https://httpwg.org/specs/rfc7540.html#HttpSequence
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__httpwg.org_specs_rfc7540.html-23HttpSequence&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=KkevKJerDHRF9WRs8nW8Ew&m=R-IP9-Hj--z3sXAZZX9rokMs5qnnChNcbFO4PLft4_M&s=QsYGd9vU3GGNCIKQjBOnvGSnXVh73OH0Kyi1KcPWpDw&e=>
>>>
>>>
>>>
>>>
>>>
>>> Roger Pantos
>>>
>>> Apple Inc.
>>>
>>>
>>>
>>>
>>> Option [3] looks to be the most correct however it raises the question
>>> of  whether a 200 response (chunked-transfer or not) implies to the client
>>> that is has received the complete object i.e starting at offset 0 instead
>>> of offset 375123. As a CDN, we need to build a behavior that is robustly
>>> supported by all HTTP clients and not just a particular class of
>>> application. The proxy-server cannot tell if is serving a LL-HLS client or
>>> some other client, therefore we need a consistent behavior when it is asked
>>> for an open-ended range request against an object of unknown size.
>>>
>>>
>>>
>>> So the questions are:
>>>
>>>    1. Is a 200 status-code expected in the response to the PRELOAD
>>>    request?
>>>    2. If so, are there other clients or applications on the internet
>>>    that would break if we did so for *all open-ended range requests
>>>    against objects of unknown size* (outside of the application space
>>>    of LL-HLS)?
>>>
>>>
>>>
>>> Cheers
>>>
>>> Will
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Hls-interest mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/hls-interest
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_hls-2Dinterest&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=KkevKJerDHRF9WRs8nW8Ew&m=R-IP9-Hj--z3sXAZZX9rokMs5qnnChNcbFO4PLft4_M&s=Yv0CtXmSurk_NBFYprpu4mN6giQ1RFARMSK8zxyR6Rg&e=>
>>>
>>>
>>>
>>>
>>> --
>>> Hls-interest mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/hls-interest
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_hls-2Dinterest&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=KkevKJerDHRF9WRs8nW8Ew&m=QUdz0dxv2aY_mBTjkxa9DgyIAgM1TzH8j_w8i_spX2w&s=VZVvigVlbA5cXwltSzsJSJ8ZrOEueLMD1jVYQO51fRk&e=>
>>>
>>>
>>> --
>>> Hls-interest mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/hls-interest
>>>
>>
>> *Legal Notice *
>> You can find the latest terms and policies of THEO Technologies under
>> www.theoplayer.com/terms including our "GENERAL TERMS AND CONDITIONS".
>> In the absence of a signed agreement between you and THEO Technologies, by
>> replying to this email these terms apply to the relevant transaction
>> between us.
>> The contents of this email message and any attachments are intended
>> solely for the addressee(s) and contain CONFIDENTIAL and/or privileged
>> information and are legally protected from disclosure. If you are not the
>> intended recipient of this message, please immediately alert the sender by
>> reply email and then delete this message including any attachments and you
>> are hereby notified that any use, dissemination, copying, or storage of
>> this message or its attachments is strictly prohibited.
>> Full security of emails over the internet cannot be ensured. Despite our
>> efforts it is your responsibility to provide for your protection.
>> Global HQ: THEO Technologies NV, Philipssite 5 bus 1, 3001 Heverlee,
>> Belgium - BE 0847.829.290 - CEO: Steven Tielemans
>> --
>> Hls-interest mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hls-interest
>>
>
>
> --
> [image: Limelight Networks] <https://www.limelight.com/>
> Andrew Crowe* Architect*
> EXPERIENCE FIRST.
> [phone] <+1+859+583+3301>
> www.limelight.com
> [image: Facebook] <https://www.facebook.com/LimelightNetworks>[image:
> LinkedIn] <https://www.linkedin.com/company/limelight-networks>[image:
> Twitter] <https://twitter.com/llnw>
> --
> Hls-interest mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hls-interest
>
>
>

-- 
[image: Limelight Networks] <https://www.limelight.com>
Andrew Crowe* Architect*
EXPERIENCE FIRST.
[phone] <+1+859+583+3301>
www.limelight.com
[image: Facebook] <https://www.facebook.com/LimelightNetworks>[image:
LinkedIn] <https://www.linkedin.com/company/limelight-networks>[image:
Twitter] <https://twitter.com/llnw>