Thanks for the review and quick response. Comments inline.
Regards, Sreekanth -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Richard Alimi Sent: Wednesday, February 22, 2012 12:14 PM To: sreekanth madhavan Cc: [email protected] Subject: Re: [alto] FW: New Version Notification for draft-alto-caching-subscription-00.txt Thank you for submitting the draft. Reading through very quickly, there are a couple of comments: (1) Note that HTTP already allows expiration date/time to be conveyed for the entire document. I don't see a reason for adding another way to convey that. (Yes, the new thing discussed in your draft is caching a subset of the content.) (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. 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
