Review of section 7

Hi all,

Here is my input to section 7.

Section 7

* Second paragraph: remove "n" in "an" of "an Web application"

Section 7.1

* proposal to rename to "1-step GET request"
* it might make sense to put an "aim" into the alternatives; this
section would have an aim of "allowing a single roundtrip media
fragment resource delivery"
* we need to mention that the replies are not cachable for the full
resource, but cache only the fragmented resource, which can result in
n copies of some subset of the resource in caching web proxies. Since
it is typically expected that a fragment request will be used
repeatedly (e.g. a fragment URI being shared around), this is
potentially acceptable. But we have no experimental data to confirm or
deny that this may pose a challenge to caching web proxies.
* further we need to mention that there are encapsulation formats
(such as MP4) that have an index in their headers that can provide a
seconds->byte mapping for any offset. For such cases, an optimisation
is possible where a client retrieves the index part of the media file
first and then uses that to make byte range requests rather than time
range requests. These requests are cachable by any caching Web proxy
without replication for differing fragment requests. This is in fact a
third means of retrieving fragment URIs, which we might want to make
explicit as a section 7.3.
* further I think we should remove the current section 7.3 and put at
the end of section 7.1 and section 7.2 the advantages and
disadvantages of that particular approach. I think that makes it a
fairer assessment of the alternatives.

Section 7.2

Even though this section is taking a different approach to temporal
URIs, it still follows the basic principles of temporal URIs (as
described in http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html#anchor6).
I therefore have some change requests to this section, since it is not
quite consistent as it is.

* proposal to rename to "2-step GET request"
* it might make sense to put an "aim" into the alternatives; this
section would have an aim of "allowing reuse of existing byte range
based URI fragment caching methodology for media fragments in caching
web proxies"
* (minor issue:) paragraph 3 (starting with "Origin Server
converts..." needs an "s" at the end of "puts" in "and put all header
data...".
* third example box says: "should it be a '204 No Content' response?"
- no that response would be wrong because there is typically actual
content in this response, which consists of the adapted headers (the
control section) of the encapsulation format.

* The section from Origin-Server -> Proxy(4) -> UA (5) probably does
not work in the way that it is outlined here.
  - If the Origin-Server returns a "200 OK" and no other header that
indicates that the client has to do another request, the client has to
assume that the retrieval action is finished. So, we need to add some
further request and response headers
  - In temporal URI, we firstly created an additional request header
called "X-Accept-Range-Redirect" which indicates to the server that it
is to do a range resolution and a redirect.

    Example:

     GET http://example.com/fragf2f.mp4 HTTP/1.1
     Accept: video/*
     Range: seconds=12-21
     X-Accept-Range-Redirect: bytes

    Mapping this to our approach here, the server needs to respond
with the following:
    1. map the given range type from seconds (or whatever else is given) to byes
    2. reply with a X-Accept-TimeURI header that indicates to the
client that is has processed the time request and converted to bytes
(similarly this could be extended to X-Accept-SpaceURI,
X-Accept-TrackURI, and X-Accept-NameURI). Incidentally, this part
should probably also be added to section 7.1 so we can generally
indicate that it's a fragment that is being returned and not the full
resource.
    3. create the control section of the partial resource, which is
specific to this fragment URI and not cacheable.
    4. return this control section in the content of the reply.
    5. reply with a X-Range-Redirect header that includes the byte
ranges to which the content retrieval action should be redirected
    6. reply with a Vary: X-Accept-Range-Redirect header to indicate
that this reply is not cachable
    7. reply with the original URI in the Location header, so that the
client can use this for the second request
    8. Unfortunately, the server cannot reply with a redirect header
of 3xx because those cannot contain actual data; instead, the client
has to tell by the existance of the X-Range-Redirect header that it
has to do a second retrieval action to get the full resource.

    Example:
    HTTP/1.1 200 OK
    Date: Fri Feb 11 14:47:12 EST 2005
    Server: Apache/2.0(Unix)
    Content-Type: video/mp4
    Location: http://example.com/fragf2f.mp4
    X-Range-Redirect: bytes=1113724-2082711
    Vary: X-Accept-Range-Redirect
    X-Accept-TimeURI: npt, smpte-25
    Message body: control section of fragf2f.mp4#12,21 (if required)

* the rest of the transaction works the way in which it is outlined;
however, the image has a problem since the response code of the second
response is "200 OK" in the image, but "206 Partial Content" in the
example, which is correct.


Section 7.3

* as mentioned above, I would like to suggest to move all the details
of section 7.3 into section 7.1 and 7.2 and have
advantages/disadvantages for each approach separately.
* can somebody clarify why "2-way handshake allows to extract a
spatial region from a Motion JPEG2000" while 4-way does not? I don't
understand the reasoning behind this.
* can somebody clairfy why "2-way handshake achieves what we want
without needing HTTP protocol extension"? I think that both, 2-way and
4-way require a protocol extension - at minimum they require the
creation of new range types. Also, I would suggest creating
Accept-TimeURI, Accept-SpaceURI, Accept-TrackURI and Accept-NameURI
headers such that the server can indicate to the client whether it is
indeed capable of returning fragments and which type. (we could
certainly turn this into a singe "Accept-FragmentURI:
time,space,track,name" header, but then we cannot communicate which
types of headers are supported).

Section 7.3, third paragraph (starting "Using HTTP byte ranges...")

I do not understand this paragraph and I think it is fundamentally
wrong. I think there is a misunderstanding for the 4-way handshake
between how to handle the control section that is non-cachable and
transferred in the first GET action, and how to handle the data
section which is transferred in the second GET action. All the data
that is transferred in the second GET action is simply a byte range
request on the original resource, which means it can be stored in the
exact same way in which existing caching Web proxies store byte range
requests, so there is no extra implementation cost. The control
section is generally small and is returned with the first GET action.
Indeed, there are not an infinite number of resources created in this
way, but exactly only one in the proxies. This is a big advantage of
the 4-way handshake and not a disadvantage.

Of course the whole idea of caching and reducing bandwidth use falls
down when we need to transcode media resources. Those are never
cachable other than for the exact same fragment URI. For those, the
2-way handshake is probably more appropriate.


OK, I hope I was able to explain myself well enough. I know I have
made some change requests that may be quite substantial - this will
make for good input to the F2F, I guess. :-) Not sure it can be
attacked before the planned WD release on Tuesday...

Happy Easter!

Cheers,
Silvia.

Received on Sunday, 12 April 2009 10:53:33 UTC