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

Craig Pratt <craig@ecaspia.com> Fri, 30 March 2018 00:13 UTC

Resent-Date: Fri, 30 Mar 2018 00:03:53 +0000
Resent-Message-Id: <E1f1hWL-0003XC-Qu@frink.w3.org>
To: ietf-http-wg@w3.org
References: <152154837826.9793.17629316745234842173@ietfa.amsl.com> <20180320141231.GB11174@raspberrypi> <f3ff3d24-34be-abca-dbf5-add21ddcc72f@ecaspia.com> <20180321140917.GA14324@raspberrypi>
From: Craig Pratt <craig@ecaspia.com>
Organization: Caspia Consulting
Message-ID: <eb37bf77-f925-4bc9-1d26-60fa0126903d@ecaspia.com>
Date: Thu, 29 Mar 2018 20:03:04 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180321140917.GA14324@raspberrypi>
Content-Type: text/html; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: I-D Action: draft-ietf-httpbis-rand-access-live-03.txt
Archived-At: <https://www.w3.org/mid/eb37bf77-f925-4bc9-1d26-60fa0126903d@ecaspia.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

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:

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

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...


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
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.</pre>
    </blockquote>
    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.<br>
    <br>
    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.<br>
    <br>
    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) <br>
    <br>
    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. <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
responses should be sent. Should these things be called out?

Regards</pre>
    </blockquote>
    <br>
    I think this statement from RFC-7233 (section 4.4) describes the 416
    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>
    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?)<br>
    <br>
    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.<br>
    <br>
    Anyway, hope this helps. And please let me know if I'm missing
    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:internet-drafts@ietf.org">internet-drafts@ietf.org</a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">
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:
<a class="moz-txt-link-freetext" href=https://datatracker.ietf.org/doc/draft-ietf-httpbis-rand-access-live/" rel="nofollow">"https://datatracker.ietf.org/doc/draft-ietf-httpbis-rand-access-live/">https://datatracker.ietf.org/doc/draft-ietf-httpbis-rand-access-live/" rel="nofollow">https://datatracker.ietf.org/doc/draft-ietf-httpbis-rand-access-live/</a>

There are also htmlized versions available at:
<a class="moz-txt-link-freetext" href=https://tools.ietf.org/html/draft-ietf-httpbis-rand-access-live-03" rel="nofollow">"https://tools.ietf.org/html/draft-ietf-httpbis-rand-access-live-03">https://tools.ietf.org/html/draft-ietf-httpbis-rand-access-live-03" rel="nofollow">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" rel="nofollow">"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" rel="nofollow">https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rand-access-live-03</a>

A diff from the previous version is available at:
<a class="moz-txt-link-freetext" href=https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-rand-access-live-03" rel="nofollow">"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" rel="nofollow">https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-rand-access-live-03</a>


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:
<a class="moz-txt-link-freetext" href=ftp://ftp.ietf.org/internet-drafts/" rel="nofollow">"ftp://ftp.ietf.org/internet-drafts/">ftp://ftp.ietf.org/internet-drafts/" rel="nofollow">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:craig@ecaspia.com">craig@ecaspia.com</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>

craig pratt

caspia consulting

craig@ecaspia.com

503.706.2933

I-D Action: draft-ietf-httpbis-rand-access-live-0… internet-drafts
Re: I-D Action: draft-ietf-httpbis-rand-access-li… Thomas Peterson
Re: I-D Action: draft-ietf-httpbis-rand-access-li… Craig Pratt
Re: I-D Action: draft-ietf-httpbis-rand-access-li… Thomas Peterson
Re: I-D Action: draft-ietf-httpbis-rand-access-li… Craig Pratt