Sreekanth, thanks for your comments! > I have reviewed the draft. Following are my comments: > > Section 3.1. HTTP > > HTTP [RFC2616] provides request-header fields to express conditional > requests. Typically these conditional requests are used by caches > to > decide whether a copy of a resource they have can be served to a > requesting client directly or not. Responses to conditional HTTP > requests must be exactly the same as for normal HTTP GET requests. > Thus sending a modified map version (i.e. a partial update) violates > the HTTP standard. Conditional requests can still be used to avoid > transmitting an unchanged Map multiple times. The options are > discussed in the following. > > [sreekanth]: RFC 3229 defines how delta encoding can be supported as an > compatible extension to HTTP/1.1. Can't we use the same framework for > alto incremental updates ? > Thanks for the pointer. This is certainly something we need to consider. After a quick search I don't have the impression that HTTP delta encoding is currently widely used. Do you or anyone else have an idea to what extend this is actually supported in today's implementations?
> > Section 3.1.1: If-Modified-Since HTTP Header > > [sreekanth]: This timestamp-based approach is prone to error because of > the > lack > of timestamp resolution: if a resource changes twice during one > second, > the change might not be detectable. It is better to use the ETag. One main assumption for the ALTO map-based approach is that the information provided in these maps is static for a longer period of time, thus changes on sub-second timeframe seem unlikely. I see your point though. Regards, Nico > > > IMO notification based cache invalidation mechanism can be added as an > alternate approach. > > Regards, > Sreekanth > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Schwan, Nico (Nico) > Sent: Monday, July 16, 2012 6:37 PM > To: [email protected] > Cc: Roome, W D > Subject: [alto] New version: draft-schwan-alto-incr-updates-02.txt > > All, > > we have submitted an updated version of the "ALTO Incremental Updates" > draft > which analyses options for partial updates of ALTO Network and Cost > Maps. In > this version we have further detailed the solution which is based on > Filtered Map Services. As suggested in the last meeting we have also > included a short numerical evaluation of the most promising options in > the > draft. Our main findings are that for more than 100 PIDs partial > updates are > useful, and that the solution based on Filtered Maps is more efficient > than > JSON Patch in terms of needed bytes for encoding. > > Any comments on the discussed options, the numbers, or anything else > are > welcome! > > Thanks, > > Nico > > > -------------- > > A new version of I-D, draft-schwan-alto-incr-updates-02.txt > has been successfully submitted by Nico Schwan and posted to the IETF > repository. > > Filename: draft-schwan-alto-incr-updates > Revision: 02 > Title: ALTO Incremental Updates > Creation date: 2012-07-16 > WG ID: Individual Submission > Number of pages: 26 > URL: > http://www.ietf.org/internet-drafts/draft-schwan-alto-incr-updates- > 02.txt > Status: > http://datatracker.ietf.org/doc/draft-schwan-alto-incr-updates > Htmlized: > http://tools.ietf.org/html/draft-schwan-alto-incr-updates-02 > Diff: > http://tools.ietf.org/rfcdiff?url2=draft-schwan-alto-incr-updates-02 > > Abstract: > The goal of Application-Layer Traffic Optimization (ALTO) is to > bridge the gap between network and applications by provisioning > network related information. This allows applications to make > informed decisions, for example when selecting a target host from a > set of candidates. > > Therefore an ALTO server provides network and cost maps to its > clients. This draft discusses options on how to provide incremental > updates for these maps, with the goal of reducing the amount of data > needed for transmitting the maps and shortly evaluates the two most > promising options. > > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
