Re: [P2PSIP] New draft: HIP BONE

"Bruce Lowekamp" <lowekamp@sipeerior.com> Thu, 10 January 2008 16:19 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 1JD08B-0007Hs-DP; Thu, 10 Jan 2008 11:19:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD08A-0007HU-Fb for p2psip@ietf.org; Thu, 10 Jan 2008 11:19:46 -0500
Received: from wa-out-1112.google.com ([209.85.146.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JD086-0002FI-Sb for p2psip@ietf.org; Thu, 10 Jan 2008 11:19:46 -0500
Received: by wa-out-1112.google.com with SMTP id k40so1566528wah.25 for <p2psip@ietf.org>; Thu, 10 Jan 2008 08:19:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=XD2FlHP/qbrunyMZXK7GcPe56hIPW+kRtjzLHrAbZJE=; b=dH8FZUWIdasZH2HsLG2eCiMwJfjRBsjU5Q3eiukOfEq0TDcXa2W3+eBteoqS78SLvhyYiMxvvV6+bfLN5NgIfn/I5SgvhthaJDrug/OvGzkQ/k9oUF13i6hCzYshUappBR9E8lgmKBQxwisuxYyHcFyI8y1Hgh9l/udYtXE+NJA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=jcVs8zgVARcO0XrtdqNznBwSh7GJMfyh6SkO73SXxyrSz+z3u7LZ1YPpvPXP/WOZSWVuCsLI0+mVpGwRoDyTZpts1k4VJ9vVq8TxVIIzzhkvtAoUsu9QgEH1bbm8PTB+z47X4IZkGfl1PcTquSC5/FsXndev2Eyj4lIsDW7lo2c=
Received: by 10.114.13.1 with SMTP id 1mr2418403wam.106.1199981979855; Thu, 10 Jan 2008 08:19:39 -0800 (PST)
Received: by 10.114.209.13 with HTTP; Thu, 10 Jan 2008 08:19:39 -0800 (PST)
Message-ID: <20d2bdfb0801100819g64d64a2bpaaa0a9ac6a535c4d@mail.gmail.com>
Date: Thu, 10 Jan 2008 11:19:39 -0500
From: Bruce Lowekamp <lowekamp@sipeerior.com>
To: Pekka Nikander <pekka.nikander@nomadiclab.com>
Subject: Re: [P2PSIP] New draft: HIP BONE
In-Reply-To: <57B24871-D72C-4043-A9F4-B2E5AFA8CC52@nomadiclab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <476BA8D9.4010203@ericsson.com> <20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> <476E2B7C.9070601@ericsson.com> <20d2bdfb0801081416t41b9b84atb3a147659771036@mail.gmail.com> <57B24871-D72C-4043-A9F4-B2E5AFA8CC52@nomadiclab.com>
X-Google-Sender-Auth: 0e2f269697c36763
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
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

On Jan 10, 2008 3:17 AM, Pekka Nikander <pekka.nikander@nomadiclab.com> wrote:
> Hi Bruce,
>
> > - the peer protocol sets the next-hop for the query to "5" based on
> > its own routing table, and lets the HIP layer forward it.  I will
> > refer to this as the hip link layer approach.
>
> The only difference that I can see between the previous one and this
> one is that here there are no explicit routing table.  Hence, instead
> of doing the typical thing routers do, i.e., to compute a forwarding
> table from the routing table as a "batch job" the forwarding decision
> is performed "lazily" on demand.
>
> > 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.  I think in a later
message I sent yesterday, I looked a bit more at the layering and
believe that it's not a layering violation, but an interface that is
needed between the two adjacent layers.


>
> > Next, let's take the case of 3.3, "lightweight message exchange."
> > As I understand 3.3, it should work fine in the hip routing table
> > approach for both application and peer protocol message exchanges.
> > In the hip link layer approach, peer protocol messages can be
> > delivered this way, but application messages cannot (they would
> > require a direct connection).
>
> I don't quite understand what you are saying.  Would you please clarify?
>

As I thought of the "hip link layer" approach, it was somewhat limited
in what it could do independently without the request of the peer
protocol.


> > 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.

Bruce

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