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
<[EMAIL PROTECTED]> 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
[email protected]
https://www1.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/p2psip
--
Ali Fessi
Computer Networks and Internet
University of Tuebingen, Germany
Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220
EMail: [EMAIL PROTECTED]
Web: http://net.informatik.uni-tuebingen.de/~fessi/
_______________________________________________
P2PSIP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/p2psip
