Hi,
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 ?
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.
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
