Re: [Hls-interest] Question about RFC8673 reference in draft-pantos-hls-rfc8216bis-09

Andrew Ryan <aryan@llnw.com> Wed, 05 May 2021 17:43 UTC

MIME-Version: 1.0
References: <CAGw2CfPQegoU5zK=yrE77kNgFqyeggjd=tnULg4dnq9y8DBCYg@mail.gmail.com> <145A45F4-E9B7-4982-B973-6EFCFC2F1E72@akamai.com>
In-Reply-To: <145A45F4-E9B7-4982-B973-6EFCFC2F1E72@akamai.com>
From: Andrew Ryan <aryan@llnw.com>
Date: Wed, 05 May 2021 13:42:35 -0400
Message-ID: <CAGw2CfPp-7vbvyRiPUMq4kLwx4qojrLTBnVpoPbzTS5=F-_pZQ@mail.gmail.com>
To: "Law, Will" <wilaw=40akamai.com@dmarc.ietf.org>
Cc: "hls-interest@ietf.org" <hls-interest@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e126ee05c198b993"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hls-interest/3FYdqjADkMIW40bP-vtUM1mI4EY>
Subject: Re: [Hls-interest] Question about RFC8673 reference in draft-pantos-hls-rfc8216bis-09
Precedence: list

Will,
  Thank you for the response.  I agree with your position on the LL-HLS
player behavior in that it would not need to use the workflow described in
RFC8673 (HEAD with Range header), so that should circumvent this particular
concern with RFC8673.  This seems to then align with the idea that RFC8673
is only referenced for it's section pertaining to last-byte-pos and that
there isn't an expectation that other parts of RFC8673 should be considered
relevant.  Once again, Thank you for the reply and explanation.

On Wed, May 5, 2021 at 12:43 PM Law, Will <wilaw=40akamai.com@dmarc.ietf.org>
wrote:

> @Andrew – thanks for raising scrutiny on RFC8673. I did want to point out
> that the use case in RFC8673 concerning a HEAD request that you excerpt
> below is for a client that is a) wanting to find out if a representation is
> continuously aggregating and b) to discover what is the latest byte
> available. A LL-HLS player does not need to do either of these actions. It
> knows that a representation is aggregating (it is a consequence of
> byte-range addressing in the media playlist) and the media playlist very
> conveniently gives it the *starting byte position *of what it needs to
> request. So there is no need for the discovery HEAD request. It can
> immediately proceed to a GET request, using the first-byte value given to
> it by the playlist and the last-byte value of 9007199254740991 (per RFC
> 8673). In my interpretation then, this does not conflict with the RFC8216
> restriction that a server MUST ignore a Range header field received with a
> request method other than GET, since a LL-HLS client will not need to
> execute a HEAD request.
>
>
>
> Cheers
>
> Will
>
>
>
>
>
> *From: *Andrew Ryan <aryan=40llnw.com@dmarc.ietf.org>
> *Date: *Wednesday, May 5, 2021 at 9:08 AM
> *To: *"hls-interest@ietf.org" <hls-interest@ietf.org>
> *Subject: *[Hls-interest] Question about RFC8673 reference in
> draft-pantos-hls-rfc8216bis-09
>
>
>
> Greetings,
>   I was hoping to gain clarification on the reference of RFC8673
> (Experimental) in
> https://tools.ietf.org/html/draft-pantos-hls-rfc8216bis-09#section-4.4.5.3
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-pantos-hls-rfc8216bis-09*section-4.4.5.3__;Iw!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4UIeX2U4$>
>
>   Based on the previous discussions on this list, the use case for
> defining the Very Large Number in the last-byte-pos is understood, and I
> can see the reasoning behind referencing
> https://tools.ietf.org/html/rfc8673#section-4
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8673*section-4__;Iw!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4UVFZHsR$>
> in this case.
>
>   After further review of RFC8673, there is a section which may present an
> issue
>
>   in RFC8673 at https://tools.ietf.org/html/rfc8673#section-2.1
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8673*section-2.1__;Iw!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4V9ngmQd$>
> it states:
>
>     Determining if a representation is continuously aggregating ("live")
>     and determining the randomly accessible byte range can both be
>     performed using the existing definition for an open-ended byte-range
>     request. Specifically, Section 2.1 of [RFC7233] defines a byte-range
>     request of the form:
>
>     byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
>
>     which allows a client to send a HEAD request with a first-byte-pos
>     and leave last-byte-pos absent. A server that receives a satisfiable
>     byte-range request (with first-byte-pos smaller than the current
>     representation length) may respond with a 206 status code (Partial
>     Content) with a Content-Range header field indicating the currently
>     satisfiable byte range.
>
>
>   If we look at RFC7233 at https://tools.ietf.org/html/rfc7233#section-3.1
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7233*section-3.1__;Iw!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4Y0qKZ7W$>
> it states
>
>    A server MAY ignore the Range header field.  However, origin servers
>    and intermediate caches ought to support byte ranges when possible,
>    since Range supports efficient recovery from partially failed
>    transfers and partial retrieval of large representations.  A server
>    MUST ignore a Range header field received with a request method other
>    than GET.
>
>
>   As I interpret the above section of RFC8673: It is intending to use a
> HEAD request with a Range header with the goal of getting a 206 response
> with a Content-Range response header to determine current asset length.
> RFC7233 states that the Range request header MUST be ignored unless the
> request is a GET. If my interpretation is correct, this seems to indicate
> an incompatibility for what is being proposed in RFC8673 and what is
> currently specified in RFC7233.
>
>   The question I was hoping to gain clarification on is if RFC8673 is
> referenced in draft-pantos-hls-rfc8216bis-09 specifically for the
> last-byte-pos component or if there is an expectation of incorporating more
> concepts from RFC8673 as well.
>
> Thank you very much for your time.
>
> --
>
> [image: Image removed by sender. Limelight Networks]
> <https://urldefense.com/v3/__https:/www.limelight.com__;!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4ZhD5ETA$>
>
> *Andrew Ryan** Principal Architect*
> *EXPERIENCE FIRST.*
> [image: Image removed by sender.][image: Image removed by sender.]+1 716
> 250 9882 <+1+716+250+9882>
> www.limelight.com
> <https://urldefense.com/v3/__https:/www.limelight.com__;!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4ZhD5ETA$>
>
>
>
> [image: Image removed by sender. Facebook]
> <https://urldefense.com/v3/__https:/www.facebook.com/LimelightNetworks__;!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4YKDKJN0$>[image:
> Image removed by sender. LinkedIn]
> <https://urldefense.com/v3/__https:/www.linkedin.com/company/limelight-networks__;!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4W8yr_OX$>[image:
> Image removed by sender. Twitter]
> <https://urldefense.com/v3/__https:/twitter.com/llnw__;!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4dv7kLaF$>
>
>
>


-- 
[image: Limelight Networks] <https://www.limelight.com>
Andrew Ryan* Principal Architect*
EXPERIENCE FIRST.
+1 716 250 9882 <+1+716+250+9882>
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] Question about RFC8673 reference i… Andrew Ryan
Re: [Hls-interest] Question about RFC8673 referen… Law, Will
Re: [Hls-interest] Question about RFC8673 referen… Andrew Ryan