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

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