Re: [alto] WebSocket-based notifications

Ravi nandiraju <ravi.nandiraju@huawei.com> Mon, 23 July 2012 07:07 UTC

Return-Path: <ravi.nandiraju@huawei.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2B621F84F2 for <alto@ietfa.amsl.com>; Mon, 23 Jul 2012 00:07:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIsUx8PGUWp9 for <alto@ietfa.amsl.com>; Mon, 23 Jul 2012 00:07:20 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8C86D21F84EC for <alto@ietf.org>; Mon, 23 Jul 2012 00:07:20 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIG33985; Mon, 23 Jul 2012 03:07:14 -0400 (EDT)
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Jul 2012 00:04:11 -0700
Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Jul 2012 00:04:10 -0700
Received: from SZXEML523-MBS.china.huawei.com ([169.254.6.147]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Mon, 23 Jul 2012 15:04:07 +0800
From: Ravi nandiraju <ravi.nandiraju@huawei.com>
To: Enrico Marocco <enrico.marocco@telecomitalia.it>
Thread-Topic: [alto] WebSocket-based notifications
Thread-Index: AQHNYyYb4mU7ZTbG0kmBbVNyNwcp9ZcyFpFD//+MtwCABNifeQ==
Date: Mon, 23 Jul 2012 07:04:07 +0000
Message-ID: <7FA18E7BC523F04096632E46DA905D7A51DC1F08@szxeml523-mbs.china.huawei.com>
References: <5003C514.70806@telecomitalia.it> <7FA18E7BC523F04096632E46DA905D7A51DC0EA7@szxeml523-mbs.china.huawei.com>, <500956C6.6050809@telecomitalia.it>
In-Reply-To: <500956C6.6050809@telecomitalia.it>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.96.96]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "alto@ietf.org" <alto@ietf.org>
Subject: Re: [alto] WebSocket-based notifications
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/alto>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Jul 2012 07:07:23 -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 [enrico.marocco@telecomitalia.it]
Sent: Friday, July 20, 2012 6:31 PM
To: Ravi nandiraju
Cc: alto@ietf.org
Subject: Re: [alto] WebSocket-based notifications

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

On 7/20/12 2:15 PM, Ravi nandiraju wrote:
> 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: alto-bounces@ietf.org [alto-bounces@ietf.org] on behalf of Enrico Marocco [enrico.marocco@telecomitalia.it]
> Sent: Monday, July 16, 2012 1:09 PM
> To: alto@ietf.org
> Subject: [alto] WebSocket-based notifications
>
> 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