Subject: Re: [alto] Pub-sub interfaces

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 01 Jan 2014 21:44:16 +0000

Hi Richard,

A Message Broker is a general construct in pub-sub environments, acting as mediator for publishers and subscribers, matching interests and announcements, and enforcing access policies. I'd think of it as an essential part of the pub-sub middleware, not necessarily as a central server or a bottleneck.

I agree the document is rather general: bear in mind it is a first statement addressed to a WG like I2RS, with very broad goals and in its initial stages. My intention was precisely to provide it as an initial reference for the ALTO crowd to consider and discuss on use cases. The one you mention is the one I had in mind. More complicated ones could include hierarchical aggregation, composition of information from different servers, or data filtering driven by policies. I guess this could be applicable in inter-domain scenarios.

Be goode and have an Extremely Goode New Year,

On 31 Dec 2013, at 03:05 , Y. Richard Yang wrote:

Hi Diego,

Thanks a lot for posting the link. I read the document and it was a well-written document. If the document provides more text to review the two pub-sub models and how they may apply to I2RS, it will be more self-contained.

A key proposal from the document, I see, is the introduction of a Message Broker. A main motivation appears to be scalability, i.e., to avoid the P * S problem, where P is the number of publishers and S the number of subscribers.

One problem of the document is that it appears to be quite broad, where either applications or routers can publish and subscribe (not sure if routers will subscribe though), and many types (e.g., router/device status changes, app info changes? policy changes) are mentioned. This may imply that the schema of the pub-sub system can be quite complex or very generic. We know generic, well-used systems such as Google Chabby (Zookeeper), and hence I will wait to see the details of any specific proposals, on whether they will apply to ALTO. A concrete issue that I will look for is on how to encode updates of a large data set, e.g., a Network/Cost Map.

As a simple, related use case of their scheme, an ALTO Server can be a publisher to push any incremental updates to the Media Broker, who can then handle a large number of subscribers. More complicated use cases or ALTO should develop its own sub-pub mechanism?

Happy New Year!

Richard

On Fri, Dec 27, 2013 at 10:58 AM, Diego R. Lopez <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Some time ago we discussed about the pros and cons of using Websockets for implementing server-to-client notifications and I mentioned the possibility of using a pub-sub schema for creating a general notification framework.

While reviewing some messages during my end-of-year tidying I came through this draft:
http://tools.ietf.org/html/draft-camwinget-i2rs-pubsub-sec-00
contributed to I2RS, that discusses the application of the model in the access to a programmatic interface to the routing system. I think it provides a good overview of the model, and that many of the considerations are applicable to ALTO notifications, and even more to a generalized topology service.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041<tel:%2B34%20913%20129%20041>
Mobile: +34 682 051 091<tel:%2B34%20682%20051%20091>
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
alto mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/alto

--
--
 =====================================
| Y. Richard Yang <[email-masked]<mailto:[email-masked]>>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 2 Jan 2014 17:29:00 -0500

Hi Diego,

On Wed, Jan 1, 2014 at 4:44 PM, Diego R. Lopez <[email-masked]> wrote:

>
> I agree the document is rather general: bear in mind it is a first
> statement addressed to a WG like I2RS, with very broad goals and in its
> initial stages. My intention was precisely to provide it as an initial
> reference for the ALTO crowd to consider and discuss on use cases. The one
> you mention is the one I had in mind. More complicated ones could include
> hierarchical aggregation, composition of information from different
> servers, or data filtering driven by policies. I guess this could be
> applicable in inter-domain scenarios.
>
>
Very interesting additional use cases (aggregation, composition, and
filtering all make sense, for example in the case of interdomain). I
remember previous discussions on building such capabilities (e.g.,
filtering) on top of ALTO, either using the ALTO protocol (e.g., by
extension within ALTO), or using a completely different protocol (e.g., the
proposed scheme). One interesting question to think about,   is what we
need to change ALTO, if any, if we use the second, which hopefully has a
lower amount of work than the first. Personally, I am fine with using a
generic pub-sub service and then multiple services (e.g., ALTO) can use it.
If the generic service can handle the ALTO's schema is a key question.

Cheers,

Richard

>  Thanks a lot for posting the link. I read the document and it was a
> well-written document. If the document provides more text to review the two
> pub-sub models and how they may apply to I2RS, it will be more
> self-contained.
>
>  A key proposal from the document, I see, is the introduction of a
> Message Broker. A main motivation appears to be scalability, i.e., to avoid
> the P * S problem, where P is the number of publishers and S the number of
> subscribers.
>
>  One problem of the document is that it appears to be quite broad, where
> either applications or routers can publish and subscribe (not sure if
> routers will subscribe though), and many types (e.g., router/device status
> changes, app info changes? policy changes) are mentioned. This may imply
> that the schema of the pub-sub system can be quite complex or very generic.
> We know generic, well-used systems such as Google Chabby (Zookeeper), and
> hence I will wait to see the details of any specific proposals, on whether
> they will apply to ALTO. A concrete issue that I will look for is on how to
> encode updates of a large data set, e.g., a Network/Cost Map.
>
>  As a simple, related use case of their scheme, an ALTO Server can be a
> publisher to push any incremental updates to the Media Broker, who can then
> handle a large number of subscribers. More complicated use cases or ALTO
> should develop its own sub-pub mechanism?
>
>  Happy New Year!
>
>  Richard
>
>
>
>
> On Fri, Dec 27, 2013 at 10:58 AM, Diego R. Lopez <[email-masked]> wrote:
>
>> Hi,
>>
>> Some time ago we discussed about the pros and cons of using Websockets
>> for implementing server-to-client notifications and I mentioned the
>> possibility of using a pub-sub schema for creating a general notification
>> framework.
>>
>> contributed to I2RS, that discusses the application of the model in the
>> access to a programmatic interface to the routing system. I think it
>> provides a good overview of the model, and that many of the considerations
>> are applicable to ALTO notifications, and even more to a generalized
>> topology service.
>>
>> Be goode,
>>
>> --
>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
>> nuestra política de envío y recepción de correo electrónico en el enlace
>> situado más abajo.
>> This message is intended exclusively for its addressee. We only send and
>> receive email on the basis of the terms set out at:
>> [email-masked]
> | Y. Richard Yang <[email-masked]>   |
> ------------------------------
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================