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

"Roy, Radhika R Dr CTR USA USAMC" <radhika.r.roy@us.army.mil> Tue, 29 January 2008 14:16 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 1JJrGl-0002qg-N3; Tue, 29 Jan 2008 09:16:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJrGk-0002qP-IG for p2psip@ietf.org; Tue, 29 Jan 2008 09:16:58 -0500
Received: from mxoutps1.us.army.mil ([143.69.250.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJrGf-0000WU-Kq for p2psip@ietf.org; Tue, 29 Jan 2008 09:16:58 -0500
DomainKey-Signature: s=ako; d=us.army.mil; c=nofws; q=dns; h=From:X-AKO:X-IronPort-AV:Received:Received:To:Cc: Message-ID:Date:X-Mailer:MIME-Version:Content-Language: Subject:X-Accept-Language:Priority:In-Reply-To:References: Content-Type:Content-Disposition: Content-Transfer-Encoding; b=qIRqJj3INuPO1huTGIqz6vfn9Jw96Z+GflrEEaBS+tfkT8GyifSwCMad fZ+0WdMv0912qOvfCokgsH5EV0utNA==;
From: "Roy, Radhika R Dr CTR USA USAMC" <radhika.r.roy@us.army.mil>
X-AKO: 97033817:10.224.36.65:29 Jan 2008 14:16:46 +0000:$Webmail:None
X-IronPort-AV: E=Sophos;i="4.25,269,1199664000"; d="scan'208";a="97033817"
Received: from mail5.int.ps1.us.army.mil (HELO us.army.mil) ([10.224.36.65]) by mxoutps1.us.army.mil with ESMTP; 29 Jan 2008 14:16:46 +0000
Received: from [10.240.32.176] (Forwarded-For: 134.80.13.193, [10.240.32.176]) by mail5.int.ps1.us.army.mil (mshttpd); Tue, 29 Jan 2008 09:16:46 -0500
To: Song Yongchao <melodysong@huawei.com>
Message-ID: <df51fa9c2c5cf.479eeefe@us.army.mil>
Date: Tue, 29 Jan 2008 09:16:46 -0500
X-Mailer: Sun Java(tm) System Messenger Express 6.2-9.04 (built Jun 11 2007)
MIME-Version: 1.0
Content-Language: en
Subject: Re: RE: [P2PSIP] Open issues with client has multiple associated peers
X-Accept-Language: en
Priority: normal
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAIILieByQXtOrs7W/bI503TCgAAAEAAAAF5bAMcw6eBIqcQfYqsneRQBAAAAAA==@huawei.com>
References: <!&!AAAAAAAAAAAYAAAAAAAAAIILieByQXtOrs7W/bI503TCgAAAEAAAAK2atB6ek1dDnENOFPMnnZkBAAAAAA==@huawei.com> <!&!AAAAAAAAAAAYAAAAAAAAAIILieByQXtOrs7W/bI503TCgAAAEAAAAF5bAMcw6eBIqcQfYqsneRQBAAAAAA==@huawei.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
X-Spam-Score: -4.0 (----)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: 'P2PSIP Mailing List' <p2psip@ietf.org>
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

Please see my inputs inline [RRR]

----- Original Message -----
From: Song Yongchao 
Date: Tuesday, January 29, 2008 6:06
Subject: RE: [P2PSIP] Open issues with client has multiple associated peers
To: 'Song Yongchao' , 'P2PSIP Mailing List' 

> I need to modify the second question to make it more clear.
> 
> I think most proposals agree that one client can have multiple 
> associatedpeers 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.

[RRR] I think the answer is none from the protocol point of view. However, if clients wants to make something as its primary, secondary, etc., it should be left for implementations. It is a different area how a client will these choices.

> (2)Should the client learn more peers information that can be the 
> client'sassociated 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.

[RRR] Yes, definitely. I guess that it is the beauty of the P2P protocol to make as reliable as one can make.
> 
> (3)Should there be a notification mechanism between a client and its
> associated peer? So the client can timely know the status of the 
> associatedpeer, and avoid choosing the congested or busy peer to 
> serve him? I think we
> do need it.

[RRR] I think that the performance criteria for choosing a peer should be a general one as it is the usual case in any communications networks. For example, in the IP network, the routers also have some general criteria how to choose the netxt hop router out of many neighboring routers. In the same token, the P2P protocol should also follow the similar mechanisms that are obvious.
> 
> Best Regards,
> Song Yongchao
> Email: melodysong@huawei.com
> 
> 
> 
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip
> 

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