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

From: "Schwan, Nico (Nico)" <[email-masked]>
Date: Mon, 16 Jul 2012 15:06:46 +0200

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.

---

From: sreekanth madhavan <[email-masked]>
Date: Fri, 27 Jul 2012 10:27:54 +0530

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-masked] [mailto:[email-masked]] On Behalf Of
Schwan, Nico (Nico)
Sent: Monday, July 16, 2012 6:37 PM
To: [email-masked]
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:

_______________________________________________
alto mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/alto

---

From: "Schwan, Nico (Nico)" <[email-masked]>
Date: Fri, 27 Jul 2012 13:59:17 +0200

Sreekanth,

thanks for your comments!
 
> 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?

>    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