Re: [P2PSIP] New draft: HIP BONE

Spencer Dawkins <spencer@mcsr-labs.org> Thu, 10 January 2008 22:42 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 1JD66L-0005IB-QI; Thu, 10 Jan 2008 17:42:17 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD66K-0005I5-IU for p2psip@ietf.org; Thu, 10 Jan 2008 17:42:16 -0500
Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JD66K-0006tI-6J for p2psip@ietf.org; Thu, 10 Jan 2008 17:42:16 -0500
Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUG0099D9QFJJ@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 10 Jan 2008 14:42:15 -0800 (PST)
Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JUG00JQX9QAL4@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 10 Jan 2008 14:42:15 -0800 (PST)
Date: Thu, 10 Jan 2008 16:41:28 -0600
From: Spencer Dawkins <spencer@mcsr-labs.org>
Subject: Re: [P2PSIP] New draft: HIP BONE
To: P2PSIP Mailing List <p2psip@ietf.org>
Message-id: <0ba601c853d9$f0cdffe0$6601a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <476BA8D9.4010203@ericsson.com> <20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> <476E2B7C.9070601@ericsson.com> <20d2bdfb0801081416t41b9b84atb3a147659771036@mail.gmail.com> <57B24871-D72C-4043-A9F4-B2E5AFA8CC52@nomadiclab.com> <20d2bdfb0801100819g64d64a2bpaaa0a9ac6a535c4d@mail.gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
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, Bruce,

From: "Bruce Lowekamp" <lowekamp@sipeerior.com>

> On Jan 10, 2008 3:17 AM, Pekka Nikander <pekka.nikander@nomadiclab.com> 
> wrote:
>> Hi Bruce,
>>
>> > The hip routing table approach looks great from a layering
>> > perspective, but implementation looks to be very hard.
>>
>> Why?  Do you allude that the various overlay routing protocols are
>> sufficiently different from the IP routing protocols so that one
>> cannot compute a forwarding table?  Or is there some other
>> implementation problem that you are thinking about?
>
> The issue I'm concerned about here is that different DHTs use
> completely different routing algorithms.  For example, for Chord you
> forward the message to the peer with the closest ID that is < the
> target, but with Kademlia, you do a prefix match and calculate
> distances with xor.  I'm sure it's possible to come up with a safe
> language or something that could be used to describe how to make
> routing decisions, but it's certainly non-trivial.

This is my concern also, FWIW. I also think it's possible, and I also think 
it's non-trivial.

>> > So in the hip routing table approach, the I1 etc messages are
>> > routed via 5 using HIP to 10 and eventually a new direct connection
>> > is established.
>>
>> Well, depending on many factors, it may be only a subset of the HIP
>> base exchange messages that would be routed over the overlay (through
>> node 5); some of them (like perhaps R2) could perhaps be sent
>> directly, at least in some cases.  So, there is some flexibility
>> here, but at least I don't quite understand the situation in cases
>> where both 1 and 10 are behind NATs.
>
> As long as they are both reachable in the overlay, both peers behind
> nats isn't a problem as long as the ice message exchanges are carried
> over the overlay.

I'm not saying there is a chicken-and-egg problem, but I'm not sure that 
there isn't (yet).

Thanks,

Spencer 



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