RE: [P2PSIP] Open issues with client has multiple associated peers

Song Yongchao <melodysong@huawei.com> Tue, 29 January 2008 11:06 UTC

Return-path: <p2psip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJoIA-00034h-6a; Tue, 29 Jan 2008 06:06:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJoI8-00034W-LF for p2psip@ietf.org; Tue, 29 Jan 2008 06:06:12 -0500
Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJoI6-0001WX-M9 for p2psip@ietf.org; Tue, 29 Jan 2008 06:06:12 -0500
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JVE00L2IK561Q@szxga02-in.huawei.com> for p2psip@ietf.org; Tue, 29 Jan 2008 19:05:30 +0800 (CST)
Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JVE00JWPK51BR@szxga02-in.huawei.com> for p2psip@ietf.org; Tue, 29 Jan 2008 19:05:30 +0800 (CST)
Received: from s64081 ([10.164.9.47]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JVE0035EK51JD@szxml03-in.huawei.com> for p2psip@ietf.org; Tue, 29 Jan 2008 19:05:25 +0800 (CST)
Date: Tue, 29 Jan 2008 19:05:25 +0800
From: Song Yongchao <melodysong@huawei.com>
Subject: RE: [P2PSIP] Open issues with client has multiple associated peers
In-reply-to: <!&!AAAAAAAAAAAYAAAAAAAAAIILieByQXtOrs7W/bI503TCgAAAEAAAAK2atB6ek1dDnENOFPMnnZkBAAAAAA==@huawei.com>
To: 'Song Yongchao' <melodysong@huawei.com>, 'P2PSIP Mailing List' <p2psip@ietf.org>
Message-id: <!&!AAAAAAAAAAAYAAAAAAAAAIILieByQXtOrs7W/bI503TCgAAAEAAAAF5bAMcw6eBIqcQfYqsneRQBAAAAAA==@huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: AchiZXWSSVDQyY9hSGe9iUcx/Bj3egAALe0Q
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc:
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Errors-To: p2psip-bounces@ietf.org

I need to modify the second question to make it more clear.
 
 I think most proposals agree that one client can have multiple associated
peers to keep the service continuity. The open issues are:
 
(1) Should there be a primary associated peer? And when this peer fails, the
client switches to another associated peer? I am not sure of about it.
 
(2)Should the client learn more peers information that can be the client's
associated peers through its now associated peer? And when one of its
associated peers fails, it joins another to keep enough associated peers for
choice? I think probably this is what we needed.
 
(3)Should there be a notification mechanism between a client and its
associated peer? So the client can timely know the status of the associated
peer, and avoid choosing the congested or busy peer to serve him? I think we
do need it.
 
 Best Regards,
 Song Yongchao
 Email: melodysong@huawei.com
 


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip