Re: [P2PSIP] HIP: optional, mandatory?

["David A. Bryan" <[e-mail]>]

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)

On Jan 11, 2008 10:38 AM, Spencer Dawkins <[e-mail]> wrote:
> 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
>
> > On Jan 10, 2008 10:52 PM, Henning Schulzrinne <[e-mail]> wrote:
> >> 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.
>
> 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
>
>
>
> > 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)
>
>
>
>
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/p2psip
>



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

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