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
