Subject: Re: [alto] FW: New Version Notification for draft-alto-caching-subscription-00.txt

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 4 Mar 2012 17:01:27 +0000

On 22 Feb 2012, at 16:09, Martin Thomson wrote:

> On 22 February 2012 07:43, Richard Alimi <[email-masked]> wrote:
>> Why not?  Do you see cases where HTTP's notion of caching is different
>> than what we want in ALTO?  (Aside from the caching a part of a
>> response, which Ben has already commented on above..)
> 
> If you need to identify subsets of information, then it is quite
> possible that you have too few resources in the design*.  A subset
> that is capable of changing could conceivably be identified as an
> independent resource with independent expiration and caching. If you
> want to retain the economy of a single, aggregated resource, you can
> still identify portions within that resource independently.  It's
> possible that you would require extensions to the data format to do so
> and there would be tradeoffs in complexity and (maybe) chattiness.
> But you could then build on HTTP caching.

I could see how that could work, PIDs in the network map could be individual resources and the cost between a PID and other PIDs in the cost map could also be individual resources.

A network or cost map could contain links to those resources or if an aggregated map is required the individual resources could be "inlined" to enable the whole map to be returned in a single response like it can today (see section 6.4.1 of draft-jenkins-cdni-metadata-00 for a description of one way we could do it and some hints about an alternative way with slightly different pros/cons).

An ALTO server could then have a "change feed" resource that is akin to an Atom Feed that contains links to individual ALTO resources that have changed over time from some (specified) base map-vtag which clients could retrieve directly instead of retrieving the entire map each time.

That would appear to work where it is felt acceptable to re-obtain the entire PID when any change is made to its contents (or to the cost between it and other PIDs).

Clients could poll the change feed resource using HTTP's If-*-Match semantics to efficiently ensure they don't have to retrieve & process the change feed unless the network/cost maps have actually changed.

Ben

> 
> 
> One set of tradeoffs has already been made and that produced the
> current design.  That doesn't prevent a well-justified and designed
> extension from functioning.  There may be a case for optimization.
> But there are probably better ways than inventing a protocol-specific
> subscription extension.
> 
> --Martin
> 
> p.s. Have you looked at RFC 5989?

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 4 Mar 2012 17:20:33 +0000

On 23 Feb 2012, at 05:48, sreekanth madhavan wrote:

> A notification mechanism doesn't help you with that problem though. What you
> need is a mechanism to provide incremental updates (i.e. only send the
> things that have changed), just being notified there is a change doesn't
> help with caching.
> 
> [SK]
> The notification message sends the changed map information for which the
> clients have already subscribed. We have mentioned this point in the
> draft(Introduction section). The mechanism was not clearly explained. We can
> add this to the draft.

I think there are two distinct things here that we should be careful not to join together unnecessarily.

The first is whether there is a need for a mechanism to provide incremental updates for efficiency. I have use cases for such a mechanism so would support its development.

The second is whether there is a need for the ALTO server to push a notification that ALTO map data has changed to ALTO clients or whether polling for updates by clients (using HTTP Etags etc for efficiency) is sufficient. I think this will rest more on the requirements of clients, for example how fast after an change has occurred must the client require the new ALTO map data, along with how many clients are likely to be accessing a single ALTO server as the number of ALTO clients could significantly differ between a P2P and CDN use case, for example. I am not convinced that a pub/sub or push mechanism for notifications is always required and for several use cases reuse of HTTP polling of, for example, a "change feed" could result in clients efficiently learning of changed ALTO data in a reasonable timeframe. 

Ben

> 
> Regards,
> Sreekanth
> 
> -----Original Message-----
> From: Ben Niven-Jenkins [mailto:[email-masked]] 
> Sent: Wednesday, February 22, 2012 8:38 PM
> To: sreekanth madhavan
> Cc: 'Richard Alimi'; [email-masked]
> Subject: Re: [alto] FW: New Version Notification for
> draft-alto-caching-subscription-00.txt
> 
> 
> On 22 Feb 2012, at 14:47, sreekanth madhavan wrote:
>> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
>> Richard Alimi
>> (2) There are ways to do caching in HTTP for POST requests (e.g.,
>> server can reply with an alternate location and the client does a GET
>> on that location).
>> 
>> 
>> [SK]
>> HTTP based caching mechanisms cannot be used for subset of the content. In
>> most cases ISPs change part of the network map information related to some
>> of the PIDs.
>> In the above case, ALTO clients ideally will be interested only in the
>> changed information and it does not make sense to resend the whole
>> information to the clients.
> 
> A notification mechanism doesn't help you with that problem though. What you
> need is a mechanism to provide incremental updates (i.e. only send the
> things that have changed), just being notified there is a change doesn't
> help with caching.
> 
> Ben
> 
>> 
>> AFAIK, In the ALTO context, HTTP is similar to a transport mechanism. The
>> validity of the map information is related to the ALTO layer and
> delegating
>> this to the HTTP layer is probably not a good idea.
>> 
>> Regarding the redirect mechanism for POST which you have suggested, it
>> involves additional messaging which can be avoided by the mechanism
> proposed
>> in the draft.
>> 
>> (3) Reading through quickly, anyways, the notification scheme seems
>> conceptually similar to that discussed in
>> http://tools.ietf.org/html/draft-sun-alto-notification-02.  There was
>> extensive discussion on the list for that document, so it may be worth
>> reading through that (if you haven't already, of course).
>> 
>> [SK]
>> Thanks for providing reference to sun-alto-notification draft. In our
>> proposal the notification message carries the map information (only the
>> changed) unlike the referred draft where the client needs to query again. 
>> 
>> Notification framework helps in fast propagation of information changes.
> In
>> the recent developments in the working group, alto-next also proposes
> server
>> notification mechanism.
>> 
>> Thanks again for submitting the draft,
>> Rich
>> 
>> On Tue, Feb 21, 2012 at 9:23 PM, sreekanth madhavan
>> <[email-masked]> wrote:
>>> Hi All,
>>> 
>>> We have submitted a new draft related to Alto caching and subscription.
> We
>> felt that the existing HTTP based caching mechanisms are not suitable for
>> caching Alto map information.
>>> 
>>> We also proposed a new mechanism for subscription and notification which
>> we think will help reduce redundant traffic between alto nodes.
>>> 
>>> Your comments are highly welcome.
>>> 
>>> http://www.ietf.org/id/draft-alto-caching-subscription-00.txt
>>> 
>>> 
>>> Regards,
>>> Sreekanth Madhavan, on behalf of all authors
>>> 
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]]
>>> Sent: Wednesday, February 22, 2012 10:29 AM
>>> To: [email-masked]
>>> Cc: [email-masked]; [email-masked]
>>> Subject: New Version Notification for
>> draft-alto-caching-subscription-00.txt
>>> 
>>> A new version of I-D, draft-alto-caching-subscription-00.txt has been
>> successfully submitted by Sreekanth Madhavan and posted to the IETF
>> repository.
>>> 
>>> Filename:        draft-alto-caching-subscription
>>> Revision:        00
>>> Title:           ALTO Caching and Subscription
>>> Creation date:   2012-02-22
>>> WG ID:           Individual Submission
>>> Number of pages: 19
>>> 
>>> Abstract:
>>>  The specification of the ALTO protocol uses map based approaches
>>>  assuming that the information provided is static for a longer period
>>>  of time.  But in some cases network operators reallocate IP subnets
>>>  from time to time which in turn changes the mapping partitions[I-
>>>  D.ietf-alto-deployments].  Since the ALTO clients are unaware of the
>>>  map information changes, clients need to query the servers for every
>>>  service request and many such requests are redundant because the
>>>  information was not changed.  The purpose of this memo is to provide
>>>  two mechanisms which will help the ALTO clients to be informed of the
>>>  map information changes. a) ALTO clients cache the map information
>>>  and the servers provide the expiration time for invalidation. b) ALTO
>>>  clients can subscribe for event notifications from the server
>>> 
>>> 
>>> 
>>> 
>>> The IETF Secretariat
>>> 
>>> _______________________________________________
>>> alto mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/alto
>> 
>> _______________________________________________
>> alto mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Ravi nandiraju <[email-masked]>
Date: Wed, 07 Mar 2012 05:56:10 +0000

Hi,
    Please find my response inline.

-Ravi

________________________________________
From: [email-masked] [[email-masked]] on behalf of Ben Niven-Jenkins [[email-masked]]
Sent: Sunday, March 04, 2012 10:31 PM
To: Martin Thomson
Cc: Sreekanth madhavan; [email-masked]
Subject: Re: [alto] FW: New Version Notification for    draft-alto-caching-subscription-00.txt

Ben

[Ravi]   The method which is described above is parallel to the one which is already defined by the base ALTO spec. I don't see the rationale for going for this method when there is already a filtered map based method defined by the base ALTO spec. I am not sure if you are suggesting that we do away with the POST based mechanism completely from ALTO.
   The reason why we came up with the ALTO based caching is because of the POST method that will be used in getting information specific information related to certain PIDs and this is not cached by the HTTP caches. Going forward we believe that more and more clients(P2P end points/trackers) will use this method. In this case the ALTO based caching will be required.

---

From: sreekanth madhavan <[email-masked]>
Date: Thu, 08 Mar 2012 12:57:42 +0530

Hi,

Comments inline.

Regards,
Sreekanth

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Sunday, March 04, 2012 10:51 PM
To: sreekanth madhavan
Cc: 'Richard Alimi'; [email-masked]
Subject: Re: [alto] FW: New Version Notification for

> draft(Introduction section). The mechanism was not clearly explained. We
can

I think there are two distinct things here that we should be careful not to
join together unnecessarily.

The first is whether there is a need for a mechanism to provide incremental
updates for efficiency. I have use cases for such a mechanism so would
support its development.

The second is whether there is a need for the ALTO server to push a
notification that ALTO map data has changed to ALTO clients or whether
polling for updates by clients (using HTTP Etags etc for efficiency) is
sufficient. I think this will rest more on the requirements of clients, for
example how fast after an change has occurred must the client require the
new ALTO map data, along with how many clients are likely to be accessing a
single ALTO server as the number of ALTO clients could significantly differ
between a P2P and CDN use case, for example. I am not convinced that a
pub/sub or push mechanism for notifications is always required and for
several use cases reuse of HTTP polling of, for example, a "change feed"
could result in clients efficiently learning of changed ALTO data in a
reasonable timeframe. 

Ben

[SK]: There are two different ways of cache invalidation - Weak consistency
approach (TTL based) and Strong consistency (Notification based , frequent
polling based). Unlike strong consistency approaches, weak consistency may
return stale document to the client. Studies have proven that strong cache
consistency can be maintained on the web with little or no extra cost than
the weak consistency approach and invalidation is the best approach ([Cao &
Liu 1997] Pei Cao, Chengjie Liu (1998). Maintaining Strong Cache Consistency
in the World Wide Web. IEEE Transactions on Computers, 47(4), 445-457.)

Regarding the impact, in the case of cdni as pointed out by Jan
(draft-seedorf-i2aex-alto-cdni-perpective-00), there can be service failures
as requests are redirected to wrong/invalid dCDN. IMO the situation becomes
worse when ALTOext introduces more application specific data (like
type/class of content at endpoints or what type of content adaptation
technique used by edge servers in case of CDN)which if incorrect will result
in wrong node selection affecting QoE.

In the case of P2P, the stale data can result in the unoptimized peer
selection and resulting in selecting the longest PATH which will defeat the
purpose of ALTO.