Er, I guess I *hear* you and agree with you *here* ;)
On Jan 11, 2008 10:50 AM, David A. Bryan <[EMAIL PROTECTED]> wrote:
> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/p2psip
> >
>
>
>
>
> --
> David A. Bryan
> [EMAIL PROTECTED]
> +1.757.565.0101 x101
> +1.757.565.0088 (fax)
> www.SIPeerior.com
>
--
David A. Bryan
[EMAIL PROTECTED]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com
_______________________________________________
P2PSIP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/p2psip
