This is exactly the situation I want to avoid. We're now creating two
classes of systems, the HIP-capable ones and the rest. From a consumer
perspective, somebody buys a "VoIP p2p client" to join any number of
yet-unkown overlays (otherwise, they could just run Skype) - and then
find out that they can't join some fraction of overlays because they
didn't look for an acronym they didn't understand. They can only hope
that the overlay implements "bridging", likely with the need for a
central server to perform that function.
This also violates the "no cost" requirement I mentioned. Even if I,
as an implementor consider HIP a waste of time, I still have to
implement it.
At least we're now clear that the HIP advocates want to essentially
force systems to implement it. This will hopefully focus the
discussion a bit.
Henning
On Jan 11, 2008, at 10:38 AM, Spencer Dawkins 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
_______________________________________________
P2PSIP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/p2psip
