Re: [P2PSIP] New draft: HIP BONE

[Ali Fessi <[e-mail]>]

Hi Gonzalo,

what is if peers add the HIP ORCHID at the first position of the list of 
gathered addresses for ICE?

Since a HIP overlay, let's say a HIP BONE, will provide e2e 
connectivity, peers in the same HIP BONE will then be able to 
communicate as if they would be in the same private network if they use 
the HIP ORCHID as "IP addresses" and they woule be able to benefit from 
all the advantages of using HIP.

If they are not in the same HIP BONE, they would need to establish 
connectivity through other type of addresses, e.g. those retreived by STUN.

Do you think that would work?

Cheers,
  Ali

Gonzalo Camarillo 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.
> 
> 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.
> 
> Cheers,
> 
> Gonzalo
> 
> 
> Bruce Lowekamp wrote:
>> Gonzalo,
>>
>> Many thanks to you, Pekka, and Jani for putting in yet more effort to
>> try to clarify a possible role for HIP in P2PSIP.
>>
>> At a high level, in section 5 you list two potential outcomes, which
>> are for the wg to settle on HIP for all connection management or for
>> the wg to not use hip, but retain modularity that allows it.  I would
>> rather see option 2 reworded along the lines of "the wg will develop a
>> protocol that uses HIP as one possible choice for its connection
>> management layer.  The HIP module will not be mandatory to implement,
>> but its specification will be developed by the wg."  I think that's
>> something along the lines of what you're thinking.  It's certainly
>> what I'm hoping the outcome will be.  I am sure there are other
>> options as well (ignore hip, try to maintain compatibility but don't
>> specify, etc).
>>
>>
>> On a specific issue, I'm still a little confused about where the line
>> is between what the overlay does with overlay routing and what
>> HIP-BONE should be responsible for.  Your section 3.2 proposes that I1
>> packets are sent across the Peer Protocol overlay.  Were I to
>> implement RELOAD on top of HIP-BONE, what exactly does this mean?
>> Does this mean that I send a RELOAD CONNECT message and the contents
>> of that message are now an I1 instead of ICE candidates?  Or would
>> RELOAD's CONNECT go away and RELOAD would simply try to send a message
>> directly to a new PeerID via its ORCHID and the HIP-BONE layer would
>> then produce an upcall to RELOAD asking that an I1 be tunneled across
>> the overlay?
>>
>> Similarly, in section 3.3, you suggest that a HIP message could be
>> tunneled through the overlay rather than establishing a new connection
>> for a simple query.  Generally, dht maintenance operations and
>> resource query operations are somewhat distinct.  If I'm using
>> recursive routing, a resource query operation would never cause a new
>> connection to be formed, but instead the query would be routed across
>> the overlay by the Peer Protocol.  Assuming I'm understanding your
>> layering correctly, that would be implemented by the Peer Protocol
>> knowing the translation between the PeerID of the next hop that it has
>> a connection to and that peer's ORCHID (or LSI) and the Peer Protocol
>> would route the query message to that next hop just like it has a
>> direct IP connection (and generally be unaware of the difference).
>> So I'm unclear on when the mechanism in 3.3 would be invoked.  If I'm
>> using recursive routing, the only time I would send a message to a new
>> peer for which I do not have an existing connection would be:
>> - during dht maintenance if I decide I should have a connection with
>> this new peer
>> - if the application decides it wants to send an application-layer
>> message directly
>> RELOAD proposes to solve the first case using CONNECT messages, as
>> discussed above.  It also proposes to solve the second case with a
>> CONNECT message (or TUNNEL, as decided by the application).  This is I
>> think where HIP (or at least id/loc) has its biggest potential win.
>> Is the use of a new ORCHID by the application the proposed application
>> of section 3.3?  If so, how would the decision be made of when to
>> tunnel and when to open a new direct connection?
>>
>> Bruce
>>
>>
>>
>>
>> On Dec 21, 2007 6:51 AM, Gonzalo Camarillo
>> <[e-mail]> wrote:
>>> Hi,
>>>
>>> we have seen a lot of discussions on how HIP could relate to P2PSIP on
>>> this list lately. While this level of interest on HIP is a good thing
>>> (from the HIP community's perspective), there have been a few
>>> misconceptions and misunderstandings on what is essential to HIP (e.g.,
>>> the ID/locator split) and what are just design or configuration choices
>>> made in a given HIP deployment (e.g., using self-certifying 
>>> identifiers).
>>>
>>> With the draft below, we have tried to clarify a few of the design
>>> choices that can be made while defining the use of HIP in a given
>>> scenario (e.g., the use of a centralized enrollment server). In
>>> particular, we have focused on the use of HIP to build overlays. The
>>> draft also includes tutorial material on HIP so that readers who are not
>>> familiar with HIP can still follow what it is said in the draft.
>>>
>>> http://www.ietf.org/internet-drafts/draft-camarillo-hip-bone-00.txt
>>>
>>> The draft also discusses the relationship between HIP and P2PSIP. It
>>> clarifies that while HIP can be used to implement connection management,
>>> other functions such as overlay maintenance, and data storage and
>>> retrieval are implemented using a peer protocol such as RELOAD or P2PP.
>>> We thought that this clarification was important because it seems some
>>> people mistakingly thought HIP was a full-blown peer protocol proposal
>>> while, in reality, HIP only provides connection management.
>>>
>>> Enjoy your Christmas reading! ;o)
>>>
>>> Cheers,
>>>
>>> Gonzalo
>>>
>>> _______________________________________________
>>> P2PSIP mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/p2psip
>>>
>>>
> 
> 
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/p2psip
> 


-- 
Ali Fessi
Computer Networks and Internet
University of Tuebingen, Germany
Phone: [phone] / Fax: [phone]
EMail: [e-mail]
Web: http://net.informatik.uni-tuebingen.de/~fessi/

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