Re: [alto] New version: draft-schwan-alto-incr-updates-02.txt

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: alto-bounces@ietf.org [mailto:alto-bounces@ietf.org] On Behalf Of
> Schwan, Nico (Nico)
> Sent: Monday, July 16, 2012 6:37 PM
> To: alto@ietf.org
> 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
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto