Subject: [alto] FW: New Version Notification for draft-alto-caching-subscription-00.txt

From: sreekanth madhavan <[email-masked]>
Date: Wed, 22 Feb 2012 10:53:49 +0530

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-masked] [mailto:[email-masked]] 
Sent: Wednesday, February 22, 2012 10:29 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
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

---

From: Richard Alimi <[email-masked]>
Date: Tue, 21 Feb 2012 22:44:21 -0800

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).
(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).

Thanks again for submitting the draft,
Rich

On Tue, Feb 21, 2012 at 9:23 PM, sreekanth madhavan
<[email-masked]> wrote:
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: sreekanth madhavan <[email-masked]>
Date: Wed, 22 Feb 2012 20:17:41 +0530

Thanks for the review and quick response.

Comments inline.

Regards,
Sreekanth

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Alimi
Sent: Wednesday, February 22, 2012 12:14 PM
To: sreekanth madhavan
Cc: [email-masked]
Subject: Re: [alto] FW: New Version Notification for
draft-alto-caching-subscription-00.txt

[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.

[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.

On Tue, Feb 21, 2012 at 9:23 PM, sreekanth madhavan
<[email-masked]> 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.
> 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.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 22 Feb 2012 15:08:24 +0000

> 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

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 22 Feb 2012 10:33:08 -0500

On 2/22/12 7:08 AM, "Ben Niven-Jenkins" <[email-masked]> wrote:

> 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.

---

From: Richard Alimi <[email-masked]>
Date: Wed, 22 Feb 2012 07:43:08 -0800

Weird - I didn't get Sreekanth's original reply, so replying to Ben's instead :)

>> 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..)

>> involves additional messaging which can be avoided by the mechanism proposed

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.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Feb 2012 08:09:51 -0800

> response, which Ben has already commented on above..)

If you need to identify subsets of information, then it is quite
possible that you have too few resources in the design*.  A subset
that is capable of changing could conceivably be identified as an
independent resource with independent expiration and caching.  If you
want to retain the economy of a single, aggregated resource, you can
still identify portions within that resource independently.  It's
possible that you would require extensions to the data format to do so
and there would be tradeoffs in complexity and (maybe) chattiness.
But you could then build on HTTP caching.

One set of tradeoffs has already been made and that produced the
current design.  That doesn't prevent a well-justified and designed
extension from functioning.  There may be a case for optimization.
But there are probably better ways than inventing a protocol-specific
subscription extension.

--Martin

p.s. Have you looked at RFC 5989?

---

From: sreekanth madhavan <[email-masked]>
Date: Thu, 23 Feb 2012 11:18:59 +0530

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.

[SK]
The notification message sends the changed map information for which the
clients have already subscribed. We have mentioned this point in the
draft(Introduction section). The mechanism was not clearly explained. We can
add this to the draft.
 
Regards,
Sreekanth

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Wednesday, February 22, 2012 8:38 PM
To: sreekanth madhavan
Cc: 'Richard Alimi'; [email-masked]
Subject: Re: [alto] FW: New Version Notification for

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

---

From: Ravi nandiraju <[email-masked]>
Date: Thu, 23 Feb 2012 10:33:10 +0000

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 reuse 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-masked] [[email-masked]] on behalf of Richard Alimi [[email-masked]]
Sent: Wednesday, February 22, 2012 9:13 PM
To: Ben Niven-Jenkins
Cc: Sreekanth madhavan; [email-masked]
Subject: Re: [alto] FW: New Version Notification for    draft-alto-caching-subscription-00.txt