Subject: [p2p-sip] Testing P2P Sip over ad-hoc

From: rodrigues.anderson at gmail.com (Anderson Rodrigues)
Date: Mon, 17 Apr 2006 08:30:35 -0400

Hi folks,

I?ve been reading your efforts on P2P SIP for a while and it is very
interisting how the discussion are growing up. Well, I would like to do some
studies on P2P SIP over small ad-hoc networks (no NATs will be available)
and I would like you help in two aspects:
1. Sugestions about softwares (P2P SIP) i can use for testing in this
environment;
2. Sugestions about which parameters would be useful to investigate (band
width, traffic, etc)
My intention is not measure the quality of voice, but instead, the
efficiency of the "lookup engine" for each of the softwares.

I apologize about this topic (i know it is out of your discursion), but i
knw that there are no place in the net with such concentration of experts in
this area.

Thanks for any help.

--
Anderson  C Barreto Rodrigues
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060417/9e380aab/attachment.html

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 17 Apr 2006 09:35:48 -0700

Over small ad-hoc networks without NAT you might like to lookup via
multicast or even broadcast, like Nimcat (Avaya) does. DHT seems like a
machine gun to kill ants, because DHT may be not as efficient (uniform
distributed) as in a network of universal scale. My 1c.

peter
----- Original Message -----
From: Anderson Rodrigues
To: p2p-sip at cs.columbia.edu
Sent: Monday, April 17, 2006 5:30 AM
Subject: [p2p-sip] Testing P2P Sip over ad-hoc

Hi folks,

Thanks for any help.

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Mon, 17 Apr 2006 14:41:45 -0400

> distributed) as in a network of universal scale. My 1c.

Hi Peter,

If we're going to standardize something, it may be OK
to have proprietary optimizations which use multicast or
broadcast for a small area.

It is a good idea to not rely on these optimizations which
have inherent scaling limitations, though, when trying to
build interoperable implementations.

Sure a DHT, or other structured overlay network may look like
overkill, but the variations in lookup overheads on a small
network really aren't likely to cause anguish for end users.

Scalability to larger networks without the need to identify a
"cutover point" from one algorithm to another may make it
useful to just build in the structured overlay capabilities
into every node.

Just my 2c
(not trying to bid you up, but we've got state sales taxes in NJ).

Greg

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 17 Apr 2006 15:37:24 -0700

Hello, Greg.

100% agreed for your perfect scenario (and the extra c you paid NJ)

Shall we also invade into 3g/ims so that all speak the same language?

Peter

----- Original Message -----
From: "Greg Daley" <gregd at research.panasonic.com>
To: "Peter Pan" <huang-ming.pan at comcast.net>
Cc: "Anderson Rodrigues" <rodrigues.anderson at gmail.com>;
<p2p-sip at cs.columbia.edu>
Sent: Monday, April 17, 2006 11:41 AM
Subject: Re: [p2p-sip] Testing P2P Sip over ad-hoc

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Tue, 18 Apr 2006 16:23:28 +0200

(the 5-hours timer fired without any ack received, so I'm retransmitting
this mail; perhaps the conspiracy ml is under attack ;-)

> efficiency of the "lookup engine" for each of the softwares.

Since existing implementations are not easily accessible and since
nothing is really "established" except that P2P layer will be separated
from SIP layer, I'd suggest to test existing DHT implementations (a
notable example is Bamboo, but starting from
http://en.wikipedia.org/wiki/Distributed_hash_table you could find a lot
more).  That should meet your requirements too.

Enrico

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Tue, 18 Apr 2006 10:36:32 -0400

> Shall we also invade into 3g/ims so that all speak the same language?

Sure, why not? :)

Greg
P2P conspiracy member.

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Tue, 18 Apr 2006 10:08:50 -0700

Wonder4!!

But, whose smart phones will volunteer as SN and pay for the "air" to
maintain p2p overlay?

peter

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Tue, 18 Apr 2006 15:54:18 -0400

Hi Peter,

> But, whose smart phones will volunteer as SN and pay for the "air" to

I know we've been flippant, but you're raising an interesting
economic argument.

Essentially, we do need to be aware of the costs of acting
as a lookup message "relay".  The demands vary dependent on
whether this also includes being a signaling (or even
media - for the global Internet version) relay.

In fact, broadcast on many wireless media are inherently
infrastructure based (802.11 non-adhoc, cellular systems),
whereby transmission to groups of nodes are relayed through
the infrastructure.

Thus retransmission is delegated to the switching infrastructure
behind the base station, which may be able to forward messages
to all nodes in the same IP subnet/link.  This is typically
only one device, though the sender [am being imprecise here I know,
but please take this as a worst case].

The main issue is that the subnet broadcast domain may be quite
small, and broadcast is highly dependent on underlying infrastructure.

In that case, further mechanisms for relaying messages are necessary.
In any case a subnet boundary is crossed, a relay/proxy or multicast
delivery service will be required to discover the endpoint address.

So, do you want only to look at a single IP subnet?

If we don't there will be some overlay network, and whether it is
structured or unstructured, both require nodes to donate their
transmission resources for the purpose of other nodes' location
discovery.

Does that make sense?

Greg

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Tue, 18 Apr 2006 13:54:42 -0700

Hi Greg,

Technically, if only address lookup is concerned, the demanded resources may
be negligible. But if users are charged (usually) by bandwidth used and
(cellular) SNs also need to store/dispatch volumes of replicated offline
messages (text+voice+video), class5 switch database, PoC/PTT group/presence
info and etc, users can not be too happy. Of course, if this kind of
"public" traffic can be classified to be free of charge, it is a different
story -- WSP will not be happy for they have paid lots for 3G spectrum.

Also, is it possible that IP mobility may significantly affect total
maintenance cost of wireless P2P overlay?

Maybe these topics are too early for P2P SIP now and can be revisited after
essential P2P SIP infrastructure is finished.

PP

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Wed, 19 Apr 2006 11:35:22 -0400

Hi Peter,

Peter Pan wrote:
> info and etc, users can not be too happy.

Indeed.

We need to be aware of the types and volumes of data being placed
on the nodes.

Personally, I don't think a class5 switch database is needed.
I'd suggest that we use CS/SIP for gatewaying to the circuit
switched network.  In that case, either the host requires
preconfiguration, or the identity of a CS/SIP proxy configured
in the Overlay or bootstrap (so, more challenges).

I'm not sure what to do about voicemail yet.  Let's think it out.

 > Of course, if this kind of

Indeed, if the traffic is onerous, and doesn't contribute
to subscription rates.

> maintenance cost of wireless P2P overlay?

I think that we should consider mobility to be out of scope.

If we have SNs who are mobile, we should expect them to use
mobility mechanisms at other layers (Layer 2, Layer 3, etc.) to
hide mobility from the overlay operations.  The ongoing reliability
of communications to mobile devices may contribute to whether a
device becomes or remains an SN though, and may increase churn,
depending on the SN selection mechanisms.

We may want to consider nomadicity though, in that location
information may be updated due to host movement.  For devices
which aren't explicitly responsible for overlay maintenance (ONs),
this largely leads to increased numbers of update operations,
and reduced lifetimes for stored information.

So I guess these are both (nomadicity and reliability) a matter
of degree.

> essential P2P SIP infrastructure is finished.

I think so, but it's not hurting to touch on them now.

If we miss something it may come back to bite us later.

Thanks again for your insight,

Greg

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 19 Apr 2006 10:21:26 -0700

Hi Greg,

> We need to be aware of the types and volumes of data being placed

[PP]: Dilemma is that likely we must choose either 0 (no p2p) or 1 (full
p2p) but not between. Kinda shame if there are still servers in a p2p
network. IMO.

> in the Overlay or bootstrap (so, more challenges).

[PP]: By class 5 switch database, I meant
subscription/features/administration information for a full-IP
implementation of major class 5 and supplemental services instead of gateway
to CSN.

> depending on the SN selection mechanisms.

[PP]: IP mobility/handoff issue is hidden beneath Layer 3. But smooth
handoff in mobile VoIP networks may incur quite some (3x) overhead to the
network (possibily correspondent nodes as well) especially when dog legs
exist in a route where optimization is not enabled in any of
home/foreign/correspondent routers.

> If we miss something it may come back to bite us later.

[PP]: Agreed. "Maybe" above was just a word of courtesy, trying not to bug
you folks too much. Depending on what P2P SIP would like to achieve
(commercially), the MAYBE is yes (to achieve Skype/MSN alike) and no (to
achieve carrier-class service networks). It is always yes, however, if P2P
SIP related protocols of initial versions for basic call control/messaging
only can be extended later to accomodate afore-said services with
compatibility and confidence.

> Thanks again for your insight,
[PP]: my pleasure!

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Wed, 19 Apr 2006 14:00:27 -0400

> p2p) but not between. Kinda shame if there are still servers in a p2p

Indeed.  We're not trying to take over the world (yet)
though.

If we need to specify servers which are intermittently
required (for example, a bootstrap server, or a CA, as
a trust anchor).  These may not need to be online
at all times, just if bootstrap procedures are failing,
or when a node needs to gain its initial authorization to
join the network.

We do have existing systems which can be used for Voicemail,
etc.  We need to figure out if all of these migrate to
analogous P2P elements.

> implementation of major class 5 and supplemental services instead of gateway

OK.  In that case, I guess we should still use CS/SIP,
at least initially.  I'm sure we want to replace all the
supplemental services use cases for CS/SIP, but add new
P2P use cases.

There are a large number of features in CS/SIP which it
isn't necessary to place in every node (Cameras, for example,
won't be quite so interested).

For some services (for example voicemail storage may be
one), we may think it data needs to be stored on the overlay.
That could significantly increase the load on SNs.

> home/foreign/correspondent routers.

In IPv6 this works ;-)

It's not really our responsibility to fix L3 problems, just
work around the critical ones like NAT.

If we pursue that path we'll never finish.

There are lots of ways of doing mobility at L4 or below.  Let's
not hack up another one to wring the last skerrick of performance
out for our scenario:  the cost to benefit ratio's not good enough
(Please take my word for it.  I did that for 4 years).

> compatibility and confidence.

Well, I don't work for a carrier.
Other opinions are certainly welcome.

I think that most of he work we do for SIP call setup, or for presence,
can be extended for other services  (peer-to-peer networks are already 
used for generic storage management for example).  Really I prefer not
to be blindsided though, if we get down the track and realize the
design's messed up.

The more eyes the better.

Greg

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 19 Apr 2006 21:09:17 -0700

> Indeed.  We're not trying to take over the world (yet)

[PP]: Engineers can cook any meal. But the issue may be more political than
technical. Who will invest on deploying a hybrid system and wait years for
it to incrementally become fully p2p when already there are proven
client/server and p2p solutions?

> (Please take my word for it.  I did that for 4 years).

[PP]: I take it. Thanks for the word :)

> to be blindsided though, if we get down the track and realize the

[PP]: What intrusion detection/prevention consideration/strategy will P2P
SIP take? I mean ingress intrusion targeting P2P SIP networks, not (P2P
SIP's) egress intrusion into P2P-forbidden enterprise/residential networks.
Traditional IDP systems for local networks seem irrelevant for global P2P
SIP networks.

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Thu, 20 Apr 2006 13:48:51 -0700

> The more eyes the better.
[PP]: Greg, it's great to hear the confidence of extendability. Does the
work consider (to transform) SIP-B in P2P SIP? Not a few VoIP vendors see
the demands of the 800 features on old IP PBX. Does P2P SIP need P2P version
of draft-ietf-sipping-service-examples-nn.txt asap so that any extendability
problem can be discovered alap?