Weird - I didn't get Sreekanth's original reply, so replying to Ben's instead :)
On Wed, Feb 22, 2012 at 7:08 AM, Ben Niven-Jenkins <[email protected]> wrote: > > 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. 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..) >> 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. Yes - that is one aspect of the problem, but note that there isn't a captive user waiting for the page to load and at least in the common case the data will not be changing at the sub-second level. Do you think the extra round-trip is going to matter for this data? I'm not sure I see the rationale for reinventing HTTP's caching. >> (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
