RE: [P2PSIP] New draft: draft-matthews-p2psip-hip-hop-00

JiangXingFeng <jiang.x.f@huawei.com> Wed, 27 June 2007 02:04 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 1I3Mt4-0006zh-HN; Tue, 26 Jun 2007 22:04:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Mt3-0006zZ-68 for p2psip@ietf.org; Tue, 26 Jun 2007 22:04:05 -0400
Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Msx-00013W-1Q for p2psip@ietf.org; Tue, 26 Jun 2007 22:04:05 -0400
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JK900BPIV10TU@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 27 Jun 2007 10:03:00 +0800 (CST)
Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JK90080DV0ZI2@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 27 Jun 2007 10:03:00 +0800 (CST)
Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JK900H2PV0WLS@szxml03-in.huawei.com> for p2psip@ietf.org; Wed, 27 Jun 2007 10:02:59 +0800 (CST)
Date: Wed, 27 Jun 2007 10:02:56 +0800
From: JiangXingFeng <jiang.x.f@huawei.com>
Subject: RE: [P2PSIP] New draft: draft-matthews-p2psip-hip-hop-00
In-reply-to: <7A7D2D13-9CE0-4F75-9D6A-BBA0899B0748@magma.ca>
To: 'Philip Matthews' <philip_matthews@magma.ca>
Message-id: <003a01c7b85f$47bd4a20$6905a40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Thread-index: Acew4ZzpomBzIqHPRuWy47yMQWGj9QHfRjAQ
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
Cc: 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

HI, Philip:

In all, using HIP to deliver peer protocol message is an interesting topic.
I give some comments below.
Regards!

1. section 1.1 Note that SIP and other applications an access the
Distributed Transport function directly without going through the other two
functions.

[JiangXingFeng]Do you want to make the distributed transported function so
general that all application messages could be forwarded in the overlay? 

Let me show an example: 
Alice wants to call Bob? How does Alice send the Invite message? Send to Bob
through the overlay or get the Bob's contact address first, later send to
Bob directly? If Alice sends the invite message through the overlay, what
does the admitting peer of Bob's key do? Forward the message to Bob's
contact address? If it forwards the message, how does the admitting peer
know the characteristic of the value under this key?

2.   o  Network layer: The ability to deliver a message to an arbitrary peer
in the overlay.  In our view, this involves adding a header to the message
that specifies the destination peer ID and then routing that message along
existing connections in the overlay to the destination peer.

[JiangXingFeng] What does the network layer refer to? IP layer or overlay
network layer? 
In my opinion, it refers to overlay network layer here.

3. Figure 2:Each peer in the network is behind its own NAT. 
What does this statement mean? 

4.   There are two ways to send a packet to another peer in the overlay:
   send it on a direct connection to the remote peer, or send it hop-by-
   hop through the overlay.  A peer typically uses hop-by-hop routing
   when it has only a small amount of data to transfer to the remote
   peer (for example, a Distributed Database update or a SIP INVITE
   transaction), and sets up a direct connection when it has a larger
   amount of data to transfer (for example, an RTP session).

In my opinion, only the peer protocol message should be routed hop-by-hop
through the overlay? Like the comments in 1, how does the admitting peer
process the application message? Maybe the peer does not recognize the
specific application message? 

That Sending packets directly to destination peer, i think, is a problem
arising from the usage of HIP, not in the scope of P2P, because in P2PSIP
case, not all communications should be protected by IPSEC ESP.


--
Jiang XingFeng


> -----Original Message-----
> From: Philip Matthews [mailto:philip_matthews@magma.ca]
> Sent: Sunday, June 17, 2007 9:15 PM
> To: P2PSIP Mailing List
> Subject: [P2PSIP] New draft: draft-matthews-p2psip-hip-hop-00
> 
> Folks:
> 
> Eric Cooper, Alan Johnston, and I have just written a draft that
> suggests what we think
> is an interesting direction for the P2PSIP working group.
> 
> We argue that a P2PSIP overlay should use HIP (the Host Identity
> Protocol)
> to provide a number of the basic features in an overlay, namely:
> 	o  Peer IDs;
> 	o  Transporting messages around the overlay;
> 	o  Signaling new overlay connections;
> 	o  Supporting mobility and multi-homing of peers;
> 	o  Providing message security.
> 
> One of the reasons we really like this idea is because, using the
> approach
> described in the draft, many existing applications don't require any
> modifications
> and "just work" in an overlay.
> 
> We describe this idea in a draft that has just been submitted.
> Until the draft appears in the archives, you can get a copy at
> 	http://www.magma.ca/~philip_matthews/draft-willis-p2psip-
> concepts-04.txt
> or for the html version
> 	http://www.magma.ca/~philip_matthews/draft-willis-p2psip-
> concepts-04.htm
> 
> Here is the abstract from the draft:
>     This document examines a P2PSIP architecture where the peer-to-peer
>     (P2P) layer is separate from and lies below the SIP layer.  We
>     discuss the functions of the P2P layer in such an architecture, and
>     focus in on the Distributed Transport function - the function that
>     allows a peer to exchange messages with any other peer in the
>     overlay, even in the presence of NATs.  We list the features that
> the
>     Distributed Transport function needs to provide, and observe that
> the
>     Host Identity Protocol (HIP) already provides a number of these
>     features.  We then propose extensions to HIP that allow it to
> provide
>     the missing features.  We discuss how a complete P2PSIP architecture
>     can be built around HIP, and contrast this approach with other
>     approaches for implementing a P2P layer.  Two of the advantages of
>     HIP approach are that (a) most existing applications can run in an
>     overlay without needing any changes and (b) peer mobility and NAT
>     traversal are handled in a way that is transparent to most
>     applications.
> 
> - Philip
> 
> 
> _______________________________________________
> 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