Subject: [p2p-sip] Where are we "getting wrapped around the DNS axle"

From: dean.willis at softarmor.com (Dean Willis)
Date: Sun, 3 Dec 2006 00:18:11 -0600

I think we're arguing at cross-purposes about DNS here.

Let me see if I can clarify things a bit:

Assumptions I think we agree on:

1) IF our rendezvous/bootstrapper/cert-server/whatever-we-start-with  
is listed in DNS, and our UA has a hostname for that whatever, THEN  
we MAY be able to use DNS to turn that hostname into an IP address.

2) If we're using DNS, as in #1, then we MAY use dynamic DNS to  
insert a record associating a hostname with an IP address. We MAY use  
conventional DNS configuration as an alternative.

3) The process of associating a hostname with an IP address in DNS is  
completely disjoint from the process of looking up a hostname in DNS  
to discover an IP address. That is, the lookup process is unrelated  
to and not dependent in any way on the configuration process.

Things we MIGHT agree on:

1) If DNS is available, we MAY use it. However, we presume that DNS  
is not always available, so we MUST NOT depend on it. For example, a  
Skype-like configuration where UAs are configured with a default  
rendezvous IP address should be workable.

2) If multicast is available, we MAY use mDNS. However, we presume  
that multicast will not always be available, so we MUST NOT depend on  
mDNS in all cases.

One MIGHT envision a resolution model that looks something like:

IF configured with a rendezvous/bootstrap/...whatever that looks like  
an IP address,
   THEN use that IP address
ELSE
   IF bootstrap looks like a hostname AND
     IF DNS is available AND returns an answer
       THEN use the address returned by DNS
     ELSE
       IF multicast is available AND returns an answer
         THEN use the address returned by mDNS
       ELSE bootstrap is broken, give up and die
       END IF multicast ...
    END IF DNS
   ELSE bootstrap is broken, give up and die
   END IF bootstrap ...
END IF configured ...

Things we have NO agreement on

1) Mandating DNS as the only resolution method for discovering the IP  
address of an entry point to an overlay

2) Using dynamic DNS as the registration/resolution mechanism for  
finding nodes in an overlay. While this could work, it's just a  
straightforward application of dynamic DNS and plain old SIP,  
consequently requiring no new work. It also doesn't meet many of the  
use cases given for P2PSIP.

--
dean

---

From: matthew at matthew.at (Matthew Kaufman)
Date: Sat, 2 Dec 2006 23:08:19 -0800

> use cases given for P2PSIP.

I guess I still fail to see how dynamic DNS + zeroconf misses any of node
(and credential, if there are any) lookup problems presented by the use
cases given for P2PSIP. Meanwhile I do see how there's lots of other "P2P"
problems that *do* need solving for SIP.

Personally, I think that the focus on the DHT up front is a distraction from
those other "P2P" problems that need solving, and that standardizing on one
that's been shown to be insufficient for the actual use cases proposed will
be an additional distraction in the future, but -- given the "charter" and
the "working group" and all -- I'm also perfectly willing to sit on the
sidelines here and focus my energy on solving other interesting problems.

Matthew Kaufman
matthew at matthew.at

---

From: dbarrett at quinthar.com (David Barrett)
Date: Sun, 3 Dec 2006 00:11:35 -0800

That's a great breakdown!  I love the bootstrapping logic you use; that
sounds like an excellent approach.

As for the others, I totally agree with what Matthew wrote, and I'd add:

> -----Original Message-----
> From: Dean Willis
> Subject: [p2p-sip] Where are we "getting wrapped around the DNS axle"
> 

I agree, DNS is wonderful for how universally standard it is to query, but
sucks for how nonstandard it is to configure.  The dynamic DNS guys have
made some good strides in automated DNS configuration on a limited scale
(the DynDNS client, for example, supports many different dynamic DNS
providers, not just DynDNS.com), but more work is required.

As such, while I'm receptive to the argument:

	"Even though DNS does a good job resolving an authoritative
hierarchical namespace into IP addresses, it's only appropriate for servers
because of the manual administration required."

My response would be:

	"Perhaps now is the time to automate that administration so we can
extend the existing DNS system to lookup clients and thus blur the line
between clients and servers (as is the hallmark of P2P)."

Indeed, I think there could be an excellent P2P-DNS sister group that
focuses on precisely this: making DNS useful for P2P networks (rather than
only client/server networks, as current).  P2P-SIP would be one of the major
customers of such a group.

> that multicast will not always be available, so we MUST NOT depend on

Likewise, I agree that this is the consensus and charter of the group.  My
confusion is why we've made this iron-clad, inviolate decision when nobody
has been able to give any real-world example of any significant set of
real-world users who do not already have DNS, won't get DNS in short order,
and can't use mDNS in the meantime.  We've discussed the entire gamut from
the largest to smallest deployments, and DNS/mDNS fit them all.

> use cases given for P2PSIP.

On the first, I didn't mean to suggest DNS should be the only option.  If
you want to hard-code or hand-enter IP addresses, go right ahead.  I'm
merely saying that DNS is everywhere the users are, so it's silly not to use
it when convenient, and wasteful to spend so much energy figuring out how to
live without it when it's right there.

On the second, I'd like to hear about these use cases that can't be met by
using DNS/mDNS/dynamic-DNS to find the proxy for a given UA.

So again, I'm not saying a P2P-SIP protocol using an IP-bootstrapped DHT
wouldn't work.  I'm just saying it's a classic case of overengineering to
solve theoretical problems that don't exist in the real world.  In the real
world, DNS and central directories work exceedingly well.  Nobody would have
bothered "improving" upon the hybrid central/p2p model of Napster had the
RIAA not insisted upon it.  Indeed, Bittorrent has been wildly successful
precisely because it didn't try.

Thus it seems much more realistic to just:

a) Have every SIP address of the form 'name at domain'
b) Resolve 'domain' to the IP address of the proxy managing that address
c) Install regular SIP proxies configured with regular DNS wherever possible
d) Have a cloud of P2P-SIP proxies configured with dynamic-DNS for the rest
e) Have P2P-SIP clients respond to mDNS requests when DNS is unavailable
f) Have P2P-DNS focus on standardizing dynamic DNS and mDNS configuration
g) Have P2P-SIP focus on bridging SIP, P2P-DNS, and infrastructureless peers

Admittedly, it's not as sexy as a non-DNS solution.  It probably doesn't
need a DHT (the cloud of public proxies could be better managed with a
simple central directory).  But it seems to work for all of the P2P-SIP use
cases, and seems technically much simpler to do.

-david

---

From: ag at ag-projects.com (Adrian Georgescu)
Date: Sun, 3 Dec 2006 19:03:36 +0100

Dean,

What we miss is:

DNS like query/response mechanism for resources in the  P2P overlay.

Adrian

On Dec 3, 2006, at 7:18 AM, Dean Willis wrote:

> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: bryan at ethernot.org (David A. Bryan)
Date: Sun, 3 Dec 2006 14:40:19 -0500

> g) Have P2P-SIP focus on bridging SIP, P2P-DNS, and infrastructureless peers

The big question here is who is maintaining these proxies and dynamic
dns servers? This proposal isn't really any different than a
conventional SIP service in terms of the centralization model. Someone
still needs to provide the proxies and someone is providing the
dynamic DNS system, which basically starts to look like a centralized
registrar that someone has to own, you just moved it from speaking SIP
to speaking DNS.

I also still haven't heard a good response to handling mobility. I
want to be able to go from home to my mobile, drive 5 minutes, and
then go to the office, and want to be reachable at all points, which I
don't see a dynamic DNS approach doing.

David

---

From: dbarrett at quinthar.com (David Barrett)
Date: Sun, 3 Dec 2006 13:23:27 -0800

> From: David A. Bryan
> Subject: Re: [p2p-sip] Where are we "getting wrapped around the DNS axle"
> 
> dns servers? 

A lot of people, as would be expected from any highly distributed system:

- On one end of the spectrum, a domain owner (eg, @intel.com) can choose to
take total responsibility for all calls into that domain and just install a
central SIP server that works in a classic sense.

- On the other end of the spectrum, a random user can trust the kindness of
any number of benevolent "free" networks (each identified by its own domain,
like @p2psip.org or @myfreebiesip.com, with DNS used to find the
bootstrapping servers), leveraging the donated resources of volunteer nodes.

As for maintenance of specific systems:

- Standard SIP proxies would be maintained by either standard SIP providers
or large corporations (eg, intel.com might offer a robust SIP deployment for
its employees). 

- Dynamic DNS servers would be maintained by the dynamic DNS providers, of
which there are dozens (http://www.technopagan.org/dynamic/).  A Dynamic DNS
provider is nothing more than a standard DNS registrar that happens to
support an automated configuration interface and fast-propagating bindings.
I'd expect that in the future, *every* DNS registrar would support dynamic
DNS.

- Distributed SIP proxies (eg P2P-SIP proxies on non-NAT'd boxes registered
into some public cloud) would be maintained in the hardware sense by the
owners of the non-NAT'd boxes themselves.  However the "cloud" in a more
general sense is maintained by the bootstrapping services.  Some might
bootstrap into a DHT, others might just maintain a big central list.  Either
way, any kind soul with time and resources on his hand can register a
domain, create a new cloud (using protocols to be defined by P2P-SIP) and
make sure its good.

DNS is far from enslaving the world under central rule; it's the only system
with *truly* decentralized ownership, and I want that benefit in SIP.  

> This proposal isn't really any different than a

For users who like conventional SIP, yes, it's precisely no different, by
design.

For users who don't like conventional SIP they:
1) Get a domain from any of dozens of dynamic DNS providers
2) Find an existing bootstrapping service, or create a new one and host it
3) Enter the following into their P2P-SIP client:
	. Dynamic-DNS credentials (the only password they have)
	. Bootstrapping server IP address or domain name

After which their P2P-SIP client finds public resources using the chosen
bootstrapping service (either asking "give me a STUN server" directly or
"give me a DHT of STUN servers", depending on what the bootstrapping service
provides), registers with the SIP proxy built-into the P2P-SIP proxy of some
non-NAT'd client (or multiple, for redundancy), uses dynamic DNS to update
his record to point to his current SIP proxy(ies), and everything else just
works as normal.  To the outside world, a random, infrastructure-less
P2P-SIP client looks *exactly no different* than a totally client-server SIP
user.  Both have a normal SIP address that is resolved to a SIP proxy using
normal DNS, and whether that SIP proxy is a big server in the sky or a
random non-firewalled client, it makes no difference and nobody is the
wiser.

> don't see a dynamic DNS approach doing.

Yes, it can do that too.  Let's assume you had some device with two wireless
adapters that started connected to your home network (IPhome), then
connected to some kind of cellular network (IPcar) as you walked out the
door and dropped IPhome, and then picked up your work network (IPwork) as
you walked into the office and dropped IPcar.

DNS supports multiple IP addresses per domain.  To start, your P2P-SIP
client would register IPhome, and then it would for a brief period register
both IPhome and IPcar, and then when it went out of home range it'd register
only IPcar, and then as you got into the office it's register IPcar and
IPwork, and then when you went into the faraday cage (which we all have,
right?) it'd register just IPwork.  Regardless, every time you switch
networks, there are two options:

1) You have connectivity, and thus can update your DNS record
2) You do not have connectivity, and thus cannot update your DNS record

So long as you can connect to the internet, you can update the relevant
records to ensure people on the internet can call you.  And if you can't
connect to the internet, it's not a problem.

Furthermore, we haven't discussed the mDNS case where even if you walk into
a faraday cage and your company internet connection goes out, you can still
talk with everyone else in the office because they'll do an mDNS lookup for
your domain (using multicast over the LAN, which is very widely supported)
and will find you just fine.

Again, DNS, dynamic-DNS, and mDNS handle *all* these cases as good as
anything else, and likely much better.  I apologize that it's not sexy, but
it's entirely adequate and indeed probably superior. 

There are still plenty of challenges to work out and details to standardize,
and the P2P-SIP WG is ideally suited to do it.  Sure it's not inventing any
new class of fun DHT technology (or standardizing an antiquated, obsolete
DHT), but the IETF isn't supposed to invent: it's supposed to standardize
what is already there.  DNS, dynamic DNS, mDNS -- they're here and here to
stay.  P2P-SIP should be figuring out and standardizing best practices, not
inventing replacements.

-david

---

From: bryan at ethernot.org (David A. Bryan)
Date: Sun, 3 Dec 2006 22:21:33 -0500

I still fail to see how having volunteer proxies is P2P. Just because
"a lot people" are participating, it isn't necessarily decentralized,
you've simply moved the central people you are dependant on from being
a company to be one or more volunteers. The individual users using the
service aren't participating (at least not all of them) in providing
the services, they are only using them. You are still relying on
centralized devices that are maintained and provided by others, in
this case, some group of volunteer proxies and some dynamic DNS
servers that may or may not be provided on a volunteer basis. Such a
system is thus susceptible to their whims and desires of those
providing it to stop at any time.

I simply don't see that it is a truly decentralized system, where one
(or a few) entities deciding to stop volunteering or being unable to
volunteer can mean the system fails. Nothing wrong with it of course,
it could work, and certainly would be interesting work to go do (as
others pointed out, the work could likely be submitted as a draft to
SIPPING) I don't think it is really in line with the type of system
that at least many of us who have been working to get this group off
the ground really had in mind.

There certainly are also scenarios (the impeded access, security
conscious small organization, and anonymous communications -- all of
3.2 in draft-bryan-sipping-p2p-usecases seem to fall into that boat)
where I can't see the approach you propose working, either.

I'm sorry I was a bit unclear with my question about how to do
mobility. It is more of a question of handling the update period in a
cached DNS-like system with sufficient speed. 5 minutes is a
reasonable time period to change a phone location, but I am not at all
convinced that conventional dynamic DNS as it is today can push
updates that fast, or it would scale if you tried. DNS does a heck of
a lot of caching. Not sure, but I would think there would be stale
caches causing all sorts of problems. It could work very well for a
permanent or semi-permanent desk phone of course, just not practical
in all the scenarios we have discussed, at least in my mind.

David

---

From: dbarrett at quinthar.com (David Barrett)
Date: Mon, 4 Dec 2006 01:48:29 -0800

> I still fail to see how having volunteer proxies is P2P. ... The
> individual users using the
> the services, they are only using them.

I'm sorry, I was unclear -- I assumed it was apparent the P2P-SIP client
would "auto-volunteer" anyone who was able (ie, not NAT'd or firewalled).  I
agree, a system where people must explicitly "opt-in" will probably fail.
So please rethink my proposal with the new assumption that "all P2P-SIP
clients will auto-volunteer to one or more clouds".

To clarify, I'm using the term "volunteer" to describe the classic P2P
relationship where you donate resources for the use of others, in exchange
for others to donate them when you need them.  If there's a better, more
intuitive term for this, please let me know.  

I'm also using the term "cloud" to describe "a group of P2P-SIP clients who
cooperatively volunteer resources".  I've assumed there will be multiple
"clouds" of volunteer nodes, and that anybody can start a new one by just
putting up a bootstrapping server and asking people type that IP/domain into
their client.  However, if it helps things for the sake of argument, we can
simplify the model and assume there's only one cloud, only one bootstrapping
service (provided by p2psip.org), and every P2P-SIP client is hard-coded to
connect to it on startup.

> You are still relying on

Hm, this seems to be overstating it:

If you are behind a NAT or firewall, you only need to find at least one
bootstrapping service that can provide you with at least one "volunteer"
node.  Given that there can be any number of bootstrapping services (aka
"clouds"), and each of these can contain any number of nodes (aka
"volunteers") -- and that any node can and probably should volunteer into
multiple clouds -- it'd take a rather large conspiracy to deny you service.
Indeed, how is this any different than bootstrapping into a DHT?

(And if you are not NAT'd and not firewalled then you don't need a
bootstrapping service and don't need any other volunteers, though I'd expect
the client would be written to have you in turn volunteer for others.)

Furthermore, yes, I'm assuming whoever you registered your DNS name with
would continue to maintain it, else you'd move it to a more reliable
provider.  This doesn't seem at all an unreasonable or unusual demand.  With
few exceptions, DNS providers generally aren't capricious.

> volunteer can mean the system fails.

Have I addressed your concerns here with the above clarifications?

> where I can't see the approach you propose working, either.

Well, in the absolute, no human technology (including DNS) can achieve that
level of security -- it's like requiring total invisibility to the NSA and
total penetration of the great firewall of China, now and forever.

But while they are impossible requirements in the absolute, it's possible to
be "good enough" in each respect.  Unfortunately, "good enough" isn't well
defined at this point, so it's hard to argue whether DNS can or cannot meet
that actual standard (versus the absolute ideal presented in your draft).
Tell me to what degree you intend to satisfy these requirements in a non-DNS
world, and then we can figure out if DNS can meet or exceed that level.

> caches causing all sorts of problems.

Set the TTL to be near-zero and all the caches will expire, causing DNS to
resolve your name from scratch every time.  It'd be inefficient to do that
for a high-volume webserver that never changes IPs, but it's totally
sensible to do that for an extremely low-volume P2P-SIP client that changes
IPs all the time.

Akamai does this.  UltraDNS does this.  This isn't some crazy theory that
pushes DNS in a totally new and explored area.  Lots of people are doing
this today.

So in summary, I've tried to address the following concerns:

Concern: Opt-in volunteering won't work.
Response: Not opt-in; everyone who can volunteers by default.

Concern: Still relying upon others.
Response: It relies upon DNS providers to provide DNS.  Otherwise it relies
on volunteers no more or less than DHT.

Concern: Can't achieve absolute security.
Response: Nothing can.  However, DNS can give "good enough" security.

Concern: DNS can't propagate fast enough.
Response: Set tiny TTLs and it can.

Were there other concerns that I missed?  Are the above responses
inadequate?

Matthew -- You know a lot more about the inner workings of DNS than me; did
I misstate anything?

-david

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Mon, 04 Dec 2006 11:26:01 +0100

> few exceptions, DNS providers generally aren't capricious.

That's the whole point.  We have been figuring a system that doesn't
depend on any provider since the very beginning.  If some are available,
it can make use of them (e.g. for bootstrap), otherwise it must work
anyway, even if with limited (but still required, at least in some
"uncommon" scenarios) functionalities.

This was the very first assumption and unfortunately a solution which
depends on a service "provided" by someone doesn't meet it.  Nobody's
asserting that such a solution wouldn't be better than p2p-sip; it's
just that it isn't p2p-sip.  Period.

-- 
Ciao,
Enrico

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Mon, 4 Dec 2006 07:21:31 -0800

>We have been figuring a system that doesn't depend on any provider
since >the very beginning.  If some are available, it can make use of
them (e.g. >for bootstrap), otherwise it must work anyway

This is a very powerful model shift indeed.
Such a P2P SIP enabled devices could have multiple accounts, so that
users could configure it for their own community networks ("providers"
if you will), but also use providers of _their own choice_.

Maybe the overlay Internet, the openDHT can interconnect all P2P SIP
devices for an access fee, similar to the access fee paid today for
broadband IP. Think of Overlay Access Service (OAS) similar to the IP
broadband access existing today.

If the above gets implemented, there will be a huge market for P2P SIP
communication devices, based on a common global standard and on open
communications under user control. 

Such devices are the opposite of today's locked down mobile phones that
work only for one single provider.

Don't expect though this new business model to have smooth sailing...

Thanks, Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Enrico Marocco
Sent: Monday, December 04, 2006 4:26 AM
To: David Barrett
Cc: 'P2P-SIP'; 'David A. Bryan'
Subject: Re: [p2p-sip] Where are we "getting wrapped around the DNS
axle"

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Mon, 4 Dec 2006 07:21:25 -0800

>DNS like query/response mechanism for resources in the P2P overlay.

DNS like query/response is not missing if there is a primary bootstrap
mechanism, such as the service mode in the I-D by K. Singh and H.
Schulzrinne. This fits into Dean Willis model, which is right:

IF configured with a rendezvous/bootstrap/...whatever that looks like an
IP address,
   THEN use that IP address
ELSE

Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Adrian Georgescu
Sent: Sunday, December 03, 2006 12:04 PM
To: Dean Willis
Cc: P2P-SIP
Subject: Re: [p2p-sip] Where are we "getting wrapped around the DNS
axle"

Dean,

What we miss is:

Adrian

---

From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 4 Dec 2006 08:35:31 -0800

> "uncommon" scenarios) functionalities.

I would argue that doing a DNS-protocol lookup given the fixed IP addresses
of the canonical root DNS servers (and, if you like, the fixed IP addresses
of some non-traditional root DNS servers) is *exactly the same* as doing a
DHT-protocol lookup given the fixed IP addresses of some seed nodes for the
DHT. And I would argue that if one can find the node at which an answer
would be stored, one can send updated information to that node as often as
bandwidth permits.

In both cases a new client requires the IP address of a bootstrap node, and
in both cases that information can redirect you to a (possibly infinite)
number of other nodes that actually contain the information.

The DNS solution requires more clever thought for the highly-distributed
cases, but can be set up today to just work for the less-distributed cases,
of which there are many. It also means that work on solving all the other
interesting P2P problems could start immediately.

The DHT solution requires more work on the part of the DHT-participating
clients to join the DHT and then requires a DHT algorithm that is stable in
the face of the expected level of client churn in order to keep providing
correct answers (of which Chord is almost certainly not an example).

And in both cases, if the configured fixed IP addresses are unreachable,
then the only way to find other clients on the LAN is multicast. Zeroconf
provides its mDNS mechanism for doing this in a DNS-like way, which is a
reasonable standard to adopt for this use case.

What it really comes down to is that when I hear "P2P SIP" I think of the
actual P2P problems with the SIP part, the P2P *signaling* issues... not the
P2P problems of node discovery and lookup. If I know the IP address of a SIP
client that my buddy is using and a way to traverse the NAT it is behind (if
any), how can I make that client ring if there's no proxy to talk to? What
if I know the IP addresses of her three SIP clients... can I make all three
of them ring without involving a proxy? Can I use SIMPLE to get presence
information from all three of them directly? In general, can I replace the
trapezoid with a straight line from my client to her client and still get
all (or most of) the features I'd like from SIP?

Neither DNS nor a DHT provides solutions to these "Peer to Peer Session
Initiation" problems... they're just two different ways of tackling the
"given a key like a name, how do I get a (list of) value(s) like an IP
address or certificate" problem.

I agree that my client being able to look things up about another client is
a precondition of doing "P2P SIP" with that client, but I don't even think
that the lookup itself *is* "P2P SIP", much less that "P2P SIP" should
mandate a non-standard mechanism for doing it.

Matthew Kaufman
matthew at matthew.at

---

From: dbarrett at quinthar.com (David Barrett)
Date: Mon, 4 Dec 2006 10:30:18 -0800

I think this is the mental leap I haven't been able to make.  "Doesn't
depend on any provider" seems impossible.  At the very least, you need
someone to "provide" network access and electricity.  But don't we also need
someone to "provide" a namespace?

In other words, do you agree:

	1) P2P-SIP must guarantee that each name resolves to a single user

	2) Multiple users want the same name

If both of those are answered yes, then how can we avoid a "namespace
provider"?  DNS already does this today on a massive scale, and is available
everywhere real users are.  Why are we so desperate to avoid it?

What is the alternative namespace provider being presented, and why is that
preferable?  Remember: even certificate authorities require someone to
maintain the CA, and that's even more centralized than DNS.

-david

> From: Enrico Marocco [mailto:enrico.marocco at telecomitalia.it]
> Sent: Monday, December 04, 2006 2:26 AM
> To: David Barrett
> Cc: 'David A. Bryan'; 'P2P-SIP'

---

From: mah at inode.at (Michael Haberler)
Date: Mon, 04 Dec 2006 19:32:17 +0100

Matthew Kaufman schrieb:
> DHT. 
Amen.

I too fail to understand the conceptual and political difference between
"set of supernodes" and "set of root servers" IP addresses - both define
the entry point into a name resolution space.

It's shifting bottlenecks (if the DNS is viewed as such) - including the
downstream politics around the "single supernode set".

-Michael

---

From: dbarrett at quinthar.com (David Barrett)
Date: Mon, 4 Dec 2006 10:53:51 -0800

Everything you describe can be done with DNS.  Yes, you could create a
replacement to DNS that accomplishes the same thing with different
technology, and then fundamentally tie P2P-SIP to that instead.  It just
seems like a waste of time.

DNS already offers the foundation for the brilliant future you want to
create:

- Multiple, technically and legally independent providers
- Massive redundancy
- Massive scalability
- No single point of failure
- No dependency on any single legal entity
- International legal framework for conflict resolution

Using DNS is absolutely nothing like being tied down to a mobile provider.
Unlike my mobile phone, I can take my IP address to any DNS provider
whenever I want.

The "powerful shift" you're talking about already happened; the "overlay
access service" you want to create was created decades ago: it's called DNS,
its fee is paid from every internet account, and it's used by nearly every
internet application.  Think of it as the original P2P service.

I understand that people see DNS as having problems.  What I don't
understand is why it's assumed those problems will magically disappear when
we replace DNS with a fundamentally equivalent but technically more
complicated and completely untested service (that, incidentally, is based
upon DHT technology that is *already* obsolete).

Anyway, I accept P2P-SIP isn't going to go this direction.  I just haven't
heard any good explanation as to why, other than it's not "P2P" enough
(though what that means is unclear). 

To review: DNS can support every use case a DHT can support (minus the
impossible security standards set out in 3.2, which nobody can meet, though
it might be able to meet them "good enough" once it's clear what that
means).  It works everywhere real users are.  It can update fast.  It works
today.  It exists.

Unless we can do away entirely with namespace management (keydrives, or
perhaps emailing around public keys), we need something almost exactly like
DNS.

-david

> From: Henry Sinnreich [mailto:hsinnrei at adobe.com]
> Subject: RE: [p2p-sip] Where are we "getting wrapped around the DNS axle"
>

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Mon, 4 Dec 2006 14:04:49 -0500

>"Doesn't depend on any provider" seems impossible.  At the very least, you
need someone to "provide" network access and electricity."

Good comparison. Both are utilities. You need both.  Nothing else.  "But
don't we also need someone to "provide" a name space?"

Yes. But that can be my receptionist. Or an editor. Or a meeting
facilitator. Or a regional branch manager.   Or a parent-teacher group.
Or a political party, or a club with 100m members.   No provider is needed
when the namespace is declared by the application. Sorry.

The application decides when wrong the credential-provider is, not the
pipe.  Where is a network provider in this space?  Where could a network
provider be in this space?   DNS is not even wrong. It is not relevant,
because the network is a pipe but nothing else.

"In other words, do you agree:

"

In each overlay, yes. See above three times.  That is an application-level
responsibility.  Not a network responsibility. The network is a pipe.

"If both of those are anwered yes, then how can we avoid a "namespace
provider"?  DNS already does this today on a massive scale, and is available
everywhere real users are.  Why are we so desperate to avoid it?"

Again:  DNS doesn't exist in application namespaces.  It  time to decouple
the namespace provider from the service.  A network service provider can't
keep up with the application space, and doesn't want to in the same way that
the telecom provider won't keep up with the telecommunications boom.

Look at your garden variety PBX and tell my how much different it is from a
VAX,  while our desktops are now supercomputers. What a waste!

In P2P the namespace comes from the application, not the network.  The
network is a pipe.  The provider does not exist apart from that pipe.

My electric utility sells me electrons, it doesn't decide on what they are
used for.  In P2PSIP the network is the network but nothing more.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061204/4174a616/attachment.html

---

From: ag at ag-projects.com (Adrian Georgescu)
Date: Mon, 4 Dec 2006 20:23:58 +0100

David,

How do you sugest to implement a replacement of bidirectional  
signalling, nat traversal and data storage associated with a SIP AoR  
with a simple address resolution mechanism provided by today's DNS?

Adrian

---

From: dbarrett at quinthar.com (David Barrett)
Date: Mon, 4 Dec 2006 11:43:45 -0800

Bidirectional signaling: I'm sorry, I don't know what that means.

NAT traversal: Just like before.  My UA looks up your proxy by resolving
your domain name, it sends an INVITE, you receive it, and we do
STUN/TURN/ICE like before.

Data storage: You mean storing arbitrary data for each SIP AoR?  If this is
necessary, I say the P2P-SIP client maintains the master copy of whatever
this data is, and then it uploads it to the SIP proxy at REGISTER time.
Thus to look up the data for a given address, just look up the proxy and ask
it.

I think we should use DNS is we need to resolve names to IPs.  Anything
other than that probably isn't a good fit for DNS (though there *are* other
DNS records than IP, so perhaps those might fit in somewhere).

-david 

> From: Adrian Georgescu [mailto:ag at ag-projects.com]
> Sent: Monday, December 04, 2006 11:24 AM
> To: David Barrett
> Cc: 'Henry Sinnreich'; 'Enrico Marocco'; 'P2P-SIP'; 'David A. Bryan'

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 4 Dec 2006 12:11:36 -0800

Hi,

Me totally agree with David Bryan on this issue. Somebodies out there have
proved p2p concept without DNS and earned worldwide respects, so can p2p-sip
same way. Slow-propagating DNS should not be the first aid for node lookup.
Besides, has existing DNS infrastructure without significant
scability/stability upgrade been proven to be able to support millions of
churning nodes?

As for mobility of p2p nodes, I think it needs upgrade of existing routing
infrastructure to support ip mobility and it is not DNS related at all.

Thanks.

Peter

----- Original Message -----
From: "David A. Bryan" <bryan at ethernot.org>
To: "David Barrett" <dbarrett at quinthar.com>
Cc: "P2P-SIP" <p2p-sip at cs.columbia.edu>
Sent: Sunday, December 03, 2006 7:21 PM
Subject: Re: [p2p-sip] Where are we "getting wrapped around the DNS axle"

axle"

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Tue, 05 Dec 2006 12:20:05 +0100

> someone to "provide" a namespace?

You don't need anyone to provide network access in the ad-hoc case.  I
understand that currently it is a very niche, but since the IETF is so
interested to have two WGs focused on it, we cannot consider the ad-hoc
scenario out of scope.

> 	1) P2P-SIP must guarantee that each name resolves to a single user

Generally speaking, no.  The peer protocol must guarantee that the name
used by a user enrolled within an overlay could not be used by another
user in the _same_ overlay.  Then, if the overlay is also accessible
from the Internet, that name is also unique.  However, the latter case,
which is absolutely _optional_ and depends on the deployment, already
uses DNS as the "namespace provider", as specified in RFC 3263.

> 	2) Multiple users want the same name

Possibly, but if an enrollment mechanism is _deployed_ in the overlay
(please note that it may be standardized as for jabber, or not), only
the firstly enrolled user can use it.

-- 
Ciao,
Enrico

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Tue, 05 Dec 2006 12:21:24 +0100

> would be stored, one can send updated information to that node as often as

Come on, everybody agrees that when DNS is available both for
provisioning and for lookup, it is better to use it instead of fixed IP
addresses.  It's usage has been proposed and welcomed in many
discussions about bootstrap and interwoking (let me mention
draft-marocco-p2psip-interwork).

The goal of the working group is to specify the minimal set of tools for
managing decentralized overlays capable of routing SIP messages,
preventing identity thefts _within_ an overlay and providing a resource
discovery mechanism for NAT traversal.  It seems that people writing on
this list consider DHT as the most promising technology for achieving
that goal;  if you disagree, just describe your alternative based on
DNS, mDNS or whatever, and try to gather consensus in the way people in
IETF are used to (i.e. writing I-Ds).  On the other hand, if you
disagree not only on the technical solution, but also on the goal, since
it is stated in the charter -- the _contract_ between the WG and the
IESG -- I think you are in the wrong place.

-- 
Ciao,
Enrico

---

From: mlepinski at bbn.com (Matt Lepinski)
Date: Tue, 05 Dec 2006 10:22:54 -0500

I've seen the term "Obsolete" come up several times in this thread. In 
particular, it seems that some participants in this discussion 
(including David Barett whose post I quote below) believe that a DHT 
that uses a chord-like ring topology is an obsolete technology. If I 
understand correctly, the claim is that such DHT technology is incapable 
of dealing with the churn inherent in modern P2P use cases.

My question to David (or anyone else on the list who is knowledge about 
DHT technology) is:
Is it the "ring-topology overlay" which is has become obsolete? If so, 
it seems like we should be fine as long as we require our eventual 
protocol architecture to support an arbitrary DHT (and hopefully any 
mandatory-to-implement DHT that we specify can avoid the pitfalls of a 
ring topology).

Alternatively, is it the notion of a DHT that has become obsolete? If 
so, is there something inherent in DHTs that make them unsuitable for 
modern use cases?  In such a case, what requirements should we adopt for 
a P2P solution to avoid the problems inherent in DHTs.

Thanks a lot,
- Matt Lepinski :->

David Barrett wrote:

>>>Furthermore, yes, I'm assuming whoever you registered your DNS name
>>>      
>>>
>>with
>>    
>>
>>>provider.  This doesn't seem at all an unreasonable or unusual demand.
>>>      
>>>
>>With
>>    
>>

---

From: br at brianrosen.net (Brian Rosen)
Date: Tue, 5 Dec 2006 10:41:38 -0500

I see the discussion somewhat differently.  I don't think David Barett is
making a judgment call on the obsolescence of any form of DHT.  He is
arguing that DNS, and specifically dynamic DNS, is a better choice to use
for intra-overlay routing of messages.  It IS, undeniably simpler.

The question to the group is, does that solve our requirements?  I don't
think it does.  It may solve a different set of requirements, and I have
suggested that David et. al. write the idea up as an Internet Draft and
submit it to sipping.  It may be an interesting enough concept that it is
taken up as a fairly straightforward BCP thing that uses existing mechanisms
to get a different form of plan jane sip.

I do see your concerns about ring topology as informing our choice of one
mandatory to implement DHT.

Brian

> From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-
> bounces at cs.columbia.edu] On Behalf Of Matt Lepinski
> Sent: Tuesday, December 05, 2006 10:23 AM
> To: David Barrett
> Cc: 'P2P-SIP'
> Subject: Re: [p2p-sip] Avoiding Obsolete DHT Technologies
>

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue, 5 Dec 2006 11:30:09 -0600

> would be stored, one can send updated information to that node as  

I think that's the point I was trying to make. Where DNS is used to  
find a bootstrap node, either manual configuration or dynamic DNS  
could be used to insert the resource record for that bootstrap node  
into the DNS.

There may be other valid ways to find a bootstrap node than using  
DNS. For example, one might be configured statically, or one might  
use some sort of multicast service like zeroconf, UPNP, or some sort  
of undetermined layer-2 mechanism.

But this is a DIFFERENT PROBLEM than the central problem of P2PSIP.  
That problem, as I see it, is finding a SIP-level route to a node  
when that node may be both highly mobile and "on the other side" of  
multiple NAT and/or firewall boundaries from the node that is trying  
to contact it.

This requires more than a name-to-address lookup operation. It  
requires message routing along ephemeral "channels" that dynamically  
adapt to changing network topology. For those of you who are old  
enough to remember Token Ring, it's something like source-route  
bridging. But it's a lot harder than the problem scope of SRB,  
because the number of nodes is larger and the network topology is  
both more complicated and less stable.

--
Dean

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue, 5 Dec 2006 13:54:24 -0500

On 12/4/06, Jacky Mallett <warlock at media.mit.edu> wrote:

> The problem with this line of reasoning is that a network is not a pipe.
> That's the piece of cable from the back of your computer. The network is a
> system. And in the P2PSIP case, the problem is that the system is also a
> network.
>
> I think there's a misunderstanding underlying some of these exchanges as to
> exactly what a peer-to-peer system is, and what a network is, and why that
> matters. I understand that you're seeing a network just as the physical
> system that carries your packets, and that is correct at one level. However,
> once any distributed communicating system becomes large enough it takes on
> what can loosely be described as network properties, if we understand
> network in this sense of a distributed communicating system whose
> application is the communication of packets - such as the Internet, and not
> just the physical hardware.
>

I've been designing communications systems for over 20 years.  For
over 95% of business and consumers the  perspective  is of a
best-effort pipe. From an application perspective it is a pipe.  Once
you get behind a NAT the Internet is a pipe.  The stuff in the NAT? A
cheap cloud, a commodity. The pipe is not well-ordered, it is not
deterministic, performance is best effort and fractal.  The Internet
is what it is, and it is messy and chaotic.  It is largely impossible
for 'the network' to provide services end to end when the network is a
chaotic collage of disjoint backbones and meshes, except for a rare
few researchers governments and very large businesses.  For the rest
of us the Internet looks like 3 AM in the Bronx.

> If your device, whatever it is, has enough capacity to hold the addresses of
> every single other device in your application, then this doesn't matter. If
> there is a single server that is large enough to hold every other device's
> address then it doesn't matter (at least in terms of network considerations,
> single point of failure, phone company fascism problms etc. still apply,
> obviously.)

A sub-$1000 Dell notebook can hold the entire global PSTN dial plan,
the entire US portion can be stored in a cheap flash card.  Cheap
computers are now supercomputers while our providers are steampunk
relics that will never scale and keep up.

One billion dollars spent by one million end user P2P systems,  one
million Christmas shoppers or 0.3% of the US population, will go a lot
farther than one billion dollars spent on core infrastructure.  That
power of scale gives a 100x advantage to the end-nodes, and the
CPU/resource power of the end-nodes is growing very rapidly over time.

The aggregate CPU power of low-cost video-game systems being sold
_just this Christmas alone_ dwarfs the capability of _the entire
deployed infrastructure_ of all service providers wordwide,
_combined_.

It is obvious that the network can't keep up with applications. It is
even more striking when the entire infrastructure of the multi billion
dollar telecommunications empires can't keep up with video game
vendors, which can deploy and install an entire generation of new
equipment between Thanksgiving and New Year's.

The biggest threat to traditional network vendors isn't Huawei.

It is Nintendo.

>
> Any communicating system where that is no longer the case, be it the postal
> system, the phone book, DNS,  Skype, or whatever has to solve a routing and
> lookup problem within itself that is independent of the underlying physical
> network. There is no way round this, the underlying mathematics of these
> systems is rather firm on that point.
>

I fully agree with you there.  It is an essential core problem of P2PSIP.

> Yes, it is an application responsibility - but the application has just
> taken on important attributes of what is commonly called a network. A
> network is not a pipe. A network  is an emergent effect of a set of
> communication protocols between autonomously functioning nodes.

Indeed it is taking over the attributes of the network.  It must
because there is no one network, there is a hodgepodge of networks
over which traffic happens, and that hodge-podge has multidimensional
characteristics that change in terms of location, physical connection
and time.  The only solution to such situations are 'overlays' that
are self-organizing and that re-organize based on the given conditions
at the time.

In the absense of a single end to  network providing all those
attributes there is no option but to put them into the application.
The real protocols that matter at the low level, be they QoS, MPLS,
identity, or even basic routing and  the like, cannot be provisioned
or ordained by the user or the application at any cost, let alone with
automation and simplicity.  They are unavailable from the network in
any real sense.  They are reluctantly provided, if every, in any
commercial space.  However, they are needed. Hence they will come from
the application, and the application will be forced to guess and learn
where it is, what it can do, what it can talk to and how.   The
Internet is not deterministic. It never has been. That was the whole
point in the first place. The reality is despite delusions it never
will be, because that's not how things are organized in reality.

> I think it's arguable that DNS actually is decoupled from the service, if by
> service you mean the physical pipe.

Yes and no.  They are leashed together.  Full DNS service including
reverse lookup always requires co-operation from the people supplying
the end-node IP and the access to pipe.

> Let me suggest that whether or not an application chooses to implement its
> own namespace, or uses one conveniently provided by a well established
> existing system is up to the application. But that for any system that is
> sufficiently large, the resulting solution will look a lot like DNS. Either

Yes, but with insertion, deletion, content, refresh rate and scope
that is application oriented not low-level IP resolution oriented.
DNS is great for mapping static names to static IP addresses. It
should, because that is what it was designed for.  For the application
it is more than obsolete.

> you are below the group size limit, where all nodes can have direct
> knowledge of each other, (or through a central server), or you're above it
> where they can't. Once you're above it, DNS or something very like it, is
> the only solution - and again, this is dictated by the underlying
> topological and communication constraints on the system. So why reinvent the
> wheel here?

Because the application layer demands the ability to steer the wheel.

>
> This discussion isn't really about the underlying system providing you with
> packets, it's about those aspects of P2PSIP implementation where it takes on
> network properties, and whether or not services that have been developed to
> allow the underlying network to function can help solve those problems
> efficiently or not. There's a large network of power stations and cables
> behind delivering your electrons too, and i rather suspect if i took the
> network out of that equation, you might well find yourself strangely
> deficient of power, even though nothing had actually changed with the supply
> of electrons.

It's all about who controls what.

Power companies are filled with people that come from the command and
control world.  There is a big debate right now about the current
provider-to-customer grid vs. distributed network meshes where the
endpoints have much more control over where they get their power and
when.

P2PSIP is in the same fight.

Right now I don't have control over what generator made those
electrons, nor their price, nor where they come from.  However I can
put panels on my roof, use a wind-turbine, and store excess power in a
redox battery.  How I organize application of electricity should be my
choice.

Television and movie networks are in the same obsolete boat. They are
broadcasting when millions of people are playing Half Life right now,
and deciding what the game is by themselves.

The same flexibility should become available to applications using P2PSIP.

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 5 Dec 2006 13:35:41 -0800

> user in the _same_ overlay.

I'll grant it can be useful to have a totally unauthenticated, insecure
namespace where you can be Enrico for a while and then the moment you log
off I can log on as Enrico and be indistinguishable to everyone else.  I'd
wager this most often works in an ad hoc or "trade show" environment, where
mDNS is totally adequate.

However, I'm assuming a more valuable use case is an authenticated world
that has long-lived names verified in a secure manner.  And in this world,
DNS is totally adequate, for networks as small as a few fixed nodes in the
jungle, or as big as the entire internet.

What I'm waiting to hear about is a critical set of users who:

	- Don't need authentication
	- Can't use mDNS

Or, a critical set of users who:

	- Do need authentication
	- Can't use DNS

I'll totally grant we can construct a network to fit either of these.  For
the first, set up a network in the jungle and explicitly disable multicast.
For the second, set up a private network with a thousand nodes, and refuse
to install a DNS server (basically, disable all other network activity
except Gnutella and eDonkey).

But these don't seem like realistic use cases.  In the first, just tell
these jungle warriors "enable multicast" and they'll be fine.  In the
second, they're going to need a DNS server anyway, so just tell them to use
that.

> the firstly enrolled user can use it.

Until he logs off or temporarily loses network connectivity, in which anyone
can steal his name.  (Though I guess we could have him generate a private
key and the first to register a public key with a name "wins" and if you
lose that private key you're basically screwed because there's no "password
change" feature.)

-david

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 5 Dec 2006 13:44:26 -0800

> From: Brian Rosen [mailto:br at brianrosen.net]
> Subject: RE: [p2p-sip] Avoiding Obsolete DHT Technologies

> to get a different form of plan jane sip.

I agree it's not a wide departure from how SIP already works, and I think
that's a strength.  But I still don't see which use cases (other than the
extreme security ones) it fails to meet.

-david

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 5 Dec 2006 13:51:09 -0800

> From: Matt Lepinski [mailto:mlepinski at bbn.com]
> Cc: 'P2P-SIP'
> Is it the "ring-topology overlay" which is has become obsolete?

I won't pretend to be a DHT expert, but I don't think Chord has been proven
in the real world at any large scale, and has largely been superseded even
in research circles.  The only one that has been proven to work is Petar's
Kademlia (eDonkey, eMule, Overnet, etc), so if we're to pick any, that seems
like the place to start.

But my real point is that we shouldn't use a DHT at all if there are easier
options available that are already standardized, such as mDNS/DNS.

-david

---

From: br at brianrosen.net (Brian Rosen)
Date: Tue, 5 Dec 2006 17:41:27 -0500

I think the elephant in the room you keep ignoring is the desire to control
who can call me.  The point of an overlay network for many people is to
restrict who can get to me.  The security mechanisms inside a domain are a
whole lot different from the Internet as a whole.  By forcing use of DNS,
you are requiring that I set up some completely separate system to control
access to me.  Within a DHT, only people inside the domain (who have
credentials for the domain) can find out about me, find out how to contact
me, and actually make contact.  Now, admittedly, some of that is security by
obscurity that I don't subscribe to, but most if it is genuine security by
restricting access to people granted credentials in the domain.

Brian

> bounces at cs.columbia.edu] On Behalf Of David Barrett
> Sent: Tuesday, December 05, 2006 4:36 PM
> To: 'Enrico Marocco'

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 5 Dec 2006 15:51:23 -0800

I'm sorry, I don't follow.   The whole notion that someone else controls who
I can talk to (and can talk to me) is precisely *opposite* our goals.  If
your UA doesn't want to take calls from anyone outside of [email-masked], then
it has every ability to define, manage, and enforce that access control
policy at the edge.

Furthermore, if you for some reason don't want to control at the edge, it's
vastly *easier* to do it with normal directories than with certificates and
DHTs.

Perhaps you can give a real-world use case of what you're describing, and
explain how you'd intend to solve it with a DHT?  Then I can present how I'd
solve it with DNS/mDNS, and we can contrast which is more straightforward --
to implement, to administer, and to use.

DNS and DHT are equivalent services.  Both take a name, and spit out
information (generally IPs, though it can be a variety of records).  One is
a drop-in replacement for the other.  The only difference is one exists on a
massive, standard, secure, universal, global scale today, and the other
doesn't.

I think whatever DHT-based solution you present, if you do a search/replace
of DHT to DNS, that'll be basically what I'm proposing.

-david

> Sent: Tuesday, December 05, 2006 2:41 PM
> To: 'David Barrett'; 'Enrico Marocco'
> > > > 	1) P2P-SIP must guarantee that each name resolves to a
single
> user

---

From: br at brianrosen.net (Brian Rosen)
Date: Tue, 5 Dec 2006 20:02:15 -0500

Okay, let's walk through this:

Someone, doesn't matter who, starts up a domain called p2ps.com.  They put
up a website, and offer to give out credentials for their p2psip domain.
They have a membership, code of conduct, and policies you like, and a
business model you can deal with, so you sign up.

p2ps gives you a credential.  That credential will entitle you to join the
DHT.  If you don't have one, you can't join the DHT, and you can't find out
who else is in the domain, or how to contact them.  All the messages within
the DHT are encrypted, and the only way you can get at any of them is to
present credentials.  

When you place a call, to anyone in the p2ps domain, you present your
credentials issued by the domain with your INVITE.  You don't accept a call
from anyone without the domain credentials.  In fact, NO signaling will
enter any element within the domain without the proper credentials, and you,
as a peer, can validate the credentials of any DHT message or any SIP
message with those credentials.

Once you get the credential, the only centralized service needed is whatever
it is that allows the domain to revoke credentials, if any, and that can be
cached by the peers.  The name to address mechanism is impervious to a lot
of damage because nothing is authoritative save the credential; it's all
distributed.  Any isolated set of peers can communicate with each other, and
as soon as connections to another peer or set of peers is restored
communication with them becomes possible.

Brian

> From: David Barrett [mailto:dbarrett at quinthar.com]
> Sent: Tuesday, December 05, 2006 6:51 PM
> To: 'Brian Rosen'; 'Enrico Marocco'
> > me, and actually make contact.  Now, admittedly, some of that is
> security
> > by
> > > second, they're going to need a DNS server anyway, so just tell them
> to
> > > use
> > > that.
> > >
> > >

---

From: dbarrett at quinthar.com (David Barrett)
Date: Wed, 6 Dec 2006 00:07:39 -0800

Thank you for the detailed use case.  This is extremely helpful.  Yes, I can
see how that would work entirely.

However, that is the exact scenario that classic SIP is designed to excel
in.  I totally accept that you could provide a functionally equivalent
solution to DNS using a DHT.  What I don't understand is why you would put
in the extra work to do so when a perfectly adequate solution already
exists.

Can you help me understand why classic SIP is inadequate in this scenario?

I can't imagine scalability being your concern.  Today, in the real world, I
have 600MHz, single-CPU, 512MB boxes so ancient you can buy anymore, and
they can handle over 16,000 simultaneous TCP connections on each.  For
$100/mo (800Hosting.com) you can rent a dedicated server far more powerful,
hosted in a very reliable datacenter.  (These aren't SIP servers, but their
performance characteristics are very comparable.)  Assuming 2-3x the
simultaneous users are offline at any point in time, it seems sensible to
expect that whatever business model in place can earn at least $100/mo from
the 100K+ users that a single server can easily support.

I can't imagine performance being the problem, because any decent central
server will do call lookups and authentication checks orders of magnitudes
faster than a DHT (in the most basic sense, O(1) versus O(log(N)) for any
operation). 

And I can't imagine security being the problem, because a central directory
is much easier to maintain and faster to correct than any decentralized
system.  It is both simpler and more secure.

My impression was that P2P-SIP was going to take SIP to places it can't go
already.  If we're merely retreading the same ground a different way, I
think there must be a very compelling problem with the existing solution to
demand it, and I don't see it.

Can you give a more challenging use case that better leverages the strengths
of P2P?  Perhaps something involving users who sometimes are on the internet
and sometimes on a private network, or perhaps users who have a domain that
points to a hosted blog provider and can't run a SIP server?  Because the
use case as given is precisely what DNS and classic SIP excels at most.
  
-david

> Sent: Tuesday, December 05, 2006 5:02 PM
> > solve it with DNS/mDNS, and we can contrast which is more
> straightforward
> > --
> > a drop-in replacement for the other.  The only difference is one exists
> on
> > a
> > > restrict who can get to me.  The security mechanisms inside a domain
> are
> > a
> > > obscurity that I don't subscribe to, but most if it is genuine
> security
> > by
> > > > namespace where you can be Enrico for a while and then the moment
> you
> > > log
> > > > off I can log on as Enrico and be indistinguishable to everyone
> else.
> > > I'd
> > > > wager this most often works in an ad hoc or "trade show"
> environment,
> > > > where
> > > > DNS is totally adequate, for networks as small as a few fixed nodes
> in
> > > the
> > > > I'll totally grant we can construct a network to fit either of
> these.
> > > For
> > > > Until he logs off or temporarily loses network connectivity, in
> which
> > > > anyone

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 6 Dec 2006 12:00:36 -0800

> use case as given is precisely what DNS and classic SIP excels at most.

For 100K+ simultaneous online users, may I give you this as a case? Will you
need more than $100/month to offer network bandwidth for centralized
voicemail service?

Another is rtp media relay when clients are behind NATs that forbid direct
media flow between the clients.

I'm not sure if the cost and server complexity can grow linearly or even
exponentially when user number hits millions.

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Sat, 9 Dec 2006 03:37:04 -0600

You seem to be missing the point.

You CANNOT put, using anything like current resource records, a multi- 
hop SIP route into DNS.

Furthermore, you cannot make DNS return a different route from Alice  
to Bob than from Charlie to Bob.

So when Alice needs to route her requests through U, V, and W to  
reach Bob, but Charlie needs to route his requests through X, Y and Z  
to reach Bob, DNS (or mDNS) or anything vaguely DNS-like is a  
completely inappropriate tool for discovering those routes.

Sure, it works to use DNS to discover the thing that will help you  
find an entry into the routing topology (which we seem to be calling  
a "bootstrap"), and DNS works for some subset of the P2P problems  
when one assumes artificially simple topologies, but DNS is NOT an  
answer for the general problem here.

--
Dean

On Dec 5, 2006, at 3:35 PM, David Barrett wrote:

> you log
> else.  I'd
> environment, where
> in the
> these.  For
> which anyone

---

From: dbarrett at quinthar.com (David Barrett)
Date: Sat, 9 Dec 2006 03:56:24 -0800

You might consider googling "DNS MANET" and see the variety of interesting
resources on how the DNS problem has been solved for MANET networks.  The
first in the list is:

http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-j
eong-manet-dns-service-00.txt

  "This document specifies an architecture of DNS service system for 
   mobile ad hoc network which might be connected to the Internet.  The 
   resolution of DNS names of mobile nodes within mobile ad hoc network 
   is performed by multicast DNS and that of DNS names of nodes in the 
   Internet is performed through DNS autoconfiguration of recursive DNS 
   server."

I'm not sure what we're arguing about.  I'm saying if you want to resolve
names to IP addresses, DNS does it, for virtually every type of network
invented, including MANET.  It's been doing the trick a million times a
second for decades, all over the world.  Given this, I'm employing the
logic:

- SIP uses names
- SIP uses IP addresses
- SIP should use DNS to resolve names to IP addresses whenever possible
- DNS works everywhere
- Maybe SIP should use DNS everywhere for name/IP resolution.

Where does this logic break down?

People will continue to invent new types of networks in the future.  And I
don't doubt that with more digging we can come up with a network that
doesn't currently have a clear answer to how DNS will be supported.

But any network that hopes to be adopted in any real way needs to support
DNS, else users won't use it.  Every major network application (email, web,
ftp, ssh, etc) uses DNS, so it seems extremely probable that every network
that will come out in the near or even far future will have some support for
DNS.  We've seen this pattern happen with private networks, with ad hoc
networks, and now with multi-hop ad hoc networks.  I can't visualize what's
more extreme than that (interplanetary links?) but I'd wager DNS will be fit
into that somehow, too.

The best way to future-proof SIP is to just use DNS.

-david

PS: As for multi-hop routing, while I'm certainly not the expert on this
subject, I thought MANET worked at the IP level.  To the application,
everything is still IP addresses.  Thus any facility for using SIP to create
a virtual multi-hop channel wouldn't be necessary, because MANET does the
multi-hop one layer down.  In other words, everyone in a MANET network still
has a normal IP address, so we're back to the problem of resolving names to
IPs, which DNS does exquisitely.

> From: Dean Willis [mailto:dean.willis at softarmor.com]
> Sent: Saturday, December 09, 2006 1:37 AM
> To: David Barrett
> Cc: 'Enrico Marocco'; 'P2P-SIP'; 'David A. Bryan'