Subject: Re: [P2PSIP] Re: a modular approach for integrating HIP for P2PSIP

From: Miika Komu <[email-masked]>
Date: Tue, 8 Jan 2008 21:13:48 +0200 (EET)

On Mon, 31 Dec 2007, Gonzalo Camarillo wrote:

Hi Ali and Gonzalo,

sorry for catching up late.

> Hi Ali,
>
> HIP includes an ICE-based NAT traversal mechanism. If two nodes use HIP, 
> they will perform ICE at the HIP level, not at the application level. 
> Using application-level ICE to negotiate the use of HIP between nodes, 
> per your email below, is cumbersome. The use of HIP can be negotiated in 
> simpler ways.
>

Basically I agree with Gonzalo here, but to be more specific...

In a "normal" (no overlay, no extra mods to ICE or HIP) HIP scenario, 
sending some data to a HIT would trigger an I1. Either with or without UDP 
encapsulation, depending on local policies. When I1 is sent without UDP, 
the hipd could speed up the connection set-up in the case there are no 
NATs between the two machines. However, the ICE module would not know 
when to stop the connectivity tests, because it wasn't HIP-aware in this 
case. Also, this "optimization" would be unnecessary in the case there are 
NATs between the two hosts because the HIP messages would be just dropped.

In another non-overlay scenario, where ICE is HIP-aware, we could define 
that ICE and HIP module can interact with each other. Sending STUN 
messages to a HIT would trigger a I1 packet without UDP encapsulation and 
upon success the HIP module could abort the ICE connectivity tests 
gracefully. One benefit of this would be that we would skip the UDP 
encapsulation altogether, but the benefit is neglectible.

As indicated by the other discussion thread, applying HIP-aware ICE in 
HIP-enabled overlays may have some caveats related to handling of multiple 
overlays. Anyway, there should be a distinction between getting a direct 
connection to the peer (using ICE) vs. routing through the overlay. I 
think this could be implemented e.g. using a socket option.

> With regards to the use of HIP in overlays, the simplest way would be to 
> deploy overlays where all nodes use HIP and overlays where none of the 
> nodes use HIP. However, some people have expressed interest in having 
> mixed overlays where some nodes use HIP while others don't. If people 
> are interested in doing this, we will have to look into ways to 
> negotiate its use within the overlay.
>
> With regards to the use of HIP in overlays, the simplest way would be to 
> deploy overlays where all nodes use HIP and overlays where none of the 
> nodes use HIP. However, some people have expressed interest in having 
> mixed overlays where some nodes use HIP while others don't. If people 
> are interested in doing this, we will have to look into ways to 
> negotiate its use within the overlay.

Regarding to Ali's original suggestion on detecting localhost and peer 
support, I think localhost support would be easy. Connecting to a HIT is 
one way detect it, but it may include a timeout. Other ways are to go 
through the addresses of host using e.g. getaddrinfo() and check if there 
are any ORCHIDs there. Perhaps the quickest way is to create a socket with 
PF_HIP family and check for errors in the return value.

-- 
Miika Komu                                       http://www.iki.fi/miika/

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 8 Jan 2008 17:16:20 -0500

On Dec 23, 2007 4:33 AM, Gonzalo Camarillo
<[email-masked]> wrote:
> Hi Bruce,
>
> thanks for your comments.
>
> Regarding your question about Sections 3.2 and 3.3 when RELOAD is the
> peer protocol and HIP BONE is used for connection management, the idea
> is to use HIP, instead of RELOAD, to perform connection management. All
> the other functions RELOAD typically performs are still performed by RELOAD.
>
> RELOAD defines the CONNECT primitive and the TUNNEL primitive. If HIP is
> being used, you would use the CONNECT primitive of HIP (i.e., an I1
> packet) *instead* of the CONNECT primitive of RELOAD. The same way, you
> would use the TUNNEL primitive of HIP (i.e., a HIP message) *instead* of
> the TUNNEL primitive of RELOAD.

This is where I still get confused, and I think this is a pretty big
architectural issue.  The combination of 3.2, 3.3, and 6 still leave
some questions in my mind as to exactly what is being proposed, so let
me try to form up an example for discussion purposes.

Suppose I have an overlay with the following connections between peers
(labeled with their peerid):

1 ------ 5 ------ 10

So 1 has 5 in its routing table (and thus a direct connection) but not
10.  5 has direct connections to 1 and 10.  I'm assuming recursive
routing and am not being precise with a DHT algorithm for the purposes
of this example.

10 is responsible for a resource, 9, that 1 wants to query for.  In a
non-HIP DHT implementation, 1 sends a query "to" 9.  It looks up for
the closest match in its routing table and discovers it is 5, then it
sends the message to 5.  5 performs a similar lookup and discovers
that its closest match is 10, so it forwards the query to 10.

Going with the HIP-BONE, approach, as I understand the "HIP is IP and
the peer protocol is OSPF" idea, I see two approaches that would meet
that requirement:
- the peer protocol loads enough information into the HIP layer that
the HIP layer on peer 1 knows that the next hop for a message bound
for "9" is 5.  I will refer to this as the hip routing table approach.
- 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 hip routing table approach looks great from a layering
perspective, but implementation looks to be very hard.  Since there
are multiple DHT (and unstructured overlay) algorithms with different
routing rules, there would have to be a pluggable routing algorithm
loaded into the HIP layer by the DHT algorithm or there  needs to be
an upcall from the HIP layer into the peer protocol layer to query for
the next-hop for messages.

In the hip link layer approach, the peer protocol layer knows that the
current set of next-hop candidates are, and it runs the DHT routing
algorithm in the conventional sense, telling the HIP layer what the
next hop for a message is.  This seems like a much simpler approach to
implement, but limits the usefulness of HIP.

So the first question is whether HIP-BONE is intended to specify one
of these approaches, and if so, which one?  I believe it's the hip
routing table approach.

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

Next, how about CONNECT messages.  Suppose that now peer 1 wants to
establish a direct connection to peer 10 for some reason.  Your email
indicates that there will be no CONNECT messages as in RELOAD, but
instead there will only be I1 etc messages.  Let's just assume that
the peer protocol has some way of indicating that it wants to be able
to send messages directly to another peer rather than over the
overlay.  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.  In the hip link layer approach, the peer
protocol would have to insert the I1 into a peer message and forward
it itself.  That would work, but it's a bit cumbersome.

What continues to confuse me, and what I think is the hardest
architectural question here, is how the issue I mentioned above:
"there would have to be a pluggable routing algorithm loaded into the
HIP layer by the DHT algorithm or there  needs to be an upcall from
the HIP layer into the peer protocol layer to query for the next-hop
for messages"
is solved.  Section 6 has quite a few block diagrams, but none of them
seem to help me resolve this issue.  I don't think I see any other
alternatives, but it would be nice to see this specific issue
addressed, because it would make the layering more concrete.

>
> Regarding when to use these primitives, you would use them in the same
> way as defined by RELOAD. That is, when RELOADs tells you to use a
> CONNECT primitive today, you would send an I1 message. When RELOAD tells
> you to use the TUNNEL primitive today, you would use a HIP message as
> well. That is, RELOAD (not HIP BONE) tells you what to do  (i.e., which
> primitive to use) and when to do it.
>
> As you can see, the only modifications to RELOAD in this context is the
> substitution of these two primitives by the HIP equivalent ones.

So I'm not quite sure that this is completely true.  If we let the HIP
layer handle the routing, then RELOAD wouldn't have to handle the
hop-by-hop nature of the recursive forwarding like it does now.  It
doesn't change anything about the majority of the peer protocol
issues, but it does change a bit in how the peer protocol's forwarding
layer (in RELOAD-02's arch diagram) would work.

Bruce

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 9 Jan 2008 09:59:13 -0800

> -----Original Message-----
> From: Bruce Lowekamp [mailto:[email-masked]] 
> Sent: Tuesday, January 08, 2008 2:16 PM
> To: Gonzalo Camarillo
> Cc: Pekka Nikander; P2PSIP Mailing List
> Subject: Re: [P2PSIP] New draft: HIP BONE
> 

> the peer protocol is OSPF" idea...

I think this analogy has some weaknesses, as you have pointed out, in
the "peer protocol is OSPF" part.  My reading of HIP BONE is that the
overall goal is to allow the peer protocol and other applications to
deal with HIP identifiers instead of IP addresses.  That is a worthy
goal IMO which might free RELOAD and other applications from having to
do ICE and handle recursive routing issues or host mobility and
multihoming.

However, the problem with this approach is that HIP needs a naming
service or routing service to resolve identifiers to either locators or
route lists.  This does not exist yet in HIP.  There have been proposals
to use DHTs to provide this service, but they do not presently
accommodate the possibility of multiple DHTs, which is pretty much a
requirement to handle, from my perspective.  HIP BONE seems to be
suggesting that the peer protocol can fill this gap but there appear to
be some issues that need to be worked out, or maybe HIP BONE needs its
own resolution/routing service separate from the application overlay.

Let's presume, for the sake of discussion, that HIP BONE could be made
to work (perhaps not exactly how it is written in the draft, but
somehow), and that it provided an abstraction to the peer protocol layer
and other applications that every node was reachable within a single
Internet; i.e., that each node had a single, globally scoped, unchanging
IP address, that there was a routing service that made each IP address
reachable from any other, and that there were no NATs.  Let's also
presume that HIP BONE was co-deployed with the peer protocol deployment;
that HIP was guaranteed to be available wherever the peer protocol was
deployed.

Question (for P2PSIP):  Is that a useful goal, for HIP to try to provide
the above abstraction, and to try to work out the rest of the details to
realize that service?  Or would there be other considerations that still
make this an unattractive abstraction to P2PSIP?  For instance, are
there reasons that nodes would want to know more details about the
underlying IP addresses associated with peer nodes, and wouldn't want
those details hidden?

Question:  How would RELOAD or other proposals change if that were the
case?  Would the benefits greatly outweigh any drawbacks to this
abstraction?

Tom

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 9 Jan 2008 16:28:22 -0500

> own resolution/routing service separate from the application overlay.

I think this is hitting on the key issue.  A p2p overlay is
fundamentally about routing.  It already has its own ID/locator
mechanism.  Trying to separate the routing and resource querying
aspects is going to be difficult.  Rather than try, I think it's best
to take advantage of the connections.  The peer protocol provides a
component that can answer routing questions for the HIP layer.  The
HIP layer provides the traversal/connection opening functionality, a
link layer capability, and delivers to applications the ability to
transparently use end-to-end connections while being unaware of the
details.

I don't think that having HIP BONE have a separate resolution/routing
service from the application overlay would help.  I'm not even sure
what that would mean, given the relationship between overlay routing
and resource storage.

> case?  Would the benefits greatly outweigh any drawbacks to this

In the RELOAD-02 architecture, what you would presumably do would be
to replace the bottom two layers (Forwarding Layer and Transport
Layer) with HIP.  The routing queries are merely an upcall between
layers.

This is just one possibility, but it is reasonably clean, and it
should be easy to clarify what functions the HIP layers are providing
when they're used, compared to when non-HIP forwarding and transport
layers are used.

Bruce

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 9 Jan 2008 13:45:48 -0800

Bruce,

>Layer) with HIP.  The routing queries are merely an upcall between

What you describe seems very solid and may be applicable to other P2PSIP
proposals as well.

Would you have time to elaborate in a little write-up and add a diagram
for the RELOAD case?
It could but need not be an I-D at this point.

Henry

-----Original Message-----
From: Bruce Lowekamp [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2008 3:28 PM
To: Henderson, Thomas R
Cc: Pekka Nikander; P2PSIP Mailing List
Subject: Re: [P2PSIP] New draft: HIP BONE

Bruce

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 09 Jan 2008 16:24:19 -0600

Hi, Thomas,

I'm not sure I'm entirely in sync with the conversation, but when I was
speed-reading HIP BONE over the Christmas break, I saw the following text, 
which seems to say that P2P comes first, because the overlay is used to 
route I1 packets. ("HIP over P2P")

My understanding of HIPHOP was that HIP came first, because it was used to 
forward P2P packets without "popping up" to a P2P protocol engine at every 
hop. ("P2P over HIP")

If I am misrepresenting either of these proposals, I apologize.

If I am not, I am confused, and think that this is one of the key design 
decisions we need to discuss before moving forward with a P2P/HIP proposal, 
which I hope we do, by the way.

Thanks,

Spencer

>From draft-camarillo-hip-bone-00.txt:

3.2.  Connection Establishment

   Nodes in an overlay need to establish connection with other nodes in
   different cases.  For example, a node typically has connections to
   the nodes in its finger table.  Nodes also need to establish
   connections with other nodes in order to exchange application-layer
   messages.

   As discussed earlier, HIP uses the base exchange to establish
   connections.  Therefore, a node uses an I1 packet to establish a
   connection with another node in the overlay.  Nodes in the overlay
   forward I1 packets in a hop-by-hop fashion according to the overlay's
   routing table towards its destination.  If the overlay nodes have
   active connections with other nodes in their finger tables and if
   those connections are protected (typically with IPsec ESP), I1
   packets may be sent over protected connections between nodes.
   Alternatively, if there no such an active connection but the sending
   peer node has a valid locator for the next hop, the I1 packets may be
   forwarded directly, in a similar fashion to how I1 packets are today
   forwarded by the HIP RVS service.

   Since HIP supports NAT traversal, a HIP base exchange over the
   overlay will perform an ICE offer/answer exchange between the nodes
   that are establishing the connection.  In order to perform this
   exchange, the nodes need to first gather candidate addresses.  Which
   nodes can be used to obtain reflexive address candidates and which
   ones can be used to obtain relayed candidates is defined by the peer
   protocol.

3.3.  Lightweight Message Exchanges

   In some cases, nodes need to perform a lightweight query to another
   node.  In this situation, establishing a connection using the
   mechanisms in Section 3.2 for a simple query would be an overkill.  A
   better solution is to forward a HIP message through the overlay with
   the query and another one with the response to the query.  The
   payload of such HIP packet is integrity protected.  Nodes in the
   overlay forward this HIP packet in a hop-by-hop fashion according to
   the overlay's routing table towards its destination, typically
   through the protected connections established between them.

---

From: Ali Fessi <[email-masked]>
Date: Thu, 10 Jan 2008 00:19:11 +0100

maybe the best way to understand the inter-working between HIP and P2P 
is to compare it with the inter-working between SIP and P2P.

HIP has the Identifier/Locator separation and SIP has also the 
SIP-URI/Contact-URI seperation.

In both cases, the P2P protocol is used for the overlay maintenance 
(e.g. join and leave).

and usually it is also the P2P protocol that will resolve lookups and be 
responsible for storing data, (i.e. get and put)

So you can use the P2P protocol to resolve a SIP-URI to a Contact-URI 
and perform B2B SIP signaling afterwards.

Simlarly, you can use the P2P protocol to resolve a HIP ORCHID to a 
Locator, and then when you get the Locator start the HIP handshake.

And in fact, this is maybe something confusing in the HIP BONE draft

(many thanks BTW to the authors here. IMHO, the draft clarified many 
things about HIP and its potential use for P2PSIP),

because HIP BONE says that a I1 message is transported hop-by-hop in the 
overlay. I would let the P2P protocol resolve the HIP Identifier to a 
Locator first, and then send the I1 message directly to the HIP Responder.

Cheers,
  Ali

Spencer Dawkins wrote:
> speed-reading HIP BONE over the Christmas break, I saw the following 
> text, which seems to say that P2P comes first, because the overlay is 
> used to route I1 packets. ("HIP over P2P")
> 
> My understanding of HIPHOP was that HIP came first, because it was used 
> to forward P2P packets without "popping up" to a P2P protocol engine at 
> every hop. ("P2P over HIP")
> 
> decisions we need to discuss before moving forward with a P2P/HIP 
> proposal, which I hope we do, by the way.
> 
> Thanks,
> 
> Spencer
> 

-- 
Ali Fessi
Computer Networks and Internet
University of Tuebingen, Germany
Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220
EMail: [email-masked]
Web: http://net.informatik.uni-tuebingen.de/~fessi/

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 9 Jan 2008 16:37:20 -0800

> From: Spencer Dawkins [mailto:[email-masked]] 
> Sent: Wednesday, January 09, 2008 2:24 PM
> To: Henderson, Thomas R

Spencer,

Maybe the authors can clarify.  I agree that the text you quote suggests
that difference.  OTOH, there is Figure 5 that suggests that it is
mainly peer protocols over HIP (although I don't know whether the fact
that peer protocols "overhang" the data transport has any significance
in that diagram), and I thought that Gonzalo remarked during the Boeing
call that HIP BONE and HIP HOP were basically the same.  

quoting from the draft:

   The HIP BONE allows quite a lot of flexibility how to arrange the
   different protocols in detail.  Figure 5 shows one potential stack
   structure.

      +-----------------------+--------------+
      | peer protocols        |     media    |
      +------------------+----+--------------+
      | HIP signalling   |   data transport  |
      |                                      |
      +------------------+-------------------+
      | NAT    | non-NAT |                   |
      |                  |                   |
      |      IPv4        |       IPv6        |
      +------------------+-------------------+

                Figure 5: Example HIP BONE stack structure

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 10 Jan 2008 10:17:37 +0200

Hi Bruce,

On Dec 23, 2007 4:33 AM, Gonzalo Camarillo  
<[email-masked]> wrote:
>> Regarding your question about Sections 3.2 and 3.3 when RELOAD is  
>> the peer protocol and HIP BONE is used for connection management,  
>> the idea is to use HIP, instead of RELOAD, to perform connection  
>> management. All the other functions RELOAD typically performs are  
>> still performed by RELOAD.
>>
>> RELOAD defines the CONNECT primitive and the TUNNEL primitive. If  
>> HIP is being used, you would use the CONNECT primitive of HIP  
>> (i.e., an I1 packet) *instead* of the CONNECT primitive of RELOAD.  
>> The same way, you would use the TUNNEL primitive of HIP (i.e., a  
>> HIP message) *instead* of the TUNNEL primitive of RELOAD.

On 9 Jan 2008, at 00:16, Bruce Lowekamp wrote:
>
> This is where I still get confused, and I think this is a pretty  
> big architectural issue.  The combination of 3.2, 3.3, and 6 still  
> leave some questions in my mind as to exactly what is being  
> proposed, so let me try to form up an example for discussion purposes.

Briefly, what I had in mind when writing the HIP BONE draft was your  
"HIP routing table" approach below.  While I agree with you that at  
the architectural level the question is relatively big, I think that  
when you go to the implementation level the actual difference between  
the "HIP routing table" and "HIP link layer" approaches will be quite  
small.  The key issue here is whether it is possible to divide the  
work between a "routing table" and a "forwarding table".  I don't  
know the proposed peer protocols well enough to be able to answer  
that question.  If it indeed is possible to make such a division,  
then I think the difference between "HIP routing table" and "HIP link  
layer" almost disappears.  Otherwise the situation gets hairier, as  
you apparently suggest below.

But let's have a look at your example:
> Suppose I have an overlay with the following connections between  
> peers (labeled with their peerid):
>
> 1 ------ 5 ------ 10
>
> So 1 has 5 in its routing table (and thus a direct connection) but  
> not 10.  5 has direct connections to 1 and 10.  I'm assuming  
> recursive routing and am not being precise with a DHT algorithm for  
> the purposes of this example.
>
> 10 is responsible for a resource, 9, that 1 wants to query for.  In  
> a non-HIP DHT implementation, 1 sends a query "to" 9.  It looks up  
> for the closest match in its routing table and discovers it is 5,  
> then it sends the message to 5.  5 performs a similar lookup and  
> discovers that its closest match is 10, so it forwards the query to  
> 10.
>
> Going with the HIP-BONE, approach, as I understand the "HIP is IP  
> and the peer protocol is OSPF" idea, I see two approaches that  
> would meet that requirement:
>
> - the peer protocol loads enough information into the HIP layer  
> that the HIP layer on peer 1 knows that the next hop for a message  
> bound for "9" is 5.  I will refer to this as the hip routing table  
> approach.

In this approach I would call the "information loaded into the HIP  
layer" as the forwarding table.

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

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

> Since there are multiple DHT (and unstructured overlay) algorithms  
> with different routing rules, there would have to be a pluggable  
> routing algorithm loaded into the HIP layer by the DHT algorithm or  
> there  needs to be
> an upcall from the HIP layer into the peer protocol layer to query  
> for the next-hop for messages.

So, you do seem to be saying that it is impossible to process the DHT- 
layer routing information into a consistent forwarding table format  
that can be used by a single look-up algorithm.  Now, I have to  
confess that I don't understand this argument at all.  Given that for  
each packet the forwarding decision has to eventually be made, the  
time complexity of computing a forwarding decision must be manageable  
(sub-linear w.r.t the number of nodes in the overlay).  Hence, are  
you saying that there is no reasonable representation of the  
forwarding table, i.e., that the space complexity will be  
overwhelming?  But then I don't understand either, as my  
understanding is that with e.g. Bloom filters you can represent an  
random collection of sets with in a relatively small space.  [In the  
case of Bloom filters we of course have the question of false  
positives, but I cannot see a big problem if some packets get briefly  
duplicated on the overlay.  Intuitively, That doesn't seem to add  
much to the already pretty high inefficiency of the overlay.]

> In the hip link layer approach, the peer protocol layer knows that  
> the current set of next-hop candidates are, and it runs the DHT  
> routing algorithm in the conventional sense, telling the HIP layer  
> what the next hop for a message is.  This seems like a much simpler  
> approach to implement, but limits the usefulness of HIP.

I agree with you that this would limit the usefulness of HIP.   
However, if there is a forwarding table, then the practical level  
difference between the "HIP routing table" and "HIP link layer" boils  
down to on which layer you store the forwarding table.

> So the first question is whether HIP-BONE is intended to specify  
> one of these approaches, and if so, which one?  I believe it's the  
> hip routing table approach.

Well, at the time of writing I couldn't see such a difference.   
Hence, perhaps the "right" answer to this question is "neither".   
Instead, while HIP BONE in its current form doesn't specify either of  
the approaches, it alludes towards a "third" approach, i.e., towards  
separating the routing and forwarding tables, which makes the  
implementation-level difference very small.  Hence, from that point  
of view, HIP BONE would allow either architectural choice.

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

> establish a direct connection to peer 10 for some reason.  Your  
> email indicates that there will be no CONNECT messages as in  
> RELOAD, but instead there will only be I1 etc messages.  Let's just  
> assume that the peer protocol has some way of indicating that it  
> wants to be able to send messages directly to another peer rather  
> than over the overlay.

I'm following so far.

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

> In the hip link layer approach, the peer protocol would have to  
> insert the I1 into a peer message and forward

Again, I don't understand.  Why would the peer protocol need to  
insert I1 into a peer message?

> "there would have to be a pluggable routing algorithm loaded into  
> the HIP layer by the DHT algorithm or there  needs to be an upcall  
> from the HIP layer into the peer protocol layer to query for the  
> next-hopfor messages" is solved.

As I indicated above, my idea was to separate the routing table and  
forwarding table.  Right now I cannot see why it would not work, but  
maybe I'm just ignorant about the various overlay routing protocols.

<snipping the rest>

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 10 Jan 2008 14:40:09 +0200

Tom,

>> and the peer protocol is OSPF" idea...
>
> I think this analogy has some weaknesses, as you have pointed out,  
> in the "peer protocol is OSPF" part.  My reading of HIP BONE is  
> that the overall goal is to allow the peer protocol and other  
> applications to deal with HIP identifiers instead of IP addresses.

Yes and no.  The goal certainly is that there may be some (or even  
most) applications that use the HIP identifiers directly.  However,  
for the peer protocols and maybe also some applications it may make  
more sense to use other kinds of identifiers.  That's why we made the  
distinction between Peer IDs and HIP identities in Section 3.1.

> That is a worthy goal IMO which might free RELOAD and other  
> applications from having to do ICE and handle recursive routing  
> issues or host mobility and multihoming.

That is certainly part of our goal.

> service or routing service to resolve identifiers to either  
> locators or route lists.  This does not exist yet in HIP.

Right.  I agree.

> There have been proposals to use DHTs to provide this service, but  
> they do not presently accommodate the possibility of multiple DHTs,  
> which is pretty much a requirement to handle, from my perspective.

That issue Gonzalo and I have discussed extensively.  On my part I  
still don't quite understand the requirement (as is probably visible  
from the previous exchange of message between you Tom and me).   
However, for example, one possibility here would be that the routing  
tables could contain PeerIDs (distinct from HIP identifiers) while  
the forwarding tables would contain HIP identifiers.  However, of  
course, whether that would work in a scalable manner depends on many  
details that haven't really been figure out yet.  For example, in  
such an approach it might be necessary to define a new HIP parameter  
(or reuse the existing HOST_ID parameter) to carry the PeerID when  
routing HIP packets through the overlay.

> HIP BONE seems to be suggesting that the peer protocol can fill  
> this gap ...

Exactly.

> ... but there appear to be some issues that need to be worked out,  
> or maybe HIP BONE needs its own resolution/routing service separate  
> from the application overlay.

There are certainly many things that need to be worked out in order  
to make HIP BONE practical.  The present draft was more meant to  
provide an overall map of some territory rather than providing detail  
instructions on how to get to the goal.  But, from the HIP BONE point  
of view, it would not make sense to make the peer protocol and a  
resolution or routing service separate.  Ideally, HIP BONE would  
support both P2PSIP based peer protocols and other, unrelated overlay  
or identity routing protocols, perhaps something similar to Berkeley  
DONA.

<snip>

> Question (for P2PSIP):  ...

I think your questions are very good, but since I am not really a  
member of the P2PSIP community, I don't feel myself able to answer to  
those.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 10 Jan 2008 14:45:15 +0200

Hi Ali,

On 10 Jan 2008, at 01:19, Ali Fessi wrote:
<snip>
> And in fact, this is maybe something confusing in the HIP BONE  
> draft [...] because HIP BONE says that a I1 message is transported  
> hop-by-hop in the overlay. I would let the P2P protocol resolve the  
> HIP Identifier to a Locator first, and then send the I1 message  
> directly to the HIP Responder.

That has been tried and there is even a prototype working on  
PlanetLab using OpenDHT, but unfortunately there appears to be two  
problems.  First, OpenDHT latencies appear to be too long and  
unpredictable, sometimes minutes and often exceeding 10 seconds.  But  
that may be an implementation problem that can be fixed.  The second,  
bigger problem is that if both the initiator and the responder are  
behind NATs, the you just cannot send the I1 message directly to the  
HIP responder.

The latter is the reason why we chose to use a Berkeley i3 -like  
system in both Hi3 and in HIP BONE, i.e., to forward HIP messages  
through the overlay instead of using it in a typical DHT put/get manner.

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 10 Jan 2008 14:49:20 +0200

Spencer and Tom,

>> I'm not sure I'm entirely in sync with the conversation, but when  
>> I was speed-reading HIP BONE over the Christmas break, I saw the  
>> following text, which seems to say that P2P comes first, because  
>> the overlay is used to route I1 packets. ("HIP over P2P")

I think your confusion here is mixing the "overlay" and the "peer  
protocol".  In HIP BONE case the overlay is formed by combining HIP  
and the peer protocol.  Hence, while HIP packets can be routed over  
the overlay, that does not mean that they are routed over the peer  
protocol.

>> My understanding of HIPHOP was that HIP came first, because it was  
>> used to forward P2P packets without "popping up" to a P2P protocol  
>> engine at every hop. ("P2P over HIP")

Perhaps a key issue in understanding this is the separation of the  
routing table and the forwarding table; see my previous message  
earlier today.

> Maybe the authors can clarify.  I agree that the text you quote  
> suggests that difference.  OTOH, there is Figure 5 that suggests  
> that it is mainly peer protocols over HIP

Yes.

> (although I don't know whether the fact that peer protocols  
> "overhang" the data transport has any significance in that diagram),

Yes it does.  It means that you can use either existing HIP  
associations (data transport) for transporting peer protocol packets  
between nodes (Section 3.2), or you may piggyback them in HIP  
signalling messages (Section 3.3).

<snip>

--Pekka Nikander

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 10 Jan 2008 11:19:39 -0500

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

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

> 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

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 10 Jan 2008 13:25:06 -0800

Pekka, thanks for your responses (some more discussion inline below) 

> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Thursday, January 10, 2008 4:40 AM
> To: Henderson, Thomas R
> Cc: Bruce Lowekamp; Gonzalo Camarillo; P2PSIP Mailing List

Yes, but I believe that you are saying in section 3.1 that those other
identifiers are turned into ORCHIDs for use in HIP.  That was the point
I was trying to make.

> from the previous exchange of message between you Tom and me). 

For a given system provided by a provider (example.com), only one
overlay is necessary.  But what happens when the user concurrently gets
a second provider (example2.com)?  The problem is that the layer trying
to resolve the flat identifier doesn't know where to try to resolve it,
unless there is metadata about the system that holds bindings for that
identifier.  What happens when the user wants to enforce policy on what
applications use which overlay, at any given time, to resolve the
identifiers?

The Balakrishan et. al paper in Sigcomm 2004 (Section 4.1) elaborated on
why multiple name service providers will proliferate in an architecture
based on flat names:
http://nms.lcs.mit.edu/papers/layerednames-sigcomm04.pdf

I do not think it is a show stopper issue, but one that HIP hasn't
addressed yet.  
  
> or identity routing protocols, perhaps something similar to Berkeley  

The difficulty I have (also with the OSPF analogy) is that it seems
necessary to avoid circular dependencies.  OSPF and IS-IS build IP
forwarding tables but, in so doing, they do not use those IP forwarding
tables, because that would be a circular dependency.  If you say that
peer protocol and resolution and routing service are combined, then it
seems to me that you are saying in HIP BONE that the peer protocol is
both a user of HIP (in some contexts) and an enabler of HIP (such as
overlay-routing the HIP messages). 

If HIP provides connection managment, and the peer protocol provides
data storage and retrieval, and peer protocol uses HIP for its
connections, and HIP uses the peer protocol for data storage, there seem
to be some circular dependencies.  Or does HIP only apply to the media
stream connections?

I'm led to assume that, in the model you're describing, the peer
protocol has to operate in the absence of HIP (and must implement ICE);
i.e., data storage and retrieval is necessary to bootstrap HIP, and
therefore the connections used to implement data storage and retrieval
do not run over HIP.  Is that correct, or am I missing something? 

- Tom

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 10 Jan 2008 17:14:56 -0500

One of the issues I don't understand about this discussion is whether  
all instances of P2PSIP would be expected to be running HIP or just  
some. There seem to be at least three options:

(1) Mandatory to implement and run

The only non-recursive-dependency model seems to be that peer nodes  
would store the HIT-IP bindings in their routing tables. (This largely  
negates any mobility advantages, but that's a separate discussion.)

(2) Mandatory to implement, but there can be instances of an overlay  
(or maybe even part of an overlay) that don't use HIP

This would require providing ICE functionality at both the HIP level  
and directly to the P2P protocol.

(3) Optional to implement and run

This only works if you can have mixed HIP-non-HIP nodes. Also requires  
implementations of ICE in both layers and the ability to mix-and-match  
HIP and non-HIP nodes within an overlay, unless each overlay has a  
"HIP flag".

I admit that I'm rather worried about the complexity of this whole  
edifice. I think it would be helpful if the proponents of a HIP-based  
approach stated clearly which of these they have in mind.

Henning

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 10 Jan 2008 16:41:28 -0600

Hi, Bruce,

From: "Bruce Lowekamp" <[email-masked]>

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

> nats isn't a problem as long as the ice message exchanges are carried

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

Thanks,

Spencer

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 10 Jan 2008 16:54:37 -0600

Hi, Pekka,

I wanted to thank you for this explanation. It's helpful in understanding 
what other people mean by what they're saying.

Spencer

From: "Pekka Nikander" <[email-masked]>

> protocol".  In HIP BONE case the overlay is formed by combining HIP  and 
> the peer protocol.  Hence, while HIP packets can be routed over  the 
> overlay, that does not mean that they are routed over the peer  protocol.
>
> routing table and the forwarding table; see my previous message  earlier 
> today.

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 10 Jan 2008 16:56:10 -0600

[Spencer] Yes, exactly. I'm not sure that we DON'T have circular 
dependencies yet. I'm still trying to understand whether the peer protocol 
is a user of HIP or an enabler of HIP.

Thanks,

Spencer

From: "Henderson, Thomas R" <[email-masked]>

- Tom

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 10 Jan 2008 18:05:34 -0500

Henning,

I think it can done in a modular way that will make it possible for it
to be optional to implement and run.  Then vendors and deployments can
decide whether they want to use it or not.

I'm not entirely convinced that HIP is the right solution, but I'm
interested enough in it that I think it will be cool to play with and
see how well it works.  That to me says it should be an optional
component. If it's successful, obviously it will be more widely
adopted.

Bruce

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 10 Jan 2008 18:15:35 -0500

If it's optional, would it mean that the upper layer has to be aware  
of its existence, possibly re-running ICE on ORCHIDs?

Can we envision hybrid HIP-non HIP overlays?

Again, I'm rather worried about the complexity of this whole effort. I  
think one reasonable criterion of going forward is that those who are  
*not* interested in using HIP shouldn't have to pay for it, in terms  
of implementation costs, interoperability or performance.

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 10 Jan 2008 18:18:28 -0500

> of its existence, possibly re-running ICE on ORCHIDs?

I think it may mean that the upper layer (other applications) need to
be aware they don't have to run ICE, at least for efficiency (they
could do it).

> of implementation costs, interoperability or performance.

I fully agree.  It only makes sense if it's actually a separable module.

Bruce

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 10 Jan 2008 18:03:14 -0800

On Jan 10, 2008, at 2:14 PM, Henning Schulzrinne wrote:

> One of the issues I don't understand about this discussion is  
> whether all instances of P2PSIP would be expected to be running HIP  
> or just some. There seem to be at least three options:
>
> would store the HIT-IP bindings in their routing tables. (This  
> largely negates any mobility advantages, but that's a separate  
> discussion.)
>
> (2) Mandatory to implement, but there can be instances of an  
> overlay (or maybe even part of an overlay) that don't use HIP
>
> This would require providing ICE functionality at both the HIP  
> level and directly to the P2P protocol.
>
> This only works if you can have mixed HIP-non-HIP nodes. Also  
> requires implementations of ICE in both layers and the ability to  
> mix-and-match HIP and non-HIP nodes within an overlay, unless each  
> overlay has a "HIP flag".
>
> edifice. I think it would be helpful if the proponents of a HIP- 
> based approach stated clearly which of these they have in mind.
>
> Henning
>

I was assuming most folks were talking about (3) given that much of  
HIP is still being designed and it will be awhile to get things build  
and deployed. I know lots of parts of HIP have been done but when we  
are talking about mobility, nat traversal, no DNS, and easy end user  
installations, there is still work. Anyway, I am in the 3 category.

Cullen <with my individual hat on>

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 10 Jan 2008 21:29:22 -0600

Hi, Cullen and Henning,

I guess today is a good day for me to be confused.

I thought I understood "optional to implement, optional to run", and I 
understood Cullen's reasons stated below, but I'm very confused about why 
"this only works if you can have mixed HIP-non-HIP" ...

... and that's probably because I'm not quite sure what "mixed HIP-non-HIP" 
means.

Are you talking about

a - mixed within P2PSIP technology, so that some overlays use HIP and others 
do not?

b - mixed within the same endpoint, that can join a HIP overlay and a 
non-HIP overlay?

c - mixed within the same overlay, so some peers use HIP and others do not?

I'll stop talking now ...

Spencer

From: "Cullen Jennings" <[email-masked]>

>> (2) Mandatory to implement, but there can be instances of an  overlay (or 
>> maybe even part of an overlay) that don't use HIP
>>
>> This would require providing ICE functionality at both the HIP  level and 
>> directly to the P2P protocol.
>>
>> HIP and non-HIP nodes within an overlay, unless each  overlay has a "HIP 
>> flag".
>>
>> edifice. I think it would be helpful if the proponents of a HIP- based 
> I was assuming most folks were talking about (3) given that much of  HIP 
> is still being designed and it will be awhile to get things build  and 
> deployed. I know lots of parts of HIP have been done but when we  are 
> talking about mobility, nat traversal, no DNS, and easy end user

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 10 Jan 2008 22:52:38 -0500

I'm assuming that the goal is that a P2PSIP-compliant application will  
be able to participate in any P2PSIP-compliant overlay, subject to  
having code for the DHT  the overlay is running. Thus, this means that  
non-HIP peers must be able to be full peers. Unless the arrival of a  
single non-HIP peer converts the whole overlay to non-HIP usage, this  
also implies that all nodes must be able to deal with non-HIP peers,  
even if they prefer to speak HIP. Among other things, they'll probably  
have to implement ICE and TLS.

Thus, it's something like (b) and (c).

Henning

On Jan 10, 2008, at 10:29 PM, Spencer Dawkins wrote:

> I thought I understood "optional to implement, optional to run", and  
> I understood Cullen's reasons stated below, but I'm very confused  
> about why "this only works if you can have mixed HIP-non-HIP" ...
>
> ... and that's probably because I'm not quite sure what "mixed HIP- 
> non-HIP" means.
>
> Are you talking about
>
> a - mixed within P2PSIP technology, so that some overlays use HIP  
> and others do not?
>
> b - mixed within the same endpoint, that can join a HIP overlay and  
> a non-HIP overlay?
>

---

From: David Barrett <[email-masked]>
Date: Fri, 11 Jan 2008 09:53:59 +0530

We don't need more options for what we CAN do, we need decisions on  
what we WILL do.  If we're not considering making HIP mandatory, then  
let's stop talking about it and start focusing on those things that  
*will* be mandatory.

That said, I think this HIP discussion is the best thing to happen in  
P2PSIP for years.  It seems like the most practical and powerful  
solution, the best layering of functionality, and the most feasible  
design that I've yet to hear.  Moving the hard P2P code into a  
reusable HIP layer makes a lot of sense, not only for P2PSIP, but for  
the internet as a whole.  It seems like a wagon that we should  
voluntarily and enthusiastically hitch ourselves to, rather than try  
to reproduce or compete with it, or toss it in the overflowing bucket  
of optional extensions.

It seems sensible to have a base HIP layer that either comes pre- 
installed with the OS or redistributed by the application (similar to  
WinPCap).  (I could even see making a sort of "HIP-lite" self- 
contained library that can be linked straight into the application for  
when installing a   Then P2PSIP can be one of many HIP-using  
applications that are vastly simplified by being insulated from the  
gnarly realities of NAT and firewall penetration, mobility, etc.

This makes a lot more sense than continually reproducing this really  
hard functionality in every application.

-david

On Jan 11, 2008, at 7:33 AM, Cullen Jennings wrote:

> HIP is still being designed and it will be awhile to get things  
> build and deployed. I know lots of parts of HIP have been done but  
> when we are talking about mobility, nat traversal, no DNS, and easy  
> end user installations, there is still work. Anyway, I am in the 3  
> category.
>

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 11 Jan 2008 09:45:18 +0200

In the case of HIP BONE, the peer (or routing) protocol is both a  
user of HIP and an enable of HIP.  But so are the routing protocols  
for IP, and in certain sense DNS for IP, too.

Such a circular dependency in itself is not bad, as long as it is  
designed (i.e. not accidental) and we have a clear understanding how  
to manage the bootstrap problem.

In this case, the bootstrap may take place, for example, in the form  
of direct HIP connections (no overlay routing).  That is, if that  
approach is taken, when a node joins to an overlay, it looks up the  
HIT and IP address of some host within the overlay (e.g. using DNS,  
local service discovery, or manual configuration), creates an HIP  
association, and runs the peer protocol join over the HIP association.

--Pekka

On 11 Jan 2008, at 00:56, Spencer Dawkins wrote:

> dependencies yet. I'm still trying to understand whether the peer  
> protocol is a user of HIP or an enabler of HIP.
>
> Thanks,
>
> Spencer
>

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 11 Jan 2008 08:20:33 -0600

OK, I'm not the architecture monitor, but I disagree with some of this, and 
agree with the rest...

> In the case of HIP BONE, the peer (or routing) protocol is both a  user of 
> HIP and an enable of HIP.  But so are the routing protocols  for IP, and 
> in certain sense DNS for IP, too.

OSPF does use IP *encapsulation*, *fragmentation/reassembly*, etc. but OSPF 
conversations happen with direct adjacencies. Using IP *encapsulation* is 
very different from using *IP*.

IS-IS runs directly over link-layer protocols ("same level as CLNS").

DNS looks like a IP enabler to applications that are trying to use DNS 
names, but it's not - IP ran for years before there was a naming system at 
all (see HOSTS.TXT).

> designed (i.e. not accidental) and we have a clear understanding how  to 
> manage the bootstrap problem.

I would agree with both points here - design and understanding are what's 
needed, and being able to bootstrap would be the first test that we have a 
design and understanding.

Thanks,

Spencer

---

From: "David A. Bryan" <[email-masked]>
Date: Fri, 11 Jan 2008 10:10:28 -0500

Hmmm...(b) and (c) doesn't make sense to me, unless I'm missing
something. After reading Spencer's email, (a) and (b) make more sense
to me.

I agree with Cullen that HIP should me optional both to implement and
run. That means that many overlays may simply not support it all, and
others may use it exclusively, giving us the (a) scenario. A
particular endpoint may choose to implement both, allowing it join
both types of overlays, which is (b).

(c) makes little sense to me operationally, although I guess I can see
how it could be done technically if there are some (b) type peers that
are effectively relays. It would make for some really odd DHTs,
however, since you might have to route calls via the adaptors, and I'm
not sure it really gains you anything.

In my mind, this would be a capabilities negotiation issue. Although
the mechanics of how you do it might differ a good bit, logically it
might be good to think about it like offer-answer in SIP. If I start
an overlay, I'm free to choose the DHT and if it is SIP or not. If, on
the other hand a few peers were negotiating among themselves, they
could compare capabilities (DHTs, HIP or not, security model, etc.)
and choose the best. I don't think we have a "One ring to rule them
all..." thing going on where every single peer is in a global overlay,
although there could be some (very) large and essentially public
rings. There will be rings with different choices on DHT/transport,
and that decision may limit who can join that particular ring.

So I guess since we are all picking numbers here, I am the (3)(a and
b) camp. I might just not have my head around (c), however...anyone
care to take a stab at explaining how it actually works?

David (as individual)

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 11 Jan 2008 09:38:28 -0600

Hi, David,

I think you're right about the !("one ring to rule them all") part.

After re-reading Henning's email down to the part that said

>> Unless the arrival of a

I think we're discussing an application scenarios question.

If you can bridge two overlays, you don't need to convert to non-HIP when a 
non-HIP peer tries to join - just bootstrap a non-HIP overlay and bridge.

If that's not possible, then you need to figure out what to do when a 
non-HIP peer joins.

If the expected application is amateur video sharing, you can probably fail 
the join request and tell someone to upgrade (this is what happens when I 
try to connect to AIM with an old client, right?). That's a lot simpler than 
anything else.

If the expected application is first-responder ad-hoc, you probably 
shouldn't fail the request...

Thanks,

Spencer

---

From: "David A. Bryan" <[email-masked]>
Date: Fri, 11 Jan 2008 10:50:38 -0500

I think I pretty much agree with you hear. If (c) is implemented as
two overlays bridged together, I'm much more comfortable with that,
but one overlay where messages between some peers are HIP and some are
not seems a bit more architecturally brittle to me, especially if some
peers can only speak one or the other. (then again, we can have mixed
TCP/UDP hops in SIP, but I am not sure that is a good thing) If (c) is
bridging, it can effectively work the same as bridging two overlays
with different DHTs (although the open question is if HIP is used for
the bridge then ;) )

David (as individual)

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: "David A. Bryan" <[email-masked]>
Date: Fri, 11 Jan 2008 10:51:06 -0500

Er, I guess I *hear* you and agree with you *here* ;)

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: Ali Fessi <[email-masked]>
Date: Fri, 11 Jan 2008 16:53:18 +0100

Hi Pekka,

On 10 Jan 2008, at 13:45 Pekka Nikander wrote:
>> [...] because HIP BONE says that a I1 message is transported 
> That has been tried and there is even a prototype working on PlanetLab 
> using OpenDHT, but unfortunately there appears to be two problems.  
> First, OpenDHT latencies appear to be too long and unpredictable, 
> sometimes minutes and often exceeding 10 seconds.  But that may be an 
> implementation problem that can be fixed.  

yes indeed, this is a OpenDHT specific problem. (we also had similar 
performance problems when experimenting with P2PSIP on OpenDHT)

> The second, bigger problem is 
> that if both the initiator and the responder are behind NATs, the you 
> just cannot send the I1 message directly to the HIP responder.
> 
> The latter is the reason why we chose to use a Berkeley i3 -like system 
> in both Hi3 and in HIP BONE, i.e., to forward HIP messages through the 
> overlay instead of using it in a typical DHT put/get manner.

i3, Secure-i3 and Hi3 have however an assumption that does not hold 
here. The overlay consitutes of i3 servers which are considered to be 
trustworthy, have public addresses and can converge as rendez-vous 
points for "clients" behind NATs. This assumption does not hold for 
P2PSIP, since there is not such an overlay.

So, when the I1 message is forwarded on the overlay, the NAT traversal 
problem needs to solved for each link on the path between the Initiator 
and the Responder. And this is not solved by HIP, unless you run HIP for 
each link on the overlay (including the HIP handshake and ICE for NAT 
traversal) which would be proably too much overhead.

Moreover, the peer protocol needs to cope with NAT traversal for other 
type of messages for the overlay maintenance, e.g. joins and leaves, 
anyway. and again this is not solved by HIP, unless you do HIP hop-by-hop.

My conslusions from these facts here (please feel free to heavily 
disagree and let me know if i am wrong) would be that:

- *HIP actually does not solve the NAT traversal problem for P2PSIP*, as 
it has been assumed.
- The peer protocol needs to cope with the NAT traversal by itself.

Cheers,
  Ali

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 11 Jan 2008 10:53:51 -0500

This is exactly the situation I want to avoid. We're now creating two  
classes of systems, the HIP-capable ones and the rest. From a consumer  
perspective, somebody buys a "VoIP p2p client" to join any number of  
yet-unkown overlays (otherwise, they could just run Skype) - and then  
find out that they can't join some fraction of overlays because they  
didn't look for an acronym they didn't understand. They can only hope  
that the overlay implements "bridging", likely with the need for a  
central server to perform that function.

This also violates the "no cost" requirement I mentioned. Even if I,  
as an implementor consider HIP a waste of time, I still have to  
implement it.

At least we're now clear that the HIP advocates want to essentially  
force systems to implement it. This will hopefully focus the  
discussion a bit.

Henning

On Jan 11, 2008, at 10:38 AM, Spencer Dawkins wrote:

> If you can bridge two overlays, you don't need to convert to non-HIP  
> when a non-HIP peer tries to join - just bootstrap a non-HIP overlay  
> and bridge.
>
> If that's not possible, then you need to figure out what to do when  
> a non-HIP peer joins.
>
> If the expected application is amateur video sharing, you can  
> probably fail the join request and tell someone to upgrade (this is  
> what happens when I try to connect to AIM with an old client,  
> right?). That's a lot simpler than anything else.
>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 11 Jan 2008 08:38:59 -0800

On Jan 10, 2008, at 8:23 PM, David Barrett wrote:

> what we WILL do.

Yep - agree.  And what I want to do is standardize something that  
lets me build deployable interoperable solutions soon. Success for me  
involves deployments.

>   If we're not considering making HIP mandatory, then let's stop  
> talking about it and start focusing on those things that *will* be  
> mandatory.

The P2PSIP WG has made very few decisions since it was formed. IMHO,  
what we need to do real soon now is pick something as a starting  
point for a WG document then go and make the decision to change it to  
be what we want.  Until we do that, my belief is that the WG will  
make fairly marginal progress.

>
> That said, I think this HIP discussion is the best thing to happen  
> in P2PSIP for years.  It seems like the most practical and powerful  
> reusable HIP layer makes a lot of sense,

this is way outside anything HIP was charted to do or is working on

> not only for P2PSIP, but for the internet as a whole.  It seems  
> like a wagon that we should voluntarily and enthusiastically hitch  
> ourselves to, rather than try to reproduce or compete with it, or  
> toss it in the overflowing bucket of optional extensions.
>
> installed with the OS or redistributed by the application (similar  
> to WinPCap).  (I could even see making a sort of "HIP-lite" self- 
> contained library that can be linked straight into the application  
> for when installing a   Then P2PSIP can be one of many HIP-using  
> This makes a lot more sense than continually reproducing this  
> really hard functionality in every application.

Most of the concrete proposals layer the p2p code such that the  
library that provided the p2p part could be used by other  
applications. This is a good design but not something you need HIP to  
accomplish.

>> I was assuming most folks were talking about (3) given that much  
>> of HIP is still being designed and it will be awhile to get things  
>> when we are talking about mobility, nat traversal, no DNS, and  
>> easy end user installations, there is still work. Anyway, I am in  
>> the 3 category.
>>
>>> whether all instances of P2PSIP would be expected to be running  
>>> HIP or just some. There seem to be at least three options:
>>>
>>> The only non-recursive-dependency model seems to be that peer  
>>> nodes would store the HIT-IP bindings in their routing tables.  
>>> (This largely negates any mobility advantages, but that's a  
>>> separate discussion.)
>>>
>>> mix-and-match HIP and non-HIP nodes within an overlay, unless  
>>> each overlay has a "HIP flag".
>>>
>>> I admit that I'm rather worried about the complexity of this  
>>> whole edifice. I think it would be helpful if the proponents of a  
>>> HIP-based approach stated clearly which of these they have in mind.
>>>
>>> Henning
>>>

---

From: "David A. Bryan" <[email-masked]>
Date: Fri, 11 Jan 2008 11:59:05 -0500

Fully agree with Cullen here as far as the flexibility of the proposed
peer protocols to extend beyond SIP. Ever since the decision was made
(early in the charter process) that while SIP would be the primary
app, we would design the protocol in such a way that it could be
easily reused for other applications, this has been a guiding
principal in all of the "concrete proposals" and I know that all the
various authors/implementors of these things have kept that very much
in mind for at least the last couple of years. I'm quite confident
that the peer protocol can be used for many things besides SIP.

Cullen further points out that much of what you mentioned -- a fully
fleshed out HIP P2P core -- isn't something that is currently
chartered standards-track work for the HIP WG. Building a peer
protocol is in scope for us. We need to make sure that what we deliver
is something that can be used by other applications (including, one
could imagine, HIP), but I don't think we wait for things to emerge
from another group that we are chartered to do!

I want to be clear that I don't think this means we rule out having a
HIP transport, but I think that if we say that we are going to wait
for HIP to provide the complete underlying P2P fabric (peer protocol
and all) that we use, we have things backwards -- that is what we are
chartered here to provide. I also think it will be a long wait, since
that particular work isn't chartered for P2P standards at the moment.
I think deployment is critical here and sooner, rather than later. We
need to be picking a direction and going with it very soon, not
waiting for another group to deliver.

As a completely personal view, I think HIP is interesting, but I think
it is a far longer path (years) to deployment if we make it mandatory.
I want to keep looking at it as it evolves, and I'd love to see us
specify how it would work with a peer protocol as a transport, but I
don't want every P2PSIP app to require HIP.

My 2 cents.

David (as individual)

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Fri, 11 Jan 2008 12:04:09 -0500

If it is so as Cullen has explained, what is the problem to proceed per P2PSIP charter for accomplishing the mandated work items (may be in a limited way) soon which may be ready for deployment?

Cheers!
Radhika

----- Original Message -----
From: Cullen Jennings 
Date: Friday, January 11, 2008 11:40
Subject: Re: [P2PSIP] HIP: optional, mandatory?
To: David Barrett 
Cc: P2PSIP Mailing List 

> Cullen 
> >> Cullen 
> >>> HIP-based approach stated clearly which of these they have in 
> mind.>>>
> >>> Henning

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 12 Jan 2008 15:19:10 +0200

>> The second, bigger problem is that if both the initiator and the  
>> responder are behind NATs, the you just cannot send the I1 message  
>> directly to the HIP responder.
> here. The overlay consitutes of i3 servers which are considered to  
> be trustworthy, have public addresses and can converge as rendez- 
> vous points for "clients" behind NATs. This assumption does not  
> hold for P2PSIP, since there is not such an overlay.

I understand what you say, but I don't understand the reasons behind,  
i.e., why exactly the assumption does not hold.  Nor do I understand  
how you can make such a system to work in the first place.  In  
particular, I don't understand how you can bootstrap an overlay if  
all nodes are behind NATs.

> So, when the I1 message is forwarded on the overlay, the NAT  
> traversal problem needs to solved for each link on the path between  
> the Initiator and the Responder. And this is not solved by HIP,  
> unless you run HIP for each link on the overlay (including the HIP  
> handshake and ICE for NAT traversal) which would be proably too  
> much overhead.

Indeed we do assume that you typically have an open HIP association  
with each of the nodes in your peer table; see the second paragraph  
in Section 3.2.   Note that once you have an HIP association open, in  
principle it can be open an arbitrary long time.  Hence, the overhead  
is not that big unless you have to keep NAT mappings open or  
whatever, which you would need to do anyway for reachability  
purposes.  Secondly, having an open HIP association allows the nodes  
to inform each others about mobility or multi-homing events and  
maintain connectivity.

> Moreover, the peer protocol needs to cope with NAT traversal for  
> other type of messages for the overlay maintenance, e.g. joins and  
> leaves, anyway. and again this is not solved by HIP, unless you do  
> HIP hop-by-hop.

Well, that depends on how you implement joins and leaves.  Our  
assumption was that you would establish an HIP association as a part  
of a join procedure.  For example, first do an I1-R1 exchange for DoS  
protection, and then piggyback the join messages and ICE candidate  
exchange starting from the I2-R2 exchange (and using UPDATEs if more  
messages are needed.)

> - *HIP actually does not solve the NAT traversal problem for  
> P2PSIP*, as it has been assumed.

I would say that it solves it in a particular way, which is not much  
different from using plain ICE.  The message formats are somewhat  
different, and the STUN/TURN servers are unified with the HIP BONE  
routing system (as they would be HIP rendezvous servers in the case  
of HIP).

> - The peer protocol needs to cope with the NAT traversal by itself.

Well, IMHO the peer protocol does not need to cope with NAT, if you  
always establish a HIP association first and let HIP to do it.

Of course, one crucial question is what are the tradeoffs there.  In  
particular, would the added support for security, multi-homing,  
mobility, and the architectural features to pay off for the four  
message exchange and the public key signatures.  OTOH, if you would  
be relying on public key crypto for security anyway, then the  
overhead is minimal, and IMHO the question boils down merely into  
architectural factors.

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 12 Jan 2008 15:29:29 +0200

> OK, I'm not the architecture monitor, but I disagree with some of  
> this, and agree with the rest...

:-)

>> user of HIP and an enable of HIP.  But so are the routing  
>> protocols  for IP, and in certain sense DNS for IP, too.
>
> OSPF does use IP *encapsulation*, *fragmentation/reassembly*, etc.  
> but OSPF conversations happen with direct adjacencies. Using IP  
> *encapsulation* is very different from using *IP*.

Exactly.  And that is very much how HIP would be used in HIP BONE for  
creating connectivity between peer nodes that are adjacent according  
to their finger (or whatever routing) tables.  In that case the peer  
protocol is a user of HIP for encapsulation, security, mobility,  
multi-homing, and NAT traversal, but not for directly forwarding  
signalling messages from one overlay node to another.

In the case of routing initial HIP signalling messages for creating  
direct peer-to-peer connections, HIP is then a user of the peer  
protocol, the peer protocol being an enabler for HIP.

> IS-IS runs directly over link-layer protocols ("same level as CLNS").

I know.  Did you intentionally leave out e.g. BGP which does use both  
IP and also TCP?  :-)

> DNS looks like a IP enabler to applications that are trying to use  
> DNS names, but it's not - IP ran for years before there was a  
> naming system at all (see HOSTS.TXT).
>
>> designed (i.e. not accidental) and we have a clear understanding  
>> how  to manage the bootstrap problem.
>
> I would agree with both points here - design and understanding are  
> what's needed, and being able to bootstrap would be the first test  
> that we have a design and understanding.

I couldn't agree more.  Personally, I don't see any big problems in  
bootstrapping.  The only bigger problems I see are related to  
supporting multiple name spaces aka multiple overlays and allowing  
nodes to participate to a number of them same time.  There I see at  
least three or four approaches, and I have big difficulties in  
understanding the tradeoffs, as I don't understand the requirements  
or scenarios well enough.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 12 Jan 2008 15:51:01 +0200

Tom,

> Pekka, thanks for your responses (some more discussion inline below)

For some reason, I almost enjoy these exchanges.  :-)  Maybe I'm  
finally getting over some of my past painful experiences with the  
I*.  :-)

>>> There have been proposals to use DHTs to provide this service,  
>>> but they do not presently accommodate the possibility of multiple  
>>> DHTs, which is pretty much a requirement to handle, from my  
>>> perspective.
>>
>> still don't quite understand the requirement (as is probably  
>> visible from the previous exchange of message between you Tom and  
>> me).
>
> overlay is necessary.  But what happens when the user concurrently  
> gets a second provider (example2.com)?  The problem is that the  
> layer trying to resolve the flat identifier doesn't know where to  
> try to resolve it, unless there is metadata about the system that  
> holds bindings for that identifier.  What happens when the user  
> wants to enforce policy on what applications use which overlay, at  
> any given time, to resolve the identifiers?

I think there are a few potential solution categories:

a) add such metadata as an overall system configuration data (IPsec  
SPD is an example of this)

b) allow communicating such metadata through the API

c) multicast the initial request to all overlays.

Of course, each of these has their benefits and drawbacks.

> The Balakrishan et. al paper in Sigcomm 2004 (Section 4.1)  
> elaborated on why multiple name service providers will proliferate  
> in an architecture based on flat names: http://nms.lcs.mit.edu/ 
> papers/layerednames-sigcomm04.pdf

That's on my my reading list.  Don't have time to read it in detail  
right now.

> I do not think it is a show stopper issue, but one that HIP hasn't  

We seem to agree.

<The rest of the message was discussed in a separate subthread with  
Spencer, I think.>

--Pekka

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 14 Jan 2008 07:12:22 -0800

Radhika,

> what is the problem to proceed per P2PSIP charter for accomplishing
the mandated > work items (may be in a limited way) soon which may be
ready for deployment?

I presume you share the view that "ready for deployment" means open
available running code and performance reports from actual test
deployments and you don't mean just eloquently written papers?

Henry

-----Original Message-----
From: Roy, Radhika R Dr CTR USA USAMC [mailto:[email-masked]]

Sent: Friday, January 11, 2008 11:04 AM
To: Cullen Jennings
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] HIP: optional, mandatory?

If it is so as Cullen has explained, what is the problem to proceed per
P2PSIP charter for accomplishing the mandated work items (may be in a
limited way) soon which may be ready for deployment?

Cheers!
Radhika

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Mon, 14 Jan 2008 11:12:31 -0500

Henry:

Right, per P2PSIP Charter objectives.

Best regards,
Radhika

----- Original Message -----
From: Henry Sinnreich 
Date: Monday, January 14, 2008 10:13
Subject: RE: [P2PSIP] HIP: optional, mandatory?
To: "Roy, Radhika R Dr CTR USA USAMC" , Cullen Jennings 
Cc: P2PSIP Mailing List 

> > > We don't need more options for what we CAN do, we need 
> decisions 
> > on 
> > > what we WILL do.
> > 
> > lets me build deployable interoperable solutions soon. Success 
> for 
> > me 
> > involves deployments.
> > 
> > > talking about it and start focusing on those things that 
> *will* 
> > be 
> > > mandatory.
> > 
> > point for a WG document then go and make the decision to change 
> it 
> > to 
> > > applications that are vastly simplified by being insulated 
> from 
> > the 
> > applications. This is a good design but not something you need 
> HIP 
> > to 
> > accomplish.
> > 
> > >
> > > -david
> > 
> > Cullen 
> > 
> > >
> > >> build and deployed. I know lots of parts of HIP have been 
> done 
> > but 
> > >> easy end user installations, there is still work. Anyway, I 
> am 
> > in 
> > >> the 3 category.
> > >>
> > >> Cullen 
> > >>> requires implementations of ICE in both layers and the 
> ability 
> > to

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 14 Jan 2008 08:20:06 -0800

Thanks Roy!

This is actually orthogonal to the HIP discussion - it was my omission
to specify.

Henry

-----Original Message-----

Sent: Monday, January 14, 2008 10:13 AM
To: Henry Sinnreich
Cc: Cullen Jennings; P2PSIP Mailing List
Subject: Re: RE: [P2PSIP] HIP: optional, mandatory?

Henry:

Best regards,
Radhika

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 14 Jan 2008 21:26:23 +0200

Hi Henning,

> force systems to implement it. This will hopefully focus the discussion 
> a bit.

not at all. I, for one, do not want to force anyone to implement HIP if 
he or she does not want to.

I agree with you that if you buy a product that supports "IETF P2PSIP" 
and I buy another product that also supports "IETF P2PSIP", they should 
be able to talk to each other... of course, we may find out that our 
boxes do not implement the right DHT, but that is a different story.

Of course, it would be OK for the P2PSIP WG to decide not to use HIP for 
"IETF P2PSIP" applications, if this is what most people want (this is 
what is being discussed). You are also right that, lately, we tend to 
build too complex systems and that we should be aplying the kiss 
principle more often... but I come from a different perspective.

I want to build a HIP-based overlay. If the P2PSIP WG decides that 
P2PSIP should be HIP-free, that's OK. If that was the case, I would run 
other types of applications on top of my HIP-based overlays.

The thing is that, in order to build my HIP-based overlay, I need a peer 
protocol whose functionality is a subset of the functionality provided 
by the peer protocols designed in the P2PSIP WG... therefore, in order 
to avoid reinventing the wheel once more, I would like to use those peer 
protocols for my HIP-based overlay.

Consequently, my requirement on the peer protocol is documented on 
Section 5 of the HIP BONE draft:

        ... the peer protocol
        standardized by the WG is kept functionally and specification
        wise reasonably modular so that the HIP community can use the
        peer protocol minus the connection management and NAT traversal
        modules to experiment with HIP-based overlays.  Note that, at
        present, this is the case with several peer protocols.

I really hope nobody has a problem with this requirement.

With respect to whether or not option 3 (optional to implement and run) 
is actually an option, we can discuss whether or not making HIP optional 
to run for any given node in any given overlay adds too much complexity 
to a system (the capability negotiation mechanism needed for that and 
the stuff that would need to be implemented twice). I personally tend to 
think that the complexity would be relatively high, but some folks do 
not think so.

Cheers,

Gonzalo

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 14 Jan 2008 12:12:40 -0800

>...anyone care to take a stab at explaining how it actually works?

Part of the explanation has just been posted:

http://www.ietf.org/internet-drafts/draft-ahrenholz-hiprg-dht-02.txt 

I understand Gonzalo Camarillo is about to publish an update to the
HIP-BONE I-D.
Let's wait and see if these will explain the issues discussed here.

Henry

-----Original Message-----
From: David A. Bryan [mailto:[email-masked]] 
Sent: Friday, January 11, 2008 9:10 AM
To: Henning Schulzrinne
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] HIP: optional, mandatory?

David (as individual)

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Tue, 15 Jan 2008 14:31:51 -0500

Gonzalo:

Good.

It is what is required for clarifications especially from the author of the draft as follows:

1. P2PSIP WG will develop the peer protocol.
2. The peer protocol will be simple one using KISS principles.

Let us focus on this and finish the development of the peer protocol first.

So, I, personally, want to help and expedite the above item of the WG. Once we have this one ready, the rest are the use cases of the peer protocol. In fact, this is the beauty of the entire process - to proceed step-by-step.

Best regards,
Radhika

PS: 

1. In fact, like you, we have also many more ideas how to solve many other problems using the standard peer protocol. You cannot believe that the emerging MANET networks are hungry for building applications once the peer protocol is standardized. It is a huge area as all applications need to migrate in peer-to-peer communications environments.

2. If the peer protocol development is completed on time by this WG, it will be an enormous help to the industry because a whole new areas for building the p2p-applications will be made open. We are yet to imagine what will be the impact of it in the future. So, let us finish our first task of the WG first as Cullen pointed out.

----- Original Message -----
From: Gonzalo Camarillo 
Date: Monday, January 14, 2008 14:26
Subject: Re: [P2PSIP] HIP: optional, mandatory?
To: Henning Schulzrinne 
Cc: P2PSIP Mailing List 

> discussion 
> peer protocol minus the connection management and NAT 
> traversal modules to experiment with HIP-based overlays. 
> Note that, at

---

From: JiangXingFeng <[email-masked]>
Date: Thu, 17 Jan 2008 15:20:28 +0800

> waiting for another group to deliver.

David, I fully agree with you. HIP has not been widely deployed and NAT
traversal, mobility and multihome are still developing. All in all, HIP is
not mature enough to provide stable service for upper applications. 

On the other hand, the requirements from HIP-BONE as pointed out by Gonzalo
should be considered while designing peer protocol. Fortunately, it is not
hard to be met. Most of the existing proposals have taken modular approach. 

Regards!
JiangXingFeng

---

From: "Oredope, Adetola" <[email-masked]>
Date: Thu, 17 Jan 2008 08:10:05 -0000

Interestingly, I was thinking p2psip is supposed to replace the
centralised systems in conventional SIP with an overlay network. So,
what role does HIP precisely play in achieving this goal? NAT
transversal? What then happens if the firewall decides block these
packets? Am I missing something here? Or is there going to be a future
proposal for conventional SIP to also support HIP?
IMHO, I will suggest that p2psip should be designed in such a way that
it can be easily extended to support any future plugins. At least
conventional SIP has the advantage of being highly extendable. Who ever
though SIP would be used to manage optical networks.

Regards,

Tola

-----Original Message-----
From: JiangXingFeng [mailto:[email-masked]] 
Sent: 17 January 2008 07:20
To: 'David A. Bryan'; 'Cullen Jennings'
Cc: 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] HIP: optional, mandatory?

David, I fully agree with you. HIP has not been widely deployed and NAT
traversal, mobility and multihome are still developing. All in all, HIP
is
not mature enough to provide stable service for upper applications. 

On the other hand, the requirements from HIP-BONE as pointed out by
Gonzalo
should be considered while designing peer protocol. Fortunately, it is
not
hard to be met. Most of the existing proposals have taken modular
approach. 

Regards!
JiangXingFeng

---

From: David Barrett <[email-masked]>
Date: Thu, 17 Jan 2008 15:02:06 +0530

On Jan 11, 2008, at 10:08 PM, Cullen Jennings wrote:
> lets me build deployable interoperable solutions soon. Success for  
> me involves deployments.

100% agree.  That's why I like the HIP layer (whether or not it's  
chartered as I dream):
- P2PSIP builds a decentralized SIP for a fictional "end-to-end"  
internet, and then
- HIP makes that "end-to-end" internet a reality.

This lets us each focus on what we care about, planning to come  
together in the future.  Granted, if they fail, then we're screwed --  
we can't deploy in the real world.  But that's the nature of open  
standards and implementations.  If we don't buy into this ethos and  
instead feel that the only way to do it "right" is to build a custom  
stack from top to bottom, then that doesn't bode well for our faith in  
the IETF.

> point for a WG document then go and make the decision to change it  
> to be what we want.  Until we do that, my belief is that the WG will  

Agreed.  Every call for more extensibility and more support for more  
plugins just puts another nail in the coffin for a practical, real- 
world P2PSIP.  I mean, if we can't get *anything* working, why should  
we expect to get it working *and* extensible?  Let's get it working  
first, and then worry about extensibility.  In my experience, it's far  
easier to extend something that exists than something that doesn't.

> this is way outside anything HIP was charted to do or is working on

Even if that's true, that's not a satisfying answer.  Good design  
should trump IETF charters.  If HIP or P2PSIP needs rechartering, so  
be it.

> applications. This is a good design but not something you need HIP  
> to accomplish.

Agreed, but HIP seems like as good a place as any.

-david

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 17 Jan 2008 09:12:07 -0800

I fully agree with Dave Barrett and would like to illustrate the
pressure to get P2PSIP ASAP to market. For what ti is worth, please look
at 

http://www.spiegel.de/fotostrecke/0,5538,PB64-SUQ9MjY4OTgmbnI9OA_3_3,00.
html 

The note on the right side specifies this statistic is for the consumer
market and enterprise networks may use more SIP based VoIP.
Clicking the "back" links will show more interesting numbers on P2P.

Opinion: This call to urgency can be best met IMHO by using P2PP
implemented on 600 nodes on Planet Lab since it meets the criteria of
running code, open available free code and large footprint deployment.

Thanks, Henry

-----Original Message-----
From: David Barrett [mailto:[email-masked]] 
Sent: Thursday, January 17, 2008 3:32 AM
To: Cullen Jennings
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] HIP: optional, mandatory?

-david

---

From: <[email-masked]>
Date: Fri, 18 Jan 2008 22:31:41 +0200

>Opinion: This call to urgency can be best met IMHO by using 
>P2PP implemented on 600 nodes on Planet Lab since it meets the 
>criteria of running code, open available free code and large 
>footprint deployment.

I fully agree. Besides Nokia's implementation shows that P2PP can also
work on mobile devices. Some of you who visited Nokia's P2PSIP demo
stand in Las Vegas could see a demo of the P2PP implementation on Nokia
phones. At the stand we were showing how a mobile phone that implements
P2PP can join the Columbia Univ.'s 600 nodes overlay on Planet Lab and
allow users to use basic SIP services. The demo was done in colaboration
with Columbia Univ. 
Everyone who whould like to join the P2PP trial network please send an
email to Salman, Henning or me.
 
Our goal is to specify a protocol based on our implementation
experience. It is very easy to write protocol specifications that are
difficult to implement and therefore have high chances to fail in the
market, what we could see in the past. 

Marcin 

>From: ext Henry Sinnreich [mailto:[email-masked]] 
>Sent: 17 January, 2008 19:12
>To: David Barrett; Cullen Jennings
>Cc: P2PSIP Mailing List
>I fully agree with Dave Barrett and would like to illustrate 
>the pressure to get P2PSIP ASAP to market. For what ti is 
>worth, please look at 
>
>The note on the right side specifies this statistic is for the 
>consumer market and enterprise networks may use more SIP based VoIP.
>Opinion: This call to urgency can be best met IMHO by using 
>P2PP implemented on 600 nodes on Planet Lab since it meets the 
>criteria of running code, open available free code and large 
>footprint deployment.
>
>Thanks, Henry
>
>decisions on  
>from the

---

From: Erkki Harjula <[email-masked]>
Date: Mon, 21 Jan 2008 11:58:33 +0200

Hi, we at the University of Oulu are collaborating with Nokia and 
Columbia University with the P2PP prototype. Together with Nokia we are 
implementing a mobile version (works on Nokia's S60 phones) of P2PP 
prototype, which is able to act as both P2PSIP peer and client. We are 
currently working on mobile version's interoperability with fixed 
version of P2PP, aiming to provide full compatibility between them.

Columbia's overlay on PlanetLab provides an excellent testing 
environment for the prototypes. Thus, I also encourage you to join this 
P2PP trial network to increase the node population.

-Erkki

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Mon, 21 Jan 2008 09:12:40 -0500

Inline [RRR]

----- Original Message -----
From: [email-masked]
Date: Friday, January 18, 2008 15:30
Subject: RE: [P2PSIP] HIP: optional, mandatory?
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]

> stand in Las Vegas could see a demo of the P2PP implementation on 
> Nokiaphones. At the stand we were showing how a mobile phone that 
> implementsP2PP can join the Columbia Univ.'s 600 nodes overlay on 
> Planet Lab and
> allow users to use basic SIP services. The demo was done in 
> colaborationwith Columbia Univ. 

[RRR] Yes, you are right. So, please help this P2PSIP WG to complete the spec for the base P2PSIP protocol based on these implementation experiences as soon as possible. We would appreciate this.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 21 Jan 2008 09:49:57 -0800

>we at the University of Oulu are collaborating with Nokia and 

>implementing a mobile version

Is there any chance it may run on my N810 Nokia Tablet at some future
point in time?

Thanks, Henry

-----Original Message-----
From: Erkki Harjula [mailto:[email-masked]] 
Sent: Monday, January 21, 2008 1:59 AM
To: [email-masked]; [email-masked]
Subject: Re: [P2PSIP] HIP: optional, mandatory?

-Erkki

> stand in Las Vegas could see a demo of the P2PP implementation on
Nokia
> allow users to use basic SIP services. The demo was done in
colaboration

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 22 Jan 2008 09:02:43 +0100

> allow users to use basic SIP services. The demo was done in colaboration

Marcin, could you provide some more details about your mobile nodes
joining a 600-peers overlay on PlanetLab?  As far as I know, PlanetLab
is a federated testbed made of very stable public servers; how did you
manage to make mobile devices part of it?  Or were the mobile nodes
participating only as clients, through a XML-RPC-like interface?

-- 
Ciao,
Enrico

---

From: <[email-masked]>
Date: Tue, 22 Jan 2008 12:42:29 +0200

Hi Henry,

There are no major reasons why it should not run. The previous version
of the software was running on N800. 

Erkki: any comments?

Marcin 

>Sent: 21 January, 2008 19:50
>To: Erkki Harjula; Matuszewski Marcin (Nokia-NRC/Helsinki); 
>[email-masked]
>Columbia 
>>University with the P2PP prototype. Together with Nokia we are
>
>Is there any chance it may run on my N810 Nokia Tablet at some 
>future point in time?
>
>Thanks, Henry
>
>Hi, we at the University of Oulu are collaborating with Nokia 
>and Columbia University with the P2PP prototype. Together with 
>Nokia we are implementing a mobile version (works on Nokia's 
>S60 phones) of P2PP prototype, which is able to act as both 
>P2PSIP peer and client. We are currently working on mobile 
>version's interoperability with fixed version of P2PP, aiming 
>to provide full compatibility between them.
>
>environment for the prototypes. Thus, I also encourage you to 
>join this P2PP trial network to increase the node population.
>
>-Erkki
>
>

---

From: <[email-masked]>
Date: Tue, 22 Jan 2008 13:06:34 +0200

>[RRR] Yes, you are right. So, please help this P2PSIP WG to 
>complete the spec for the base P2PSIP protocol based on these 
>implementation experiences as soon as possible. We would 
>appreciate this.

We are constantly improving our software implementation and protocol
specification. We published a paper at CCNC conference (Mobile P2PSIP -
Peer-to-Peer SIP communication in mobile communities). It should be
available from ieeexplore. 

Do you think that an implementation report (with some measurements)
would be useful?

Marcin

>From: ext Roy, Radhika R Dr CTR USA USAMC 
>[mailto:[email-masked]] 
>Sent: 21 January, 2008 16:13
>To: Matuszewski Marcin (Nokia-NRC/Helsinki)
>Cc: [email-masked]; [email-masked]; 
>[email-masked]; [email-masked]
>> Planet Lab and allow users to use basic SIP services. The demo was 
>> done in colaborationwith Columbia Univ.
>[RRR] Yes, you are right. So, please help this P2PSIP WG to 
>complete the spec for the base P2PSIP protocol based on these 
>implementation experiences as soon as possible. We would 
>appreciate this.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 22 Jan 2008 08:13:06 -0500

PlanetLab is many things, but stable is not the adjective I would  
use... These are generally servers run on a volunteer basis by  
graduate students in various university labs; they routinely get  
disconnected, crash or get overloaded with other experiments.

Relative to consumer nodes, they do tend to have public IP addresses.

It would be good to gather some statistics on the dynamics of  
PlanetLab nodes.

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 22 Jan 2008 15:07:37 +0100

Henning Schulzrinne wrote:
> PlanetLab is many things, but stable is not the adjective I would use...
> These are generally servers run on a volunteer basis by graduate
> students in various university labs; they routinely get disconnected,
> crash or get overloaded with other experiments.
> 

So, if I understand correctly, Marcin's mobile devices connect directly
to P2PP peers running on PlanetLab nodes without effectively being part
of PlanetLab, establishing an overlay made of both PL and non-PL nodes,
right?

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Tue, 22 Jan 2008 09:15:50 -0500

Hi, Mercin:

What we want is to develop the P2PSIP protocol standard for this WG. The P2PSIP protocol drafts are there. You can help to provide insights which proposals are good and if needed what improvements need to be done to finalize the specs or you can proposed a new one or a modified draft combining with the existing ones.

In this way, you can play a role to standardize the P2PSIP protocol for this WG. Then we can proceed to build other P2P things (e.g. HIP-overlay using the standardized P2PSIP protocol of this WG).

Best regards,
Radhika

----- Original Message -----
From: [email-masked]
Date: Tuesday, January 22, 2008 6:02
Subject: RE: RE: [P2PSIP] HIP: optional, mandatory?
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]

> P2PP

---

From: <[email-masked]>
Date: Tue, 22 Jan 2008 16:28:36 +0200

Hi Enrico,

You are correct. In the demo P2PP enabled mobile phones connect to P2PP
nodes on PlanetLab. Mobile phones are not part of PlanetLab. 

Mobile phones can also form a separate overlay (they don't have to
connect to PlanetLab).

Marcin 

>From: ext Enrico Marocco [mailto:[email-masked]] 
>Sent: 22 January, 2008 16:08
>To: Henning Schulzrinne
>Cc: Matuszewski Marcin (Nokia-NRC/Helsinki); 
>[email-masked]; [email-masked]
>So, if I understand correctly, Marcin's mobile devices connect 
>directly to P2PP peers running on PlanetLab nodes without 
>effectively being part of PlanetLab, establishing an overlay 
>made of both PL and non-PL nodes, right?
>
>--
>Ciao,
>Enrico
>

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 22 Jan 2008 07:29:59 -0800

Enrico,

>of PlanetLab, establishing an overlay made of both PL and non-PL nodes,

The mobile devices run the _client protocol_ that has been the topic of
many discussions on this list.

Maybe Marcin can give us the reference to the latest description of the
client protocol for P2PP implemented for this trial. 

Thanks, Henry

-----Original Message-----
From: Enrico Marocco [mailto:[email-masked]] 
Sent: Tuesday, January 22, 2008 6:08 AM
To: Henning Schulzrinne
Cc: [email-masked]; Henry Sinnreich; [email-masked]
Subject: Re: [P2PSIP] HIP: optional, mandatory?

> PlanetLab is many things, but stable is not the adjective I would
use...

-- 
Ciao,
Enrico

---

From: Erkki Harjula <[email-masked]>
Date: Tue, 22 Jan 2008 18:11:08 +0200

Henry Sinnreich wrote:
> The mobile devices run the _client protocol_ that has been the topic 
> of many discussions on this list.
Actually we are currently implementing the _peer_ prototype at the Univ. 
of Oulu. At the moment it is based on the older version of P2PP, and we 
are currently converting it to P2PP version -01. The next goal is the 
integration with Nokia's client version (which was demonstrated in CCNC) 
and Salman's new prototype implementation.

-Erkki

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 22 Jan 2008 11:06:13 -0800

> we are currently implementing the _peer_ prototype at the Univ. 
> are currently converting it to P2PP version -01.

It is very encouraging to see one more organization contributing to
deploying and testing a P2PSIP protocol that has the benefits of free
code, deployment experience, peer review and continued enhancements from
various sources.

This may or may not have been a requirement in the WG charter, but makes
many of us comfortable the emerging P2PSIP standard may be based on all
these benefits coming from cooperation in the IETF.

Henry

-----Original Message-----
From: Erkki Harjula [mailto:[email-masked]] 
Sent: Tuesday, January 22, 2008 8:11 AM
To: Henry Sinnreich
Cc: [email-masked]
Subject: Re: [P2PSIP] HIP: optional, mandatory?

-Erkki

---

From: <[email-masked]>
Date: Wed, 23 Jan 2008 14:20:57 +0200

The mobile phones implement the P2PP protocol
(http://tools.ietf.org/id/draft-baset-p2psip-p2pp-01.txt) and Kademlia
DHT. Depending on a situation a mobile phone may act as a peer or a
client. If it becomes a client it connects to some of P2PP peers and
uses a subset of the P2PP protocol, called a "client protocol" (mainly
PublishObject, RemoveObject, LookupObject), to perform PUT/GET
operations. If a mobile phone can act as a peer then it uses the full
P2PP protocol and runs Kademlia code (the clients do not run DHT).

In addition the demo includes TURN like relays that publish their
contact information in the overlay and help clients and peers to
traverse NATs/Firewals.

Marcin 

>Sent: 22 January, 2008 17:30
>To: Enrico Marocco; Matuszewski Marcin (Nokia-NRC/Helsinki)
>Cc: [email-masked]; Henning Schulzrinne
>The mobile devices run the _client protocol_ that has been the 
>topic of many discussions on this list.
>
>Maybe Marcin can give us the reference to the latest 
>description of the client protocol for P2PP implemented for 
>this trial. 
>
>Thanks, Henry
>

---

From: <[email-masked]>
Date: Wed, 23 Jan 2008 14:34:19 +0200

Hi Radhika,

We share the same goal. 

Salman, Henning and me are specifying the P2PP protocol
http://tools.ietf.org/wg/p2psip/draft-baset-p2psip-p2pp-01.txt. The
version of the document is going to be updated based on our recent
implementation experience.  

We would appreciate your suggestions and comments. The cooperation on
software development is also appreciated. This will allow P2PSIP WG to
converge much faster.

Marcin

>Sent: 22 January, 2008 16:16
>Cc: [email-masked]; [email-masked]; Matuszewski 
>Marcin (Nokia-NRC/Helsinki)
>Subject: Re: RE: RE: [P2PSIP] HIP: optional, mandatory?
>
>Hi, Mercin:
>
>What we want is to develop the P2PSIP protocol standard for 
>this WG. The P2PSIP protocol drafts are there. You can help to 
>provide insights which proposals are good and if needed what 
>improvements need to be done to finalize the specs or you can 
>proposed a new one or a modified draft combining with the 
>existing ones.
>
>In this way, you can play a role to standardize the P2PSIP 
>protocol for this WG. Then we can proceed to build other P2P 
>things (e.g. HIP-overlay using the standardized P2PSIP 
>protocol of this WG).
>
>Best regards,
>Radhika
>
>complete 
>> >the spec for the base P2PSIP protocol based on these implementation 
>> >experiences as soon as possible. We would appreciate this.
>> 
>> specification. We published a paper at CCNC conference 
>(Mobile P2PSIP 
>> - Peer-to-Peer SIP communication in mobile communities). It 
>should be 
>> >Cc: [email-masked]; [email-masked]; [email-masked]; 
>> >[email-masked]
>complete 
>> >the spec for the base P2PSIP protocol based on these implementation 
>> >experiences as soon as possible. We would appreciate this.
>> >
>> 
>

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Wed, 23 Jan 2008 09:15:01 -0500

Marcin:

Yes, that is what this WG, I believe, wants - helping to finalize the base P2PSIP protocol through implementation experiences as soon as possible.

Best regards,
Radhika