Subject: [alto] WebSocket-based notifications

From: Enrico Marocco <[email-masked]>
Date: Mon, 16 Jul 2012 09:39:00 +0200

Folks,

Jan and I have just submitted a draft proposing a server-to-client
notification mechanism based on the WebSocket protocol:
http://tools.ietf.org/html/draft-marocco-alto-ws-01

The mechanism proposed is one of the several possible, and the draft at
this point delineates the idea only at quite a high level, without
delving too deep into the details. Yet it should be enough to start a
focused discussion, so please, if you are interested in the topic, take
a quick read and share your thoughts on the list -- whether you feel
this is a promising way to go, or if you have alternatives that you
think would fit better.

-- 
Ciao,
Enrico

---

From: Ravi nandiraju <[email-masked]>
Date: Fri, 20 Jul 2012 12:15:44 +0000

Hi Enrico,
  I went through the proposed mechanism of notifications based on WebSocket protocol. I think this mechanism has the additional overhead of server needing to keep the connection alive for all the clients which need notification. This works well if the number of clients are less. In case of scenarios where the clients are more, then the server needs to manage a lot of connections. 

The additonal drawback of this mechanism is that if there is no change in the map data then the connections still needs to be managed by the server.

-Ravi

________________________________________
From: [email-masked] [[email-masked]] on behalf of Enrico Marocco [[email-masked]]
Sent: Monday, July 16, 2012 1:09 PM
To: [email-masked]
Subject: [alto] WebSocket-based notifications

Folks,

--
Ciao,
Enrico

---

From: Enrico Marocco <[email-masked]>
Date: Fri, 20 Jul 2012 15:01:58 +0200

There certainly is additional overhead with any push notification
mechanism, esp. as compared to the simple pull model. For sure in terms
of resources needed for maintaining the subscription state of the
clients to be notified and for keeping the notification channels alive.
But that's a price you have to pay if you want to have server-initiated
notifications and in the end I believe the transport protocol will
hardly have a significant impact on it. Can you point out where you
think in WebSocket lays the additional overhead other alternatives do
not suffer from?

Enrico

---

From: Ravi nandiraju <[email-masked]>
Date: Mon, 23 Jul 2012 07:04:07 +0000

Hi Enrico,
   The overhead which I was mentioning in my previous e-mail was about managing the connections even when there is no change in the ALTO map information. I think an explicit subscription/notification mechanism which we proposed in [http://tools.ietf.org/html/draft-alto-caching-subscription-00#section-8] does not have this overhead because the server would initiate the connection only when required. The server does'nt need to maintain the connection when there is no change in the map information.
   The mechanism which is proposed in the websocket based notification is an implicit subscription where the connection implies the subscription. To keep the subscription alive, the connection needs to be alive. In many cases, the client just wants to subscribe and get notified only when there is a change in the map data otherwise the connection is just an overhead.

-Ravi
________________________________________
From: Enrico Marocco [[email-masked]]
Sent: Friday, July 20, 2012 6:31 PM
To: Ravi nandiraju
Cc: [email-masked]
Subject: Re: [alto] WebSocket-based notifications

Enrico

---

From: Enrico Marocco <[email-masked]>
Date: Mon, 23 Jul 2012 09:44:09 +0200

Ok, I see you point. I agree that, for resources that rarely change
there may be even a substantial gain with having the connection
initiated by the server only upon an update event. On the flip side, for
constantly changing resources (e.g. representing uptime-like information
about server load) the overhead of a full HTTP request for each and
every update would easily exceed the overhead due to maintaining a
websocket connection.

More concerning than overhead is however the reachability requirement
that a mechanism based on server-initiated connections pose on the
client side, and that in fact would make it unsuited for any host
residing behind a NAT -- the vast majority of end-user devices.

Enrico

---

From: Ravi nandiraju <[email-masked]>
Date: Tue, 24 Jul 2012 09:57:28 +0000

Hi Enrico,

   Yes. Websockets will be useful for cases where there are frequent notifications (like server load etc). This is only one use case for subscription/notification. IMO, we should define a generic framework for subscription/notification which includes support for things like multiple event subscription and does'nt have the overhead of persistent connections when the clients are not interested to keep them.
   Regarding the server creating a connection to the client, the client explicitly advertises its contact address for the server to connect to. The reachability problem should be solved by the client.

-Ravi

________________________________________
From: Enrico Marocco [[email-masked]]
Sent: Monday, July 23, 2012 1:14 PM
To: Ravi nandiraju
Cc: [email-masked]
Subject: Re: [alto] WebSocket-based notifications

Enrico

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 24 Jul 2012 12:40:16 +0200

On 7/24/12 11:57 AM, Ravi nandiraju wrote:
> Yes. Websockets will be useful for cases where there are frequent
> notifications (like server load etc). This is only one use case for
> subscription/notification. IMO, we should define a generic framework
> for subscription/notification which includes support for things like
> multiple event subscription and does'nt have the overhead of
> persistent connections when the clients are not interested to keep
> them.

This is actually something the authors would like to get feedback about,
i.e. whether people prefer to have one connection per resource, or some
sort of subscription protocol running for multiple resources on a single
connection. The draft at this point suggests the former approach,
basically for simplicity.

> Regarding the server creating a connection to the client, the client
> explicitly advertises its contact address for the server to connect
> to. The reachability problem should be solved by the client.

I cannot think of any way for the client to solve the reachability
problem that is less demanding in terms of resources than a
client-initiated connection. Can you suggest one that works with today's
firewalls, access gateways and carrier NATs?

-- 
Ciao,
Enrico

---

From: Ravi nandiraju <[email-masked]>
Date: Wed, 25 Jul 2012 05:47:12 +0000

I agree that NAT traversal is complex but that is for a peer to peer network where both the peers are behind NATs and they need to figure out their reachability. In case of ALTO we don't have that kind of complexity. The ALTO client which expects the server to connect to it needs to ensure that it is reachable on that address/port from an external/internal network. This is same as the way an ALTO server behind a carrier firewall is configured to be reachable to clients outside.

I don't envisage ALTO clients like home devices using the subscription mechanism because, for a home device client it is easier to query the ALTO server for a changed map information rather than going for a subscription. 

IMO, this subscription mechanism would be useful for infrastructure cases like gateway devices, CDN, inter-DC etc where the problem of reachability is not so complex as in the case of peer to peer.

Please let me know if there is something I am missing here.

-Ravi
________________________________________
From: Enrico Marocco [[email-masked]]
Sent: Tuesday, July 24, 2012 4:10 PM
To: Ravi nandiraju
Cc: [email-masked]
Subject: Re: [alto] WebSocket-based notifications

--
Ciao,
Enrico

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 25 Jul 2012 09:43:56 +0200

On 7/25/12 7:47 AM, Ravi nandiraju wrote:
> I don't envisage ALTO clients like home devices using the
> subscription mechanism because, for a home device client it is easier
> to query the ALTO server for a changed map information rather than
> going for a subscription.

Just to be clear, here by "home device" you actually mean "user
devices", i.e. any laptop, desktop, smartphone and whatnot that may for
example run in a home network.

> IMO, this subscription mechanism would be useful for infrastructure
> cases like gateway devices, CDN, inter-DC etc where the problem of
> reachability is not so complex as in the case of peer to peer.

And useless in any environments where global reachability cannot be
taken for granted. Agreed.

-- 
Ciao,
Enrico

---

From: Ravi nandiraju <[email-masked]>
Date: Wed, 25 Jul 2012 08:39:42 +0000

________________________________________
From: Enrico Marocco [[email-masked]]
Sent: Wednesday, July 25, 2012 1:13 PM
To: Ravi nandiraju
Cc: [email-masked]
Subject: Re: [alto] WebSocket-based notifications

[Ravi] Yes. What I meant by "home device" are the devices which are used by end users as P2P clients and which could potentially use ALTO as clients.

[Ravi] Basically what I meant was, we don't need to consider the case of  "user devices" for subscription/notification because for them it is easier to query the information based on need rather than subscribing. I am not very clear if reachability is really a concern in the use case for ALTO subscription/notification.

--
Ciao,
Enrico

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 25 Jul 2012 19:40:25 +0800

Hi Enrico, Ravi,

On Wednesday, July 25, 2012, Ravi nandiraju wrote:

> From: Enrico Marocco [[email-masked] <javascript:;>]
> Cc: [email-masked] <javascript:;>

> [Ravi] Yes. What I meant by "home device" are the devices which are used
> by end users as P2P clients and which could potentially use ALTO as clients.
>
> [Ravi] Basically what I meant was, we don't need to consider the case of
>  "user devices" for subscription/notification because for them it is easier
> to query the information based on need rather than subscribing. I am not
> very clear if reachability is really a concern in the use case for ALTO
> subscription/notification.

Interesting perspective to focus on the desgn scenario. Ignoring
reachability for a moment and considering only overhead, since the number
of user devices will be large, the design of user-device-pull vs that of
server-push-to-user-device will be a trade off between bandwidth/throughput
vs server connection/open connection overheads. In this setting, I agree
that user-device-pull appears to be more preferred. On the other hand, if
we consider alto as a mechanism for network to update info to user devices
(e.g., end point properties, in a general context; i am even thinking of
network notify user device its last mile usage/quota/load properties), then
server-push-to-user-device can have benefits, such as low latency. What do
you think or this is too pushed?

Thanks!

Richard

>
> --
> Ciao,
> Enrico
> _______________________________________________
> alto mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sun, 29 Jul 2012 23:43:04 +0000

Hi,

Just to add another bit of confusion...

When reading this thread I was wondering whether a solution based on
bi-directional data streams, that would keep one single connection per
client-server association while allowing for different resources to be
queried and updated, could be considered.

What I have in mind is the use of XMPP for bi-directional ALTO
interactions. Apart from the features outlined in the paragraph above, it
does fit well with ALTO encoding and operational semantics, and
there is a well established corpus of (many of them open) implementations.

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]
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: Peter Saint-Andre <[email-masked]>
Date: Tue, 31 Jul 2012 12:26:40 -0600

> there is a well established corpus of (many of them open) implementations.

It certainly seems to me that we could use XMPP here. However, I'll need
to read draft-marocco-alto-ws before providing more detailed comments. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/