Hi All, Thanks for all your comments. The good thing I see is that everyone agrees to the point that caching of ALTO information is beneficial(at least from the replies). For caching of this information, we have two options, use HTTP based mechanisms or define a new mechanism in ALTO. We(authors) seem to have a different opinion regarding the mechanism for caching. The rationale (as I understand) for using HTTP based caching mechanism is to reuse the existing HTTP caching infrastructure. AFAIK, many of the commonly used HTTP caches support only caching of GET/HEAD requests. The POST request will be used in ALTO for filtered map queries and going forward I believe this will probably be more popular among the clients for the simple reason being that the client is not interested in getting the whole map information every time. In this case, the existing cache infrastructure is not very useful. The POST caching mechanism of redirecting every request from the client to another URL, IMHO, is cumbersome and does not reu se the existing caching infrastructure. The server has to generate a unique URL for every new ALTO filtered request and redirect it to this URL. The filtered map queries could be varied and this ends up into multiple redirected URLs for each kind of filter. IMO, the goal is to cache the ALTO information, HTTP caching mechanism is the means. If the means is cumbersome, then it is better to devise the extension in the protocol itself.
-Ravi ________________________________________ From: [email protected] [[email protected]] on behalf of Richard Alimi [[email protected]] Sent: Wednesday, February 22, 2012 9:13 PM To: Ben Niven-Jenkins Cc: Sreekanth madhavan; [email protected] Subject: Re: [alto] FW: New Version Notification for draft-alto-caching-subscription-00.txt 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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
