Hi, Comments inline.
Regards, Sreekanth -----Original Message----- From: Ben Niven-Jenkins [mailto:[email protected]] Sent: Sunday, March 04, 2012 10:51 PM To: sreekanth madhavan Cc: 'Richard Alimi'; [email protected] Subject: Re: [alto] FW: New Version Notification for draft-alto-caching-subscription-00.txt 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 [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. > > Regards, > Sreekanth > > -----Original Message----- > From: Ben Niven-Jenkins [mailto:[email protected]] > Sent: Wednesday, February 22, 2012 8:38 PM > To: sreekanth madhavan > Cc: 'Richard Alimi'; [email protected] > 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 protected] [mailto:[email protected]] 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 protected]> 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 protected] [mailto:[email protected]] >>> Sent: Wednesday, February 22, 2012 10:29 AM >>> To: [email protected] >>> Cc: [email protected]; [email protected] >>> 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 protected] >>> https://www.ietf.org/mailman/listinfo/alto >> >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
