[alto] ALTO for realtime data?

[Börje Ohlman]

I’m interested in finding out if there are thoughts on making it possible to use ALTO for realtime data in the future, or at least possible to use it for data that is being updated quite frequently. Examples of such data could be available bandwidth on links, available storage capacity in caches or CPU load in processing resources.

One possible way to enable such use of ALTO could be to provide a pub/sub option for communication between ALTO clients and servers. Another option is that clients polls the servers at certain intervals. While the pub/sub alternative would be nice it probably would mean substantial changes to the ALTO architecture and protocols. I found an old (2012) draft proposing this draft-madhavan-alto-subscription-01. Does anyone know if this work has continued in some shape or form? If not, does anybody have any history to tell about it? The problem the draft is primarily addressing is to avoid multiple redundant requests for parameter values that have not changed.

I would like to propose a more lightweight mechanism to reduce this problem. We could introduce the possibility for responses from ALTO servers to indicate an expected freshness period for the returned value giving the client a hint to when it makes sense to make the next request.

I by no means consider myself an ALTO expert, so if this functionality already is provided in the existing protocols or it has been already discussed at length, please inform me and accept my apologies for wasting bandwidth on the mailing list.

Börje Ohlman

[Jensen Zhang]

Hi Börje,

I am not familiar with the old darft (draft-madhavan-alto-subscription-01)
you just mentioned. But if you are talking about the pub/sub mechanism in
ALTO, I believe the SSE document (draft-ietf-alto-incr-update-sse-13) is a
solution. The SSE document defines a new service which allows the ALTO
client to subscribe the real-time update of ALTO resources, and allows the
ALTO server to publish the update via the server-sent event stream. And the
update can be incremental, which means the ALTO server will only publish
the diff patch of the subscribed resources without the JSON nodes that have
not changed. This document is already in WG Last Call now.

However, I think the real-time data retrieving is still an interesting
topic. Even if we have the pub/sub mechanism, several issues on the
real-time data still remain:

1. Currently, there is no mechanism to make the client and the server agree
on how frequently the update should be triggered. It is not expected if
some data will be updated very frequently so that when the client receives
the update it is already expired.
2. The unreliable pub will make the client and the server inconsistent. The
thing comes worse when there are multiple dependent resources subscribed.
If one resource is updated successfully but its dependency fails to be
updated, the client will get inconsistent information.
3. The two issues above can be combined. Consider the case: when the client
receives the update of one resource, the update of its dependency is
already expired.

Those issues do not come from the pub/sub mechanism, but the general
real-time data updates. I have some rough ideas about them but no complete
solution so far.

Maybe the authors of SSE document can say more words.

Best,
Jensen

I’m interested in finding out if there are thoughts on making it possible
to use ALTO for realtime data in the future, or at least possible to use it
for data that is being updated quite frequently. Examples of such data
could be available bandwidth on links, available storage capacity in caches
or CPU load in processing resources.
One possible way to enable such use of ALTO could be to provide a pub/sub
option for communication between ALTO clients and servers. Another option
is that clients polls the servers at certain intervals. While the pub/sub
alternative would be nice it probably would mean substantial changes to the
ALTO architecture and protocols. I found an old (2012) draft proposing this
draft-madhavan-alto-subscription-01. Does anyone know if this work has
continued in some shape or form? If not, does anybody have any history to
tell about it? The problem the draft is primarily addressing is to avoid
multiple redundant requests for parameter values that have not changed.
I would like to propose a more lightweight mechanism to reduce this
problem. We could introduce the possibility for responses from ALTO servers
to indicate an expected freshness period for the returned value giving the
client a hint to when it makes sense to make the next request.
I by no means consider myself an ALTO expert, so if this functionality
already is provided in the existing protocols or it has been already
discussed at length, please inform me and accept my apologies for wasting
bandwidth on the mailing list.
Börje Ohlman
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto