RE: [P2PSIP] New draft: HIP BONE

["Henderson, Thomas R" <[e-mail]>]

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

> -----Original Message-----
> From: Pekka Nikander [mailto:[e-mail]] 
> Sent: Thursday, January 10, 2008 4:40 AM
> To: Henderson, Thomas R
> Cc: Bruce Lowekamp; Gonzalo Camarillo; P2PSIP Mailing List
> Subject: Re: [P2PSIP] New draft: HIP BONE
> 
> Tom,
> 
> >> Going with the HIP-BONE, approach, as I understand the "HIP is IP  
> >> 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.

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.

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

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

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

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