Subject: I-D Action: draft-ietf-httpbis-rand-access-live-03.txt

From: [email-masked]
Date: Tue, 20 Mar 2018 05:19:38 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Hypertext Transfer Protocol WG of the IETF.

        Title           : HTTP Random Access and Live Content
        Authors         : Craig Pratt
                          Darshak Thakore
                          Barbara Stark
	Filename        : draft-ietf-httpbis-rand-access-live-03.txt
	Pages           : 11
	Date            : 2018-03-20

Abstract:
   To accommodate byte range requests for content that has data appended
   over time, this document defines semantics that allow a HTTP client
   and server to perform byte-range GET and HEAD requests that start at
   an arbitrary byte offset within the representation and ends at an
   indeterminate offset.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-rand-access-live/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-httpbis-rand-access-live-03
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rand-access-live-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-rand-access-live-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Thomas Peterson <[email-masked]>
Date: Tue, 20 Mar 2018 14:12:31 +0000

A question I have with this draft is the behaviour or expectations that may or
may not occur during failure modes, particularly when a "reset" or roll-over
happens on the server side. Consider the scenario when the server byte-offset is
effective reset, and thus it's "range" has shifted beyond the client's
expectations.

I don't see any reference in this draft that explicitly call out when 416
responses should be sent. Should these things be called out?

Regards

---

From: Craig Pratt <[email-masked]>
Date: Wed, 21 Mar 2018 00:37:29 -0700

Thanks Thomas for the
suggestion/questions.

My thoughts in-line...

cp

On 3/20/18 7:12 AM, Thomas Peterson wrote:

When a server encounters an error acquiring the live content it's
incorporating into the representation (e.g. a discontinuity) there
are a couple options that come to mind: (1) stop appending the
content into the representation (and optionally start a new one), or
(2) append the content in a content-type-specific way that the
client can digest/comprehend.

Either way, the client wouldn't receive a non-success HTTP status
code when transferring content on each side of the discontinuity. In
the case of (1), the content would just no longer grow (effectively
becoming a static representation). For (2) the only effect would be
a momentary decrease in the transmitted bitrate during the period of
discontinuity. (you could see this effect periodically in the
results I presented at IETF 100) To the client, it looks like one
contiguous sequence of data.

So at this point, you might be thinking "this explanation on
discontinuities is what should be in the draft RFC". I don think it
would be great if there was more guidance on live content. The issue
there is that (a) dealing with discontinuities is fairly
format-specific, (b) the guidance applies to non-random access cases
equally, and (c) I'm not sure it has to do with with the "transfer"
aspect of HTTP - since my argument above is that the server-side
failure modes really affect the *constitution/construction* of the
representation and not the *transfer* of it. (as I still consider
myself a newb in the httpbis group, maybe someone can clarify my
understanding)

If only (a) and (b) apply, there might be a case to be made for a
format-agnostic "Live Content and Errors/Discontinuities" draft RFC.
But my thinking has been that it's a bit too far out of scope for
this draft.

Regards

I think this statement from RFC-7233 (section 4.4) describes the 416
cases pretty well:

The 416 (Range Not Satisfiable) status code
indicates that none of

the ranges in the request’s Range header field (Section 3.1)
overlap

the current extent of the selected resource

Unfortunately, section 4.4 trips over itself a bit when it tries to
talk about byte-range-specific simplifications. But I don't think
it's appropriate to clarify this in our draft. (Perhaps this can be
cleaned up as part of HTTPter?)

And while it might be useful to provide examples in the draft, I've
tried to provide examples of ways to interact with a
live/aggregating server that should *avoid* 416 errors (and get 206
instead). But the cool thing about the way that 7233 is written is
that a client can really respond to a 206 and 416 similarly - since
they both include a Content-Range response header.

Anyway, hope this helps. And please let me know if I'm missing
something (like the point of your question)...

Abstract:

--

craig pratt

caspia consulting

[email-masked]

503.706.2933

---

From: Thomas Peterson <[email-masked]>
Date: Wed, 21 Mar 2018 14:09:36 +0000

Thank you for your response.

My failure considerations are not around a server failing to acquire live
content, but the scenario when the server itself fails, resulting in the
connection to the client to close and the client may reconnect. In this scenario
(which can be complicated further by having n servers fronted by a load
balancer, which each server reporting different byte ranges for the same asset)
it's not clear to me from the document what a client may do, however as you put
it this may be too format specific to introduce into the specification. Perhaps
there is benefit to including something like:

    "A client that may have been disconnected and wishing to continue to receive
    only newly-aggregated portions SHOULD perform a HEAD request to learn of any
    potential changes in the range available before making a subsequent GET".

I hope that clears the point I'm trying to make.

Regards

On Wed, Mar 21, 2018 at 12:37:29AM -0700, Craig Pratt wrote:
> <html>
>   <head>
>     <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
>   </head>
>   <body text="#000000" bgcolor="#FFFFFF">
>     <div class="moz-cite-prefix">Thanks Thomas for the
>       suggestion/questions. <br>
>       <br>
>       My thoughts in-line...<br>
>       <br>
>       cp<br>
>       <br>
>       On 3/20/18 7:12 AM, Thomas Peterson wrote:<br>
>     </div>
>     <blockquote type="cite"
>       cite="mid:20180320141231.GB11174@raspberrypi">
>       <pre wrap="">A question I have with this draft is the behaviour or expectations that may or
> expectations.</pre>
>     </blockquote>
>     client can digest/comprehend.<br>
>     <br>
>     contiguous sequence of data.<br>
>     <br>
>     understanding) <br>
>     <br>
>     this draft. <br>
>     <br>
>     <blockquote type="cite"
>       cite="mid:20180320141231.GB11174@raspberrypi">
>       <pre wrap="">I don't see any reference in this draft that explicitly call out when 416
> Regards</pre>
>     </blockquote>
>     <br>
>     cases pretty well: <br>
>     <blockquote><tt>The 416 (Range Not Satisfiable) status code
>         indicates that none of</tt><br>
>       <tt>the ranges in the request’s Range header field (Section 3.1)
>         overlap</tt><br>
>       <tt>the current extent of the selected resource</tt><br>
>     </blockquote>
>     cleaned up as part of HTTPter?)<br>
>     <br>
>     they both include a Content-Range response header.<br>
>     <br>
>     something (like the point of your question)...<br>
>     <blockquote type="cite"
>       cite="mid:20180320141231.GB11174@raspberrypi">
>       <pre wrap="">
> 
> On Tue, Mar 20, 2018 at 05:19:38AM -0700, <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> wrote:
> </pre>
>       <blockquote type="cite">
>         <pre wrap="">
> <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-ietf-httpbis-rand-access-live/">https://datatracker.ietf.org/doc/draft-ietf-httpbis-rand-access-live/</a>
> 
> <a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/draft-ietf-httpbis-rand-access-live-03">https://tools.ietf.org/html/draft-ietf-httpbis-rand-access-live-03</a>
> <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rand-access-live-03">https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rand-access-live-03</a>
> 
> <a class="moz-txt-link-freetext" href="https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-rand-access-live-03">https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-rand-access-live-03</a>
> 
> 
> <a class="moz-txt-link-freetext" href="ftp://ftp.ietf.org/internet-drafts/">ftp://ftp.ietf.org/internet-drafts/</a>
> 
> 
> </pre>
>       </blockquote>
>       <pre wrap="">
> </pre>
>     </blockquote>
>     <p><br>
>     </p>
>     <div class="moz-signature">-- <br>
>       <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
>       <meta http-equiv="Content-Style-Type" content="text/css">
>       <title></title>
>       <meta name="Generator" content="Cocoa HTML Writer">
>       <meta name="CocoaVersion" content="1038.36">
>       <style type="text/css">
>     p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px 'Lucida Console'}
>     p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px}
>     table.t1 {border-collapse: collapse}
>     td.td1 {background-color: #bffdba; border-style: solid; border-width: 1.0px 1.0px 1.0px 1.0px; border-color: #000000 #000000 #000000 #000000; padding: 0.0px 5.0px 0.0px 5.0px}
>     td.td2 {background-color: #9fd39b; border-style: solid; border-width: 1.0px 1.0px 1.0px 1.0px; border-color: #000000 #000000 #000000 #000000; padding: 0.0px 5.0px 0.0px 5.0px}
>     td.td3 {background-color: #78a075; border-style: solid; border-width: 1.0px 1.0px 1.0px 1.0px; border-color: #000000 #000000 #000000 #000000; padding: 0.0px 5.0px 0.0px 5.0px}
>   </style>
>       <table class="t1" cellspacing="0" cellpadding="0">
>         <tbody>
>           <tr>
>             <td class="td1" valign="middle">
>               <p class="p1">craig pratt</p>
>               <p class="p1">caspia consulting</p>
>               <p class="p1"><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></p>
>               <p class="p1">503.706.2933</p>
>             </td>
>             <td class="td2" valign="middle">
>               <p class="p2"><br>
>               </p>
>             </td>
>             <td class="td3" valign="middle">
>               <p class="p2"><br>
>               </p>
>             </td>
>           </tr>
>         </tbody>
>       </table>
>       <p class="p2"><br>
>       </p>
>     </div>
>   </body>
> </html>
>

---

From: Craig Pratt <[email-masked]>
Date: Thu, 29 Mar 2018 20:03:04 -0400

Thanks for the clarification Thomas -
and apologies for the latency. We're in spring break here.

Reply in-line.

cp

On 3/21/18 7:09 AM, Thomas Peterson wrote:

Regards

Ah - ok. Well, sorry for the long explanation about server-side
issues. That's an involved topic - and as interesting as it is, it's
a tar pit of application- and implementation-specific issues.

To your question: I definitely intended section 2.1 ("Establishing
the Randomly Accessible Byte Range") - which discusses using HEAD to
establish the currently accessible range - to cover both initial
connection and reconnection cases. But I've tried to avoid
mentioning any specific semantics because there are so many ways
that clients can use Range - esp when one can get a Content-Range
(which communicates the available range) response header with a GET
or HEAD.

e.g. If a client wants to buffer content using fixed "walking" Range
requests, they can update their current picture of the available
range from the Content-Range headers included in the Range
responses. Other clients may wish to use periodic HEADS.

In either of these two models, the client may make some temporal
assumptions/optimizations about the state of the accessible range.
So a short disconnect need not necessarily require a client to
perform a HEAD - since they may just continue with another
byte-range GET and update their internal picture with the
Content-Range response.

In short: I think the "should" you suggest should be a "may". And
there are a lot different "may" scenarios that I'd rather not get
into. (esp since I don't even know if I can authoritatively
enumerate them all)

Hope I'm making some sense here...

<html>
<head>

Regards</pre>
</blockquote>
<br>

Abstract:

</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<p><br>
</p>

--

craig pratt

caspia consulting

[email-masked]

503.706.2933