Re: Review of section 7

On Sun, 12 Apr 2009, Silvia Pfeiffer wrote:

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

Why? it is the case only if the cache can't handle merging timed fragment, 
which is the case of general purposes caches (they will handle only 
bytes), but media procies might be able to do so. Once again, it is not 
sure that they will do that as requesting the whole resource and serve 
fragments from the cache might be more efficient for such caches anyway :)

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

This is needed for both options, btw.

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

One thing that I wonder is what happen if the reply is with two Range: 
header, one in bytes, one in seconds.

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

Even in case of Accept: video/* ? (we will keep that for after the 
publication, as it is a technical issue)

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

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Sunday, 12 April 2009 17:42:26 UTC