On 2/22/12 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.
Which was planned, written but finally removed from base ALTO protocol. But
irrespective, incremental updates is something I've always seen as a
important piece of the puzzle. But this is something Server and clients can
probably do it almost without changes to base spec as long as the diff rules
are well understood.
>
> 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
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
