Subject: [P2PSIP] Concepts issue: Domains and Overlays

From: Dean Willis <[email-masked]>
Date: Wed, 13 Jun 2007 18:00:24 -0500

Someone brought this up on the list, and I wanted to clarify the  
consensus here before nailing it down further in the concepts doc.

We think of usernames as domain-scoped, like "[email-masked]".

One model of an overlay allows users to enroll names from many  
domains. In this model, there might be only one overlay serving every  
domain in the world, including (for example) "example.com" and  
"example.net". Clearly routing messages within this overlay is  
straightforward, and there's no need to talk to any other overlay.

In another model, each overlay corresponds to one or more but not all  
domains, and we use RFC 3263 procedures to route between overlays. So  
"example.com" might be in one overlay, and "example.net" in another.  
Each overlay can look up the other in DNS to find it.

This second model mostly precludes having one domain scattered across  
multiple overlays.

Here's the deal: Assume we have overlays A and B. [email-masked]  
enrolls with overlay A, and [email-masked] enrolls with overlay B.

Alice now wants to call Bob. She looks him up in her overlay, and  
he's not there. What to do? She can't just look up example.com in  
DNS, because it has been split across A and B and DNS just doesn't  
work that way. Now, if both A and B registered with some "upstream"  
lookup function (a meta-overlay), then Alice could perhaps look  
there. But this starts to get messy really quickly.

So unless we want to solve the namespace-split-across-overlays  
problem (and that's not easy), we're much better off at this time  
having a model where each domain can be mapped onto only one overlay  
at a time.

Y'all ok with that?

--
Dean

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Jun 2007 20:04:13 -0400

I generally agree with your train of thought until it derails in the  
last paragraph, I think. A slightly weaker requirement that also  
works and is useful is to require that each domain has a "default"  
overlay that one must register with if it is available. There is  
nothing wrong with registering in wild-card domains for special  
purposes. For example, this can occur when such an overlay is  
disconnected from the Internet at large. Would you want to set up a  
per-domain overlay for each and every AOR domain in that case? (I  
realize that detecting this case can get messy, but this largely  
depends on how we solve the overlay discovery problem.)

Henning

On Jun 13, 2007, at 7:00 PM, Dean Willis wrote:

> domains. In this model, there might be only one overlay serving  
> every domain in the world, including (for example) "example.com"  
> and "example.net". Clearly routing messages within this overlay is  
> In another model, each overlay corresponds to one or more but not  
> all domains, and we use RFC 3263 procedures to route between  
> overlays. So "example.com" might be in one overlay, and  
> "example.net" in another. Each overlay can look up the other in DNS  
> to find it.
>
> This second model mostly precludes having one domain scattered  
> across multiple overlays.
>
> having a model where each domain can be mapped onto only one  
> overlay at a time.
>
> Y'all ok with that?
>
> --
> Dean
>
>

---

From: Isaias Martinez Yelmo <[email-masked]>
Date: Thu, 14 Jun 2007 15:33:27 +0200

Hello,

I agree with you, it has no sense to split a domain in two different overlays. 
However, I'm not completely sure if it is a good idea to define an overlay 
per each p2psip domain and to use a hierarchical approach to interconnect all 
the domains with DNS.

I think that the concept that you define as meta-overlay will be the way to 
interconnect the different p2psip domains and not to use the DNS 
infrastructure. I am studyin my research topic on this line of work.

Regards,

Isaias

-- 
Isaias Martinez Yelmo
Universidad Carlos III de Madrid
Departamento de Telemática
http://www.it.uc3m.es/~imyelmo
Asociación de Telématica:
http://www.telematica.ws
http://www.netcoms.net
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 14 Jun 2007 09:14:48 -0500

Henning Schulzrinne wrote:
> last paragraph, I think. A slightly weaker requirement that also  works 
> and is useful is to require that each domain has a "default"  overlay 
> that one must register with if it is available. 

So, extrapolating from Dean's example and your thoughts above, Bob
would register with overlay B and also with the "default" overlay
for his domain (example.com).  When Alice calls Bob, her peer first
searches for Bob in overlay A (Alice's overlay), and not finding Bob
there continues to search for him in the "default" overlay.

Essentially, a peer would have to maintain and refresh
two registrations -- one to their assigned overlay, and the other
to the "default" overlay (and the other peers in the DHT would need
to maintain and possibly replicate two registrations.)  Yes?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 14 Jun 2007 10:24:35 -0400

Uh huh, that's the way I thought it worked.

<with my individual hat on>

Brian

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Wednesday, June 13, 2007 7:00 PM
> To: P2PSIP Mailing List
> Subject: [P2PSIP] Concepts issue: Domains and Overlays
> 
>

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 14 Jun 2007 09:37:56 -0500

Much like Brian's response - Dean described the way I thought this worked.

I do like Henning's suggestion, although I'm not sure we're ready for 
engineering yet - if you disconnect from the Internet at large, then set up 
special overlays based on being disconnected, then reconnect (ignoring the 
imprecision of "disconnecting from and reconnecting to the Internet), would 
we expect the special overlays to self-destruct?

I'm not sure what our consensus is about going the other way - can three or 
four domains participate in a single overlay? Or did I miss a conversation?

Thanks,

Spencer

From: "Henning Schulzrinne" <[email-masked]>

>I generally agree with your train of thought until it derails in the  last 
>paragraph, I think. A slightly weaker requirement that also  works and is 
>useful is to require that each domain has a "default"  overlay that one 
>must register with if it is available. There is  nothing wrong with 
>registering in wild-card domains for special  purposes. For example, this 
>can occur when such an overlay is  disconnected from the Internet at large. 
>Would you want to set up a  per-domain overlay for each and every AOR 
>domain in that case? (I  realize that detecting this case can get messy, 
>but this largely  depends on how we solve the overlay discovery problem.)
>
> Henning
>
>> One model of an overlay allows users to enroll names from many  domains. 
>> In this model, there might be only one overlay serving  every domain in 
>> the world, including (for example) "example.com"  and "example.net". 
>> Clearly routing messages within this overlay is  straightforward, and 
>> there's no need to talk to any other overlay.
>>
>> Alice now wants to call Bob. She looks him up in her overlay, and  he's 
>> not there. What to do? She can't just look up example.com in  DNS, 
>> because it has been split across A and B and DNS just doesn't  work that 
>> way. Now, if both A and B registered with some "upstream"  lookup 
>> function (a meta-overlay), then Alice could perhaps look  there. But this 
>> starts to get messy really quickly.
>>
>> So unless we want to solve the namespace-split-across-overlays  problem 
>> (and that's not easy), we're much better off at this time  having a model 
>> where each domain can be mapped onto only one  overlay at a time.
>>
>> Y'all ok with that?
>>
>> --
>> Dean
>>
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Jun 2007 11:10:36 -0400

We'd have to define a predictable ordering of what to do when  
presenting with a SIP URI, comprising at least

- RFC 3263
- the domain-specific overlay
- zero or more "generic" overlays
- non-overlay mechanisms, such as Bonjour

This doesn't seem to be too hard, as long as a single AOR is unique.  
[email-masked] should be one logical entity, although there is the  
practical issue that the set of devices associated with that AOR may  
well differ among the four resolution mechanisms.

Henning

On Jun 14, 2007, at 10:14 AM, Vijay K. Gurbani wrote:

>> I generally agree with your train of thought until it derails in  
>> the  last paragraph, I think. A slightly weaker requirement that  
>> also  works and is useful is to require that each domain has a  
>> "default"  overlay that one must register with if it is available.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 14 Jun 2007 11:26:19 -0400

I'm sorry, but my head is hurting.  It does that when I'm completely
clueless, as I am here.  I'm sure most of you just looked at this and said
"of course".

I need to go back to first principals.

Can we just forget clients for a sec?  Alice has a full peer implementation
in the example.com domain.  What is Alice's AoR (what is the scheme for
example?  How does another peer resolve that AoR to the protocol, IP
address, etc. needed to create a session with Alice?  Assume that peer is
very well connected and lives on multiple overlays, as well as several
direct SIP C/S domains.

I mean, if it's sip:[email-masked], then the peer is going to do an SRV
lookup at example.com for a sip server and try C/S, right?  RFC3263

Are you expecting that to fail?

Then what happens?

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, June 14, 2007 11:11 AM
> To: Vijay K. Gurbani
> Cc: P2PSIP Mailing List
> Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Jun 2007 11:31:06 -0400

On Jun 14, 2007, at 10:37 AM, Spencer Dawkins wrote:

> I do like Henning's suggestion, although I'm not sure we're ready  
> for engineering yet - if you disconnect from the Internet at large,  
> then set up special overlays based on being disconnected, then  
> reconnect (ignoring the imprecision of "disconnecting from and  
> reconnecting to the Internet), would we expect the special overlays  
> to self-destruct?

The special overlay may indeed go away if the nodes leave (or you may  
leave it).

>
> I'm not sure what our consensus is about going the other way - can  
> three or four domains participate in a single overlay? Or did I  
> miss a conversation?

I think this is really a discovery problem. As long as we have a rule  
of how UAs proceed along a path of discovery and registration, the  
outcome should be predictable, with only minor complexity increase.  
We'll already have to deal with at least two ways to resolve an AOR,  
3263 and overlay, plus likely a third, multicast-one.

I don't see why two domains couldn't share the same overlay. They  
wouldn't seem to collide or even be visible to each other. If I know  
to look for [email-masked] on overlay A, and [email-masked] is also  
on overlay A, I don't really care.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Jun 2007 11:38:33 -0400

The AOR now takes on essentially two meanings:

(1) something that gets fed into the 3263 algorithm, dissected into a  
user part and domain part, and then proceeds through a recursive  
resolution process (. -> com -> example.com, via NAPTR and SRV, etc.)

(2) an identifier that only has to be unique and simply gets hashed.  
In theory, I wouldn't even care if example.com is  a domain name. If  
it weren't for SIP URL syntax rules, using my postal address would  
work just about as well, as long as we can both agree on the format  
and ordering. (I'm not suggesting that we do anything except AORs,  
but wanted to highlight the distinction.)

We do need to define the structure of the identifier that's input  
into the hash function. Is it sip:[email-masked] or just  
[email-masked]? What about various SIP URL parameters? Is  
sips:[email-masked] different from sip:[email-masked]?

Thus, once (1) fails, you proceed to look up the identifier in all  
available overlays. There are two ways to do that: proceed until you  
find one mapping and then stop, or gather all candidate resources  
across all overlays and essentially "fork" the call across these.

We have implemented a simple version of this in OpenWengo and it's  
not terribly hard.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 14 Jun 2007 12:28:04 -0400

Okay, so if I understand what you are saying, the idea is that we have this
"if 3263 fails, try this" idea that maybe the user is on some random p2psip
overlay, and the sending peer should blindly try any or all of them that it
has access to see if it can get a message to Alice.

That seems pretty dumb to me, but maybe I'm the weird one.

I would think we would want to have some more definitive way to know which
overlay(s), if any, the domain of the AoR was on.

Frankly, I think example.com should say which overlays its domain may be
resolved it, by some kind of DNS record.   Further, it would be very
annoying that you had a SIP AoR, with a domain, but there was no SRV that
supplied a sip service in that domain.  The domain DOES have a sip service,
but its p2psip, not c/s sip.  Somehow, I think we should be more explicit.

My head is hurting less, but I don't like the answer much.

Was everyone else thinking it works the way Henning describes it?

I want to get back to the sip client idea, just blindly accepting the
mechanism works as described.  In the example above, Alice has credentials
in the overlay.  Now suppose Alice is C/S, connected to a proxy peer.

Does Alice have credentials in the overlay?
The proxy does, for sure.
How do I address a message to Alice now?  How does anyone figure out the
identity of the proxy peer so the overlay can be used to contact it in order
for it to relay sip messages to Alice?

Brian

> Sent: Thursday, June 14, 2007 11:39 AM
> To: Brian Rosen
> Cc: 'Vijay K. Gurbani'; 'P2PSIP Mailing List'

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 14 Jun 2007 11:36:41 -0500

Henning Schulzrinne wrote:
> (2) an identifier that only has to be unique and simply gets hashed.  In 
> theory, I wouldn't even care if example.com is  a domain name. If  it 
> weren't for SIP URL syntax rules, using my postal address would  work 
> just about as well, as long as we can both agree on the format  and 
> ordering. (I'm not suggesting that we do anything except AORs,  but 
> wanted to highlight the distinction.)
[...]
> across all overlays and essentially "fork" the call across these.

Shouldn't (2) happen first in a P2P network?  In other words,
ISTM that DNS et al. via rfc3263 should kick in *after* the
overlay lookup has failed

My model is that when a peer joins, it only knows its bootstrap
node.  The bootstrap node tells the peer the name of the overlay
and other associated logistics (joining peer, other servers like
STUN server, etc.)  At this point, I really do not understand
how the overlay name gets chosen and how it is represented --
flat?  hierarchical?  But, I will consider that a detail to
be worked out later.

If it is a pure P2PSIP peer and only interested in communicating
with other peers in that overlay, it won't register anywhere else.
If it is interested in also communicating with C/S SIP user agents,
it will also register itself into the "default" overlay for its DNS
domain, allowing C/S SIP clients from the same DNS domain or
other DNS domains to look it up using rfc3263.

Thanks,

- vijay

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Jun 2007 12:54:51 -0400

> overlay lookup has failed

I don't much care about the order. Arguments can be made either way.  
For example, "stealing" somebody's registration is probably easier in  
P2P, but it is less attractive a target if the 3263 is followed first.

> node.  The bootstrap node tells the peer the name of the overlay

There may not always be a single bootstrap node. Bootstrap could in  
some scenarios, such as a corporate network, rely on other service  
discovery mechanisms. Having a single bootstrap node means having a  
single point of failure.

I think we need to have a broader discussion as to whether we assume  
a functioning DNS (and access to that). One of the applications we  
have talked about is usage during emergencies, where this is probably  
not a given.

Henning

---

From: "Eric Cooper" <[email-masked]>
Date: Thu, 14 Jun 2007 12:17:56 -0400

I'm in favour of keeping it simple (one domain == one overlay), but I don't 
see a mechanism for enforcing it.

As Henning mentioned, I think it all depends on how you locate overlays.

Perhaps the mechanism for locating overlays could enforce the 1:1 mapping, 
but there's always the possibility that the overlay is disconnected from the 
mechanism.

Best Regards,

Eric.

----- Original Message ----- 
From: "Dean Willis" <[email-masked]>
To: "P2PSIP Mailing List" <[email-masked]>
Sent: Wednesday, June 13, 2007 7:00 PM
Subject: [P2PSIP] Concepts issue: Domains and Overlays

> "example.com" might be in one overlay, and "example.net" in another.  Each 
> overlay can look up the other in DNS to find it.
>
> not there. What to do? She can't just look up example.com in  DNS, because 
> it has been split across A and B and DNS just doesn't  work that way. Now, 
> if both A and B registered with some "upstream"  lookup function (a 
> meta-overlay), then Alice could perhaps look  there. But this starts to 
> get messy really quickly.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 14 Jun 2007 14:23:37 -0400

While I have not thought on this as deeply as some, I think that the 
idea of randomly trying the variously overlays one knows of to look 
for party seems deeply flawed.

It seems like there needs to be a way to go from an AoR to at least 
one likely candidate overlay, and a way to find an entry point to 
that overlay even if one normally doesn't participate in it.
One can bend things in interesting ways if that location function is 
itself a function provided by ones preferred overlay.  But it still 
has to happen, and happen in a way that is not dependent on the DHT 
functions themselves.  (Please, let's not duplicate all of the global 
delegation infrastructure into the DHT.)

It does seem that any given domain ought to be primarily handled by a 
some specific overlay.  That overlay might handle several domains (so 
it is not 1:1.)  The ability to create ad-hoc overlays is clearly 
required.  And one would clearly prefer not to have to create domain 
names and AoRs just for that.  However, the binding authentication 
gets MUCH more complicated.  And one starts down the slope of having 
to try candidate overlays to see where someone is.  Maybe some means 
of recording in ones home overlay that one is also in some specific 
other overlay would work?

Yours,
Joel M. Halpern

At 12:17 PM 6/14/2007, Eric Cooper wrote:
>I'm in favour of keeping it simple (one domain == one overlay), but 
>I don't see a mechanism for enforcing it.
>
>Perhaps the mechanism for locating overlays could enforce the 1:1 
>mapping, but there's always the possibility that the overlay is 
>disconnected from the mechanism.
>
>Best Regards,
>
>Eric.

---

From: Dean Willis <[email-masked]>
Date: Thu, 14 Jun 2007 14:07:46 -0500

On Jun 13, 2007, at 7:04 PM, Henning Schulzrinne wrote:

> There is nothing wrong with registering in wild-card domains for  
> special purposes. For example, this can occur when such an overlay  
> is disconnected from the Internet at large. Would you want to set  
> up a per-domain overlay for each and every AOR domain in that case?  
> (I realize that detecting this case can get messy, but this largely  

In this case, I'd put everybody into one domain.

The real problem happens when this disconnected overlay you are  
proposing suddenly regains connectivity to the Internet, or when it  
gains connectivity to another overlay.

If we're routing between overlays based on the "domain parts" of  
names, then we're in a quandary whenever a given domain (aka  
namespace) exits in two or more discrete chunks, whether those be  
inside overlays or as partitions of a conventional domain.

Let's revert back to thinking about conventional SIP for a moment.  
Presume we have domain "example.com", and users Alice and Bob, and  
two proxy/registrars A and B, both of which think they are the only  
proxy/registrars for "example.com". Therefore, example.com is  
partitioned.

Alice registers at A, Bob registers at B. Alice can't call Bob,  
because the only proxy/registrar she knows about doesn't know Bob  
exists. Same for Bob, who can't call Alice.

Sure, for the two-proxy problem, one proxy could always assume that  
any name it doesn't recognize is at the other proxy, but this quickly  
breaks down as the number of proxies increases. To make this work in  
the general n-partition case, we'd need a way for the proxies to  
discover each other and learn which part of the namespace is being  
held by each other. Further, we need to keep track of this topology  
as the connections between overlasy shift. Basically, we're talking  
dynamic routing on a per-name, not per-domain, basis.  Note that  
conventional SIP doesn't have anything like this today, but good-old  
spanning tree ethernet does, and we understand the limits of that  
pretty clearly, and it's not reaching the kind of size/space/time  
constraints we're dealing with in large overlays.

So unless you can convince folks that we're really prepared to  
develop a unified theory of per-name SIP dynamic routing that  
encompasses both conventional and client-server SIP, I strongly  
suggest we restrict ourselves to the cases in which namespaces are  
not partitioned and we can use RFC 3263 between namespaces.

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Jun 2007 15:55:51 -0400

I don't think the problem is as hard as you make it to be. I  
specified a reasonable set of steps that try out a, typically very  
small, number of possibilities. This isn't fundamentally different  
from trying different DNS record types, for example.

My concern is that insisting on 3263 isn't likely to work in many  
applications where P2P actually matters beyond buzzword compliance,  
namely in infrastructure-challenged environments.

Henning

On Jun 14, 2007, at 3:07 PM, Dean Willis wrote:

>> up a per-domain overlay for each and every AOR domain in that  
>> case? (I realize that detecting this case can get messy, but this  
>> largely depends on how we solve the overlay discovery problem.)
>
> any name it doesn't recognize is at the other proxy, but this  
> quickly breaks down as the number of proxies increases. To make  
> this work in the general n-partition case, we'd need a way for the  
> proxies to discover each other and learn which part of the  
> namespace is being held by each other. Further, we need to keep  
> track of this topology as the connections between overlasy shift.  
> Basically, we're talking dynamic routing on a per-name, not per- 
> domain, basis.  Note that conventional SIP doesn't have anything  
> like this today, but good-old spanning tree ethernet does, and we  
> understand the limits of that pretty clearly, and it's not reaching  
> the kind of size/space/time constraints we're dealing with in large  
> overlays.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 14 Jun 2007 16:27:59 -0400

Okay, let's talk about those environments.  I like them, and want p2psip to
work in them.

I assume we all are expecting that we don't have DNS.

I assume that we have the IP Address (not a domain name) of one or more
bootstrap peers.

I assume we have credentials for the overlay, and furthermore that each peer
can validate those credentials without needing some other service

I assume we have our own IP address, and an AoR, which for this purpose is
just a string we can hash.

Where is the problem?  Even if we started at 3263, that fails.  We go to the
bootstrap server, present our credentials and get admitted into the overlay.
We try to connect to our buddy, and if he is on the overlay, we find him.

What won't work without a lot of assumptions we don't want to make is proxy
peers, and inter-overlay routing, and other stuff.  But p2p will work, as
long as the credentials are accepted in the absence of any kind of service
to assist in validating them.

I still think in more benign environments, we want more explicit
declarations of what overlays a domain supports, and not a "try them all and
see what happens" mechanism.

Getting back to your message, I don't think it's necessarily a very small
number.  Just consider that I CURRENTLY have 7 or 8 active IM accounts.  If
they were all peer to peer, I could be broadcasting your AoR in all of them
trying to find you.  That seems silly, and not scaleable, because some of
those overlays are very big, and I don't want lots of "try them all"
messages zinging around.

Brian
> Sent: Thursday, June 14, 2007 3:56 PM
> To: Dean Willis
> Cc: P2PSIP Mailing List

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Jun 2007 17:18:24 -0400

Brian,

If I'm understanding you correctly, the difference between what you  
wrote and what I proposed is minor. You seem to propose ONE "wild  
card" (i.e., non-DNS) overlay that is contacted after the normal 3263  
mechanism fails. I didn't specify the number of such overlays and I'm  
not sure that it needs to be exactly one and no more, but that seems  
to be more of a matter than degree than principle. (Practically  
speaking, I expect the number of such 'disconnected' overlays that  
are of interest to a client to be very small, as there's little gain  
in having a lot of them; they could occur "naturally" when mobile  
networks split and merge.)

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 14 Jun 2007 17:58:42 -0400

If you have multiple sets of bootstrap servers, and multiple sets of
credentials for multiple overlays, you can join as many as you like.  I
think that might be dozens for lots of users.

I think the question is, are you broadcasting in all of them to look for a
hit when contacting someone, or is there a more deterministic algorithm?

I probably would not object to a broadcast in the case of an ad hoc network
with no DNS.  In that environment, while you may have several overlays you
could join, there is likely to be only a couple you have addressability to
in that environment.  I would prefer to not use that in a more connected
environment.

Brian

> Sent: Thursday, June 14, 2007 5:18 PM
> To: Brian Rosen
> Cc: P2PSIP Mailing List

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Jun 2007 19:47:16 -0400

> hit when contacting someone, or is there a more deterministic  

You clearly don't want to have to go hunting around in some random  
collection of overlays, so the algorithm should be fairly deterministic.

> in that environment.  I would prefer to not use that in a more  

I generally agree, but would add that a UA may not know which  
environment it finds itself in until it tests reachability. We  
presumably don't want to manually configure UAs.

I think a reasonable algorithm is that a node tries 3263, discovers  
(a typically small) number of overlays and searches those, with the  
notion that all participants within the disconnected network will be  
using the same one or two.

I don't see the need to go into great amounts of details for the  
initial discussion, but we shouldn't preclude this mode of operation.

Henning

---

From: Dean Willis <[email-masked]>
Date: Fri, 15 Jun 2007 01:30:09 -0500

> Are you expecting that to fail?

In my current worldview, if the peer knows it is participating in an
overlay that addresses the namespace "example.com", the peer looks up
Alice in its overlay. If not (or perhaps if the overlay lookup fails) it
fails, then the peer either does a 3263 resolution itself, or finds a
peer node offering "proxy service" to do the 3263 resolution for it.

I believe Henning is implying a model where if the "local" overlay
fails, we then repeat the lookup operation using either the "meta"
overlay, or by asking a peer that does "meata proxy" to do it for us.
Said  "meta" lookup might then revert to RFC 3263.

--
Dean

---

From: "Greger V. Teigre" <[email-masked]>
Date: Fri, 15 Jun 2007 15:26:03 +0200

While following this thread, I was trying to apply the various 
approaches to a use case Henry (Sinnreich) brought up during VON Europe: 
(from memory) "You go to the shop and buy a phone you like out of a 
selection the shop has. You plug it in when you come home using your 
family domain, and it just works."

My elaboration: I assume that this use case implies that vendor A and 
vendor B each has a bootstrap server, which each device will connect to. 
This may imply one or two different overlays.
I can easily see how people with the same domain in their email address 
can buy devices from different vendors (ex. company email address or 
maybe even gmail.com).

Can we declare that [email-masked] registering on a device from vendor A 
and [email-masked] registering on a device from vendor B both should end 
up in the same overlay?

Does that mean that the bootstrap servers of vendor A and vendor B need 
to direct each device to a different overlay?

Is the overlay for a given domain in some way calculated and then 
registered if the domain doesn't already exist in an overlay?

If not, and the two exist in two different overlays determined by (in 
this example) the vendor, I cannot see how we get out of it in a good 
way (without some kind of lookup).

Is there something I don't see here?! Or is this use case something that 
should not be supported?
g-)

Dean Willis wrote:
> because it has been split across A and B and DNS just doesn't work 
> that way. Now, if both A and B registered with some "upstream" lookup 
> function (a meta-overlay), then Alice could perhaps look there. But 
> this starts to get messy really quickly.
>
> (and that's not easy), we're much better off at this time having a 
> model where each domain can be mapped onto only one overlay at a time.
>
> Y'all ok with that?
>
> -- 
> Dean
>
>

---

From: "Eunsoo Shim" <[email-masked]>
Date: Mon, 18 Jun 2007 00:30:38 -0400

What Dean wrote in the initial email starting this thread has been what I
thought.
To put Henning's point in my way, the question is what we do if DNS is not
available.
For example, in a wireless ad-hoc network without connectivity to the
Internet or DNS.
How can [email-masked] talk to [email-masked] using p2psip if possible
in such an environment?

Even though I like the simplicity of 1:1 mapping between domain and overlay,
such restriction does not look helpful in this case. So we'd better allow at
least one overlay to support multiple domains (or allow nodes of multiple
domains to participate in the same overlay).

A node should be allowed to start a new overlay if it cannot discover any
existing overlay it can use. This means a domain may split into multiple
disconnected overlays. This is unavoidable if the nodes of the same domain
are split into isolated networks. Then we would also need a mechanism to
merge the nodes of the split domain into one overlay. This sounds somewhat
scary.

If we allow nodes to use only one "default" overlay in addition to their own
"regular" overlay, things don't look so complex.
Here the "regular" overlay means the overlay the nodes of the particular
domain should try to participate in at their best (probably MUST if they
have connectivity to the DNS).
The "default" overlay means an overlay created and used whenever a node has
no connectivity to the DNS. Thus nodes of any domain can participate in the
"default" overlay. Since there can be many isolated networks, there may be
many physically separated/disconnected "default" overlays.

In this approach, a node will create or join its "regular" overlay if it has
connectivity to the DNS. If not, then it will create or join a "default"
overlay. That is, it won't create a new overlay that is limited to the
node's own domain.

This restriction removes my uncomfortable feeling about allowing nodes to
create and participate in an arbitrary number of overlays or having a
situation where there are many overlays for the same domain.

Thanks.

Eunsoo

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 18 Jun 2007 14:04:30 -0400

Okay, so maybe there is a glimmer here I understand, but clearly not all.

Let me ask this: can the domain of an AoR be in more than one overlay?

If the answer is no, then maybe I see the way through the haze towards some
kind of distributed database of domains in the DHT.  If the answer is yes,
then I hit brick walls.

I'm still not really happy, because what I don't see is a definitive way to
address a message to an arbitrary domain.  With C/S, I can do that (3263).
With p2psip, I really think I need to be able to do that.  It seems hit or
miss now.

I also think that unless the number of domains in an overlay is small, that
we have an intractable problem related to the above.  In the extreme, there
could be one domain per peer, or even worse, in which case the domain is
meaningless.  Is that the intention?

Imagine a google service that offers to advertise your AoR, one at a time,
on a proxy it runs.  Just register with an AoR of your choice, and you're on
the overlay.  Domain doesn't matter, as long as the entire AoR is unique.
Tens of millions of C/S clients on one proxy peer, with millions of domains,
all resolving to one peer.  Does that make sense?

Then suppose Yahoo offers a competing service.  Suppose you register with
both (same AoR).  Would that work?

Brian

> Sent: Friday, June 15, 2007 2:30 AM
> To: Brian Rosen
> Cc: 'Henning Schulzrinne'; 'Vijay K. Gurbani'; 'P2PSIP Mailing List'

---

From: "Eunsoo Shim" <[email-masked]>
Date: Mon, 18 Jun 2007 18:37:26 -0400

My answers/comments are inline.

> Let me ask this: can the domain of an AoR be in more than one overlay?

Yes.
But there is a restriction.
A node of an AoR should participate in its domain's "regular" overlay if
possible.
If not, it can participate in a "default" overlay.

> With p2psip, I really think I need to be able to do that.  It seems hit or

I think the above restriction  provides a definitive way to address a
message to an arbitrary domain. If a node has connectivity to the DNS, it
uses its local "regular" overlay (if the target domain is the same domain)
or its local proxy that will use RFC3263. If a node has no connectivity to
the DNS, it uses its local "default" overlay. Please notice that a node uses
just one overlay in either case. There is no random poking into arbitrary
overlays.

> we have an intractable problem related to the above.

I think the number of domains in an overlay does not matter. As long as you
have a definitive way of mapping domain to overlay, you are fine.

 In the extreme, there
> meaningless.

With the proposed restriction, a node is allowed to create an overlay for
its domain only when it does not have connectivity to the DNS and there is
no existing "default" overlay. That is, it is the first node that wants to
participate in P2PSIP in the isolated network.

So in the world of P2PSIP I envision, there is one big "regular" overlay for
a specific domain and many small "default" overlays where some of the nodes
of the domain participate.

 Is that the intention?

> the overlay.  Domain doesn't matter, as long as the entire AoR is unique.

This is not what I propose. If a node has connectivity to the DNS, it should
participate in the overlay for the specific domain but not in the google
overlay.

> both (same AoR).  Would that work?

You are not going to register the AoR either in the google overlay or in the
yahoo overlay. You will have to register the AoR in the overlay for the
domain of the AoR.

Thanks.

Eunsoo

---

From: "Greger V. Teigre" <[email-masked]>
Date: Tue, 19 Jun 2007 09:54:22 +0200

We have two choices as I see it:

1. Is the AoR supposed to be the equivalent of an email address where 
the whole domain must handled authoritatively by one entity, here 
overlay (which allows 3263 lookups) ?

2. Or is the AoR supposed to be the equivalent of "use your email 
address as username on my website"?

If #1 is true, we can use language as the "AoR's default overlay". 
However, if #2 is true, a default overlay has no meaning. We must always 
identify the overlay as well.  So, the AoR has turned from 
[email-masked] to [email-masked]@googlesoverlay (ref. Brian's example.

I don't think we are able to do #1 and #2 at the same time.  If we go 
for #1, we follow the Internet-model for authoritative domain handling. 
This means that I need several AoRs, one for each overlay I want to 
participate in. [email-masked], [email-masked], and so on. Is this a problem? 

I have a feeling that some people really would like to create some 
universal id (AoR) that can be used across overlays and will have 
meaning regardless of which overlay(s) the AoR is connected to. The 
reality is that most people are used to having several email addresses, 
and I don't think they will have a problem with having several AoRs.
g-)

Eunsoo Shim wrote:
> On 6/18/07, *Brian Rosen* <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> A node of an AoR should participate in its domain's "regular" overlay 
> if possible.
> message to an arbitrary domain. If a node has connectivity to the DNS, 
> it uses its local "regular" overlay (if the target domain is the same 
> domain) or its local proxy that will use RFC3263. If a node has no 
> connectivity to the DNS, it uses its local "default" overlay. Please 
> notice that a node uses just one overlay in either case. There is no 
> random poking into arbitrary overlays.
>
> I think the number of domains in an overlay does not matter. As long 
> as you have a definitive way of mapping domain to overlay, you are fine.
>
>      In the extreme, there
> With the proposed restriction, a node is allowed to create an overlay 
> for its domain only when it does not have connectivity to the DNS and 
> there is no existing "default" overlay. That is, it is the first node 
> that wants to participate in P2PSIP in the isolated network.
>
> So in the world of P2PSIP I envision, there is one big "regular" 
> overlay for a specific domain and many small "default" overlays where 
> some of the nodes of the domain participate.
>
>      Is that the intention?
>
>
>
>
> This is not what I propose. If a node has connectivity to the DNS, it 
> should participate in the overlay for the specific domain but not in 
> the google overlay.
>
> You are not going to register the AoR either in the google overlay or 
> in the yahoo overlay. You will have to register the AoR in the overlay 
> for the domain of the AoR.
>
>
> Thanks.
>
> Eunsoo
>
>     > From: Dean Willis [mailto: [email-masked]
>     <mailto:[email-masked]>]
>     > > in the example.com <http://example.com> domain.  What is
>     Alice's AoR (what is the scheme for
>     > > address, etc. needed to create a session with Alice?  Assume
>     that peer
>     > is
>     > > I mean, if it's sip:[email-masked]
>     <mailto:sip:[email-masked]>, then the peer is going to do an
>     > SRV
>     > > lookup at example.com <http://example.com> for a sip server
>     and try C/S, right?  RFC3263
>     > >
>     > overlay that addresses the namespace " example.com
>     <http://example.com>", the peer looks up
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 19 Jun 2007 11:00:03 -0400

A good summary.
I support #1.
That's a simple way to support interoperation with C/S SIP.

[email-masked]@overlay_1 is just another URI. If we do that, someone
cannot print [email-masked] on her name card but should print
[email-masked]@overlay_1, [email-masked], and so on.
overlay_1 and overlay_2 are just another domains. nothing much changes.

Thanks.

Charlie

On 6/19/07, Greger V. Teigre <[email-masked]> wrote:
> 1. Is the AoR supposed to be the equivalent of an email address where the
> whole domain must handled authoritatively by one entity, here overlay (which
> allows 3263 lookups) ?
>
> 2. Or is the AoR supposed to be the equivalent of "use your email address
> as username on my website"?
>
> I don't think we are able to do #1 and #2 at the same time.  If we go for
> #1, we follow the Internet-model for authoritative domain handling. This
> means that I need several AoRs, one for each overlay I want to participate
> in. [email-masked], [email-masked], and so on. Is this a problem?
>
> universal id (AoR) that can be used across overlays and will have meaning
> regardless of which overlay(s) the AoR is connected to. The reality is that
> most people are used to having several email addresses, and I don't think
> they will have a problem with having several AoRs.
> g-)
>
>
> Eunsoo Shim wrote:
>
> I think the number of domains in an overlay does not matter. As long as
> you have a definitive way of mapping domain to overlay, you are fine.
>
>  In the extreme, there
> So in the world of P2PSIP I envision, there is one big "regular" overlay
> for a specific domain and many small "default" overlays where some of the
> nodes of the domain participate.
>
>  Is that the intention?
>
>
>
>
> should participate in the overlay for the specific domain but not in the
> google overlay.
>
> You are not going to register the AoR either in the google overlay or in
> the yahoo overlay. You will have to register the AoR in the overlay for the
> domain of the AoR.
>
>
> Thanks.
>
> Eunsoo
>
> > > From: Dean Willis [mailto: [email-masked]]
> > > > address, etc. needed to create a session with Alice?  Assume that
> > peer
> > > is
> > > > I mean, if it's sip:[email-masked], then the peer is going to do
> > an
> > > SRV
> > > overlay that addresses the namespace " example.com", the peer looks up
> ------------------------------
>
> [email-masked]://www1.ietf.org/mailman/listinfo/p2psip
>
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 19 Jun 2007 10:57:09 -0500

On Jun 19, 2007, at 2:54 AM, Greger V. Teigre wrote:

> 1. Is the AoR supposed to be the equivalent of an email address  
> where the whole domain must handled authoritatively by one entity,  
> here overlay (which allows 3263 lookups) ?
>

I think #1 is the general solution, and there might reasonably be a  
fallback to behavior #2 under certain fully-disconnected scenarios  
that I don't really even want to think about right now because the  
overlay-discovery and authentication problems become very, very messy  
and make my head hurt.

--
Dean

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 19 Jun 2007 14:07:00 -0400

Okay.  I like it.

Is there a way I can look in the URI or the DNS entry for the domain in the
URI and discover if this is p2p or c/s, or do I blindly try one and then the
other?

Brian

> Sent: Tuesday, June 19, 2007 11:57 AM
> To: Greger V. Teigre
> Cc: P2PSIP Mailing List

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 20 Jun 2007 10:10:36 -0400

Yes.

> overlay-discovery and authentication problems become very, very messy

Authentication and encryption are optional with c/s sip. I think a similar
principle should be applied to p2psip. That is, p2psip should be able to run
with strong security measures or weak security measures depending on the
choice of the overlay or the domain administrator or the participants.
In some situations, just connectivity is too valuable to give up because of
the lack/weakness of security. For example, an ad-hoc network in an
emergency situation. p2psip can be very useful for such situations. And the
fallback mechanism/overlay may be the right solution for some of the cases.
Hope this view may soothe Dean's headache a little bit.

Thanks.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 20 Jun 2007 10:17:46 -0400

I think the URI would have not any explicit indicator whether the resource
may be over c/s sip network or p2psip network at least the option #1.
DNS is likely to be an important tool for discovery of the overlay for a
specific domain and thus be able to indicate whether the resource is over
c/s sip or p2psip network. This depends on the overlay discovery mechanisms
we are going to use.
In the architecture I envisioned, interoperation among nodes using c/s sip
and p2psip are so seamless, each node does not have to really worry about
whether the target resource is using c/s sip or p2psip.
If a node is running over p2psip, it just uses the p2p mechanism to send a
message to any destination. If a node is running over c/s sip, it uses the
c/s sip mechanism.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 20 Jun 2007 10:21:36 -0400

I'd like to strengthen this.

I'd like EVERY implementation to ALWAYS try authentication and encryption.
I'd like there to be policy on what ciphersuites are allowed, including fall
back to none.  I'd like it to be "fall back"; that is you try something
stronger, and if you can't establish the connection, you try again with
something weaker.  I'd like an implementation that didn't implement the
security mechanism to fail to interoperate with most implementations.

I think that is the right choice for ad-hoc emergency.  In MOST cases, the
desire really is for secure communications in emergencies.  Fallback when
some part of the infrastructure fails is acceptable.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 20 Jun 2007 10:24:53 -0400

Okay, I like this answer.  Does that mean you thing the SRV for the sip
service in the DNS will have something that says the domain supports a
p2psip overlay?  Would you agree with me that "both" (C/S and P2P) is a
acceptable, and perhaps common case?

Furthermore, does the overlay have some identity beyond the (set of) domains
that are in it?  If there is, is the identity in the DNS?

Brian

  _____  

From: Eunsoo Shim [mailto:[email-masked]] 
Sent: Wednesday, June 20, 2007 10:18 AM
To: Brian Rosen
Cc: Dean Willis; Greger V. Teigre; P2PSIP Mailing List
Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays

Okay.  I like it.

Brian

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 20 Jun 2007 16:09:45 -0400

Catching up on this thread.  Comments inline

> overlay-discovery and authentication problems become very, very messy

I agree, although I think that dividing into just these two scenarios
is a little bit restrictive.  Consider a case where a company with an
established conventional SIP installation is migrating over to a
P2PSIP installation as hardware is replaced.  They could expect for
some period of time to have both systems, and are not likely to want
to use different domain parts for the old and new phones (no one
really should be aware of the difference other than IT).   In this
case, one good solution might be to have the p2p devices perform the
lookup in the overlay and if it fails, contact the conventional proxy,
only reporting failure if that fails.  So in this case, there is an
overlay, and the overlay should only contain one domain, but it's not
authoritative.

I can also see situations where you might have some Internet
connectivity, but might still want a particular overlay to support
multiple domain parts (e.g. a non-IETF conference might have hundreds
of people who could participate in a p2psip overlay and would
frequently be contacting each other, but not have ideal connectivity
to the Internet). Again, I think the right answer here is to search
the local overlay before going to the broader Internet.

While I agree with the concern about being a part of 6 overlays and
searching each of them everytime you make a call, I think this is
something of an implementation (and usage) issue more than an issue we
need to worry about right now.   There are practical cases to support
overlays that are authoritative for a single domainpart, practical
cases where an overlay should have only one domain present but is not
authoritative, and cases with mixed domains and no authoritative
presence whatsoever.

I also agree with Dean that my head hurts when thinking about how to
handle authentication in the mixed domain case, since without
involving an authoritative server for the domain, your security
options are very different than in normal SIP.

> URI and discover if this is p2p or c/s, or do I blindly try one and then the

Does it matter whether a URI is backed by a p2p or conventional SIP
installation?  Unless you're going to join an overlay in order to send
a message to anyone running one, I've been assuming that if you're
sending a SIP message to a URI that is not supported by the overlay
you're connected to, the resolution and message should follow the
normal 3263 etc procedure.

draft-marocco-p2psip-interwork-01 talks a bit about interworkings
between conventional and p2p deployments and I don't think has been
mentioned in this thread so far.

Bruce

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 25 Jun 2007 11:35:36 -0400

I tend to agree local domain should be tried first, for a couple of
reasons. First, the person you are trying to call is more likely there
(using the "you call people in your company more than local people
more than regional more than international" old rule of thumb. YMMV),
and second, if the overlay is running in a small area (ad-hoc network,
enterprise, local cluster), then the local domain search is likely to
complete first in any case.

David

On 6/25/07, Eunsoo Shim <[email-masked]> wrote:
> My comments are inline
>
>
> On 6/20/07, Bruce Lowekamp <[email-masked]> wrote:
> There is a quite straightforward way to allow interoperation of the c/s sip
> devices and p2psip devices using the same domain name. The concept draft or
> my old architecture draft describes it. The overlay can be the authoritative
> overlay for the domain.
>
> > to the Internet).
> > Again, I think the right answer here is to search
> I am not quite sure I understand the benefit of doing this.
>  Are you concerned that the DNS thus the mechanism of RFC3263 may not work
> very well because of poor Internet connectivity in this case?
> > need to worry about right now.
>
> If we want interoperation of various implementations, we would need
> agreement on what and how each peer/node will choose its own overlay(s)
> because it will affect how a peer/node will find others.
>
> >   There are practical cases to support
> Yes. So I believe we should accept the fact and be flexible about security
> requirements.
> Again I believe  insecure connectivity may be better than no connectivity in
> some situations.
>
> Thanks.
>
> Eunsoo
>

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

---

From: "Wei Gengyu" <[email-masked]>
Date: Tue, 26 Jun 2007 00:27:55 +0800

Hi, 
Also including some dedicated networks.
Based on P2P technology, we are trying to give a solution to an operator for its mobility management.

Regards,

Gengyu