From tutschku at informatik.uni-wuerzburg.de Mon Sep 4 13:34:00 2006
From: tutschku at informatik.uni-wuerzburg.de (Kurt Tutschku)
Date: Mon, 4 Sep 2006 19:34:00 +0200
Subject: [p2p-sip] CfP: MobileP2P'07 - 4 Weeks to Go
Message-ID: <008901c6d048$4f09c1a0$806abb84@Musa>
---------------------------------------------------------------------
(Please apologize for multiple copies)
---------------------------------------------------------------------
Call-for-Paper
4th IEEE International Workshop on Mobile Peer-to-Peer Computing (MP2P'07)
http://www-info3.informatik.uni-wuerzburg.de/mp2p2007
White Plains, NY, USA, March 19-23, 2007
In conjunction with the 5th IEEE International Conference on
Pervasive Computing and Communications (PerCom07)
http://www.percom.org/
----------------------------------------------------------------------
Peer-to-Peer (P2P) computing is a networking and distributed computing
paradigm which allows the sharing of computing resources and services by
direct, symmetric interaction between computers. The advance in mobile
wireless communication technology and the increasing number of mobile users,
extend the arena of P2P computing to encompass mobile devices and wireless
networks. The special characteristics of mobile environments, such as
highly variable connectivity, disconnection, location-dependency, resource
constraints, and diversity in wireless networks as well as carrier-grade
performance requirements bring new challenges for research in mobile P2P
computing.
Based on the success of its three predecessors, MP2P'07 is intended to serve
as a continuing forum for scientists and engineers in academia and industry
to exchange and discuss their experiences, new ideas, and research results
about all aspects of mobile P2P computing. It will address the challenges,
technologies, and architectures leading to real-world solutions that provide
users with direct access and control of their critical peer-based
information and services, regardless of location or device. The principal
theme of MP2P'07 is the development of protocols, systems and applications
of mobile P2P architectures and the evaluation of their performance.
Topics of particular interest include, but are not limited to:
- Architecture and platforms for mobile P2P computing
- Measurement studies on mobile P2P systems
- Performance of mobile P2P services
- Resource and service discovery in mobile P2P computing
- Resource exchange mechanisms in mobile P2P application
- Multicast Protocols in mobile networks
- Energy saving P2P protocols for mobile devices
- Mobile P2P in wirelesss sensor networks
- Security in mobile P2P networks
- Mobile P2P over different kinds of bearer services: 2.5/3G (GPRS/UMTS) /
802.11 (WLAN)
- Mobile P2P & operator/provider requirements
- Reliability and carrier-gradeness of mobile P2P services
- Mobile P2P SIP
- Mobile P2P & fixed P2P system interworking
- Issues of combining P2P services with mobility (mobile IP / MANET)
- Peer access and control in mobile environment
- Location dependent mobile P2P services
- Data exchange and rendering techniques for mobile devices
- Secure communication protocols for mobile P2P computing
- Mobile P2P messaging systems
- Peer-to-peer broadband wireless communications
- Applications of mobile P2P
- Middleware for mobile P2P
- Nature-inspired algorithms for mobile P2P computing
- Theoretical issues on mobile information diffusion
- Mobile P2P video games
- Stimulating cooperation in mobile computing
- Multicast Protocols in mobile networks
- Energy saving P2P protocols for mobile devices
- Mobile P2P in wireless sensor networks
Paper Submission:
-----------------
Papers must be written in English and should not exceed 5 pages in IEEE
proceedings style. All submissions must describe original research, not
published nor currently under review for another conference or journal.
Authors MUST submit their papers through the PERDAS web site
(http://www.percom.org/perdas) in three steps:
* Creation of a personal account on PERDAS (if the author does not already
have one)
* Registration of the paper (requiring a short abstract of up to 150 words)
* Upload of the paper. Only in pdf format
Submission implies the willingness of at least one of the authors to
register and present
the paper.
There is only one registration for the whole PerCom "convention", all
workshops included. The only exception from the full-registration rule is:
an author can register for her/his paper with a student registration if i)
(s)he is a student AND ii) on of her/his co-authors has a full registration
with PerCom.
All submissions will be reviewed and selected based on their originality of
the paper. Accepted papers must be presented at the workshop and will appear
in a combined PerCom 2007 workshop proceedings published by IEEE Computer
Society Press.
Authors that present a system in their paper are highly encouraged to
demonstrate also the system in the demo session of the workshop.
Important Dates:
----------------
Papers due: 5pm EST, September 29, 2006
Notification of acceptance November 25, 2006
Camera-ready papers due to IEEE December 22, 2006
Organizing Committee, Program Co-chairs:
----------------------------------------
Kurt Tutschku, Department of Distributed Systems, University of W?rzburg,
Germany.
Acting Chair of Self-Organization and Distributed Systems,
TU Chemnitz, Germany.
John Buford, Panasonic Princeton Laboratory, USA.
Li Li, Communications Research Center Canada, Canada.
Steering Board:
---------------
- Jiannong Cao, Department of Computing, Hong Kong Polytechnic University.
- Y. Charlie Hu, School of Electrical and Computer Engineering, Purdue
University.
- Cecilia Mascolo, Department of Computer Science, University College
London.
- Maria Papadopouli, Department of Computer Science, University of North
Carolina at Chapel Hill.
- Frank-Uwe Andersen, Siemens Communications, Germany.
Publicity Chair:
----------------
Kurt Tutschku, Department of Distributed Systems, University of W?rzburg,
Germany
Acting Chair of Self-Organization and Distributed Systems,
TU Chemnitz, Germany.
Program Committee Members:
--------------------------
- Arup Acharya, IBM Watson Research Lab, USA.
- Frank-Uwe Andersen, Siemens Communications, Germany.
- Jiannong Cao, Hong Kong Polytechnic University, Hong Kong.
- Geoff Coulson, Lancaster University, Lancaster, UK.
- Hermann de Meer, Department of Computer Networks & Computer
Communications, University of Passau, Germany.
- Franca Delmastro, CNR-IIT ,Pisa, Italy.
- Krishna Dhara, Avaya Labs Research.
- Babak Esfandiari, Carleton University, Canada.
- Stephen Hailes, Department of Computer Science, University College of
London, UK.
- Felix Hernandez-Campos, Department of Computer Science, University of
North Carolina at Chapel Hill, USA.
- Y. Charlie Hu, School of Electrical and Computer Engineering, Purdue
University, USA.
- Norihiro Ishikawa, NTT Docomo, Japan.
- Valerie Issarny, INRIA, France.
- Wolfgang Kellerer, DoCoMo Communications Laboratories Europe, Germany.
- Kazuhiro Kitagawa, Keio University, Japan.
- Rajeev Koodli, Nokia Research, USA.
- Thomas Kunz, Dept. of Systems and Comp. Engineering, Carleton University,
Canada.
- Li Li, Communications Research Center Canada, , Canada.
- Christoph Lindemann, Depart. of Communication Networks and Distributed
Systems, University of Leipzig, Germany.
- Vishal Misra, Dept. of Computer Science, Columbia University, New York,
USA.
- Maria Papadopouli, Department of Computer Science, University of North
Carolina at Chapel Hill , USA.
- Rudolf Riedi, Department of Statistics, Rice University , USA.
- George Roussos, School of Computer Science and Information Systems -
Birkbeck College, University of London, UK.
- Jochen Schiller, Institute of Computer Science, FU Berlin, Germany.
- Hans-Peter Schwefel, Department of Communication Technology, Aalborg
University, Denmark.
- Shervin Shirmohammadi, School of Information Technology and Engineering
(SITE), University of Ottawa, Canada.
- Apostolos Traganitis, Telecommunications and Networks
Laboratory,University of Crete, Greece.
- Kurt Tutschku, Department of Distributed Systems, University of W?rzburg,
Germany.
- Klaus Wehrle, Distributed Systems Group, RWTH Aachen, Germany.
- Chansu Yu, Department of Electrical and Computer Engineering, Cleveland
State University, USA.
---
Dr. Kurt Tutschku, Assistant Professor
University of Wuerzburg
Department of Distributed Systems
Institute of Computer Science
Am Hubland
97074 Wuerzburg
Germany
Tel.: +49-931-8886641
FAX: +49-931-8886632
mailto:tutschku at informatik.uni-wuerzburg.de
or
mailto:kurttutschku at hotmail.com
http://www-info3.informatik.uni-wuerzburg.de/staff/tutschku
TU Chemnitz
Acting Chair of Self-Organization and Distributed Systems
Faculty of Computer Science
Strasse der Nationen 62
09107 Chemnitz
Germany
Tel.: +49-371-531-35514
FAX: +49-371-531-25539
mailto:tutschku at informatik.tu-chemnitz.de
From g06t6632 at campus.ru.ac.za Wed Sep 6 16:37:02 2006
From: g06t6632 at campus.ru.ac.za (Mosiuoa Tsietsi)
Date: Wed, 06 Sep 2006 22:37:02 +0200
Subject: [p2p-sip] Interoperation Between HeterogenousP2P OverlayNetworks
In-Reply-To: <200608280612.k7S6C0o3026367@noya.bupt.edu.cn>
References: <200608280612.k7S6C0o3026367@noya.bupt.edu.cn>
Message-ID: <1157575023.6753.0.camel@localhost.localdomain>
Hi Juwei,
Some more thoughts...
I think that the main issue lies in whether or not we will allow lookups
to be done in foreign DHTs when that peer does not belong to that DHT.
I'm guessing maybe you believe they should. I think interoperation can
be simplified by allowing foreign nodes to use the look-up semantics of
the foreign DHT (via the use of plug-ins - note that the plug-in the
node is using does not have to be the same one being used for local
lookups) to access bindings needed for session establishment. This can
be a "guest function". As such, nodes can use a local plug-in to
participate in thei local DHT (get,put,remove) and temporarily use
another plug-in to simply do gets from there. Below is a quote from the
freepastry.org website commenting on interoperation between freepastry
and simpastry:
"Two implementations of Pastry are currently available for download:
FreePastry from Rice University and SimPastry/VisPastry from Microsoft
Research. The initial releases of both implementations support a
semantically similar API. A joint, language independent API for Pastry
is currently being defined and will be supported by future releases of
both implementations."
This leads me to believe that if the semantics are similar,
interoperation is possible. Please let me know what you (and all else!)
think.
Regards,
Mos
On Mon, 2006-08-28 at 14:12 +0800, Juwei Shi wrote:
> Hi, Mosiuoa
>
> The idea only storing resource bindings is very interesting and I think that proxy nodes are still needed. The difference between our scheme and your scheme is that: we implement the inter-overlay operation via a higher level overlay and you implement that via only inter-domain resource operation/register. Does every overlay need to register to any other overlays as the resource? The efficiency, reliability, scalability and message overhead need to be evaluated by your future experiment.
>
> Thanks
> Juwei
>
> __________________________________________________
>
> Hi folks,
>
> Thanks for the probing questions, they really make me think more
> carefully about my idea, which is for all intents and purposes, work in
> progress. Firstly, interoperation aside, pluggability of algorithms is
> useful to overlays because it doesn't commit them to one way of doing
> things. I don't think anyone is willing to stick out his/her head and
> say Chord is best or Pastry is best for P2P SIP (neither am I saying
> DHTs are the best p2p protocol, oops!). An overlay can choose to
> "switch" to another routing algorithm for experimental purposes and we
> can examine differences in latency etc.
>
> Now for the contentious issue, interoperation. Say for sake of
> arguement bob at chord.co.za wants to initiate a call with
> alice at pastry.co.za. Bob notices that the RHS of Alice's AOR is not
> chord.co.za (not part of the local overlay). So what next? The idea is
> still taking form in my mind, but if we are allowing storage of foreign
> resource bindings in the local overlay, essentially, only one binding
> for a given overlay may be enough since the P2PSIP proxy is flattened
> across the foreign overlay and every peer is savvy enough to translate.
>
> I could be wrong about this. I did initially think of using a proxy (it
> is the natural choice) but thought it would simply be an optimization to
> the base case. It may actually be the way to go since I also wanted to
> explore interoperation with canonical SIP and that will definately need
> gateways (for interest sake, I was thinking along the lines of
> CoDoNS/Beehive and DNS-DHT translators..).
>
> At any rate, I'm glad I got my idea out there. The input is great!
>
> Mos
> On Sat, 2006-08-26 at 10:42 +0800, Seaward Hu wrote:
> > I agree with Krishna, let me show a example.
> > We know that the Window OS can support many companies' CPU, but after
> > you install it in your computer with Pentium CPU, you can not simply move
> > the hard disk to another computer with AMD CPU and boot it successfully, for
> > the two kinds of CPU have different instruction set. To interwork between
> > the two computers, we need other protocols such as FTP, HTTP and SIP.
> > So I mean not every node can bear the burden of supporting many kinds
> > of DHT protocol, for the efficient reason, the protocol for interworking
> > over different overlay is needed. And those strong nodes which equipped with
> > two kinds or more stack will become the GW.
> > I don't know if I misunderstand Mos's idea, comments are appreciated.
> >
> > Thanks.
> >
> > Seaward
> >
> > > -----Original Message-----
> > > From: p2p-sip-bounces at cs.columbia.edu
> > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Krishna
> > > Sankar (ksankar)
> > > Sent: Saturday, August 26, 2006 1:30 AM
> > > To: Juwei Shi; Mosiuoa Tsietsi; p2p-sip at cs.columbia.edu
> > > Subject: Re: [p2p-sip] Interoperation Between Heterogenous
> > > P2P OverlayNetworks
> > >
> > > > I can't understand your plug-in theory clearly. Although the
> > > common API can be provided by your architecture, the
> > >
> > > Yep, same here.
> > >
> > > There are two distinct layers, the interface layer and the
> > > protocol layer. The interface layer can be abstracted by a
> > > plug-in architecture, thus making a system independent from
> > > programming changes. But if the underlying protocol machines,
> > > state machines, information model and wire formats are
> > > different, we will not be able to achieve interoperability
> > > and will result in what Juwei has described.
> > >
> > > The JMS (Java Messaging Service) world has parallels - the
> > > JMS API is standard, so that we can use JMS either with JMS
> > > providers or with products like Tibco, MQ et al. The
> > > programming does not change. But none of them are
> > > interoperable; which means we cannot send a JMS message
> > > through an IBM JMS implementation and expect BEA JMS to understand it.
> > > This is because, the wire format and the protocols are not
> > > standardized.
> > >
> > > That said, am interested in how Mos's idea works out. From
> > > the beginning, this was one of my wishes - a substrate
> > > agnostic, transport independent and orthogonally extensible
> > > P2P-SIP. But am not sure it can be achieved ...
> > >
> > >
> > >
> > >
> > > ________________________________
> > >
> > > From: p2p-sip-bounces at cs.columbia.edu
> > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Juwei Shi
> > > Sent: Friday, August 25, 2006 10:12 AM
> > > To: 'Mosiuoa Tsietsi'; p2p-sip at cs.columbia.edu
> > > Subject: Re: [p2p-sip] Interoperation Between
> > > Heterogenous P2P OverlayNetworks
> > >
> > >
> > >
> > > Hi, Mos
> > >
> > >
> > >
> > > I can't understand your plug-in theory clearly.
> > > Although the common API can be provided by your architecture,
> > > the underlying lookup protocols still differ. If every node
> > > has all kinds of overlays, it must join all overlays. That is
> > > to say, all nodes can do translation between DHTs means every
> > > node should join all DHTs. Then the DHT operation message
> > > overhead will be significantly increased and I personally
> > > don't think it is a practical way for heterogeneous overlay
> > > interwroking.
> > > Furthermore, if every node runs all kinds of DHTs, there's no
> > > need of interworking.
> > >
> > >
> > >
> > > Do I comprehend your idea correctly? Can you give us an
> > > session initial example between Bob in Chord and Alice in Pastry?
> > >
> > >
> > >
> > > Thanks
> > >
> > > Juwei
> > >
> > >
> > >
> > > ________________________________
> > >
> > >
> > >
> > > Hi all,
> > >
> > >
> > >
> > > I have been listening in very intently on the list and
> > > have been very intrigued by many of the comments that have
> > > been made particularly concerning interoperation between
> > > heterogeneous P2P Overlays. I read the document
> > > draft-shi-p2psip-hier-arch-00.txt with great interest and
> > > would like to comment on a statement made therein saying:
> > >
> > > "A peer in one P2P overlay (such as Chord) is difficult
> > > to route the SIP message to another P2P overlay (such as
> > > Pastry) based on their individual P2P peer locating service"
> > >
> > >
> > >
> > > I can understand the difficulty as mentioned. I have
> > > come up with an idea that could (hopefully) ameliorate these
> > > difficulties. I propose a node architecture for a P2PSIP UA
> > > within the context of using DHTs as the basis of a location
> > > service, with an added abstraction layer built in to the UA
> > > to hide the differences in the DHT APIs. This abstraction
> > > layer consists of a layer of DHT plug-ins for different DHT
> > > algorithms. These plug-ins will allow "pluggability" of
> > > different DHTs in participating overlay nodes. This design
> > > will allow all P2PSIP nodes to use a common {get, put,
> >
> > > remove} API which is then translated by the particular
> > > plug-in in use at that time. This would eliminate the need
> > > for a gateway node (since all nodes can do translation
> > > between DHTs) and is more kosher in strictest p2p sense.
> > >
> > >
> > >
> > > I have begun using OpenChord and Bamboo (Java DHT
> > > implementations) to test out my plugin theory.
> > >
> > >
> > >
> > > Have I misunderstood the problem and oversimplified it?
> > > Comments much appreciated.
> > >
> > >
> > >
> > > Mos
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > p2p-sip mailing list
> > > p2p-sip at cs.columbia.edu
> > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> > >
> >
> >
> >
>
>
--
The Law of Unintended Consequences: for every action, there is an
excellent chance of producing an opposite and totally disproportionate
reaction. - Clyde Haberman
From spencer at mcsr-labs.org Thu Sep 7 15:58:00 2006
From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 7 Sep 2006 14:58:00 -0500
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
Message-ID: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com>
I'm trying to get through this document at several levels - I hope these
comments are coherent (and helpful).
Summary - the document is really a good start, even though I have lots of
notes and suggestions. Thanks for the hard work.
Thanks,
Spencer Dawkins
High-level comments ...
- in general, I'd like to tighten up the terminology that we use. There are
terms with four additional "short forms" listed. This seems unnecessarily
confusing. It is OK to have a short form, but can we deprecate at least some
of the choices?
- as a follow-on, it's not clear to me how much of the terminology is P2PSIP
and how much is P2P in general. For example, is there anything special about
a "P2PSIP Overlay Key", compared to an "overlay key"?
- Figure 1 seems confused on whether the UA/Peers behind the NATs are part
of the overlay or not - I think I can draw the lines more clearly (shown
below), assuming that they ARE part of the overlay.
- Figure 1 is also trying to do more than you can do in ASCII art (at least
I think so) - the dotted lines either mean (a) logical connectivity in the
overlay, (b) physical connectivity through the NATs, or (c) a SIP call. I
doubled the lines for the overlay topology, but left the SIP calls in and
don't like the result. If people agree, I can do ASCII art for (a) and (c),
as two figures.
- I'm very confused about how both clients and peers can be "endpoints". For
one thing, I'm not sure how "endpoint-to-endpoint trust" works. I suspect
that this is conflating P2P endpoints (peers) with SIP endpoints (either a
UA-peer or a UA-client). If you guys understand this perfectly, please keep
typing...
- I'm somewhat confused about how we can talk about P2PSIP peers and clients
without talking about something like a P2PSIP Overlay Server (see comments
below).
Detailed comments ...
2. Definitions
P2PSIP Overlay User Agent: A SIP user agent that is coupled to a
P2PSIP Overlay Peer or P2PSIP Overlay Client, such that the peer
or client can assist the UA with registration (storage of a route
to users of the UA) and/or routing of requests using the P2PSIP
Overlay. A P2PSIP Overlay SUer Agent differs from a conventional
s/SU/Us/
SIP user agent in that it is coupled directly to a P2PSIP Overlay
Peer or P2PSIP Overlay Client, and can therefore directly interact
with a P2PSIP Overlay, which a conventional SIP UA cannot do.
P2PSIP Overlay User Agents are presumed to have no distinguished
name or identifier. Short forms: overlay UA, P2PSIP UA.
P2PSIP Overlay Bootstrap Server: A network node used by P2PSIP
Overlay Peers or Clients who are attempting to enter to locate an
entry into the P2P Overlay Network. It may return an entry point
(address of a Peer) to the P2PSIP Overlay or act as one itself.
This should be a quasi-stable and well known host, located using a
configuration or discovered via , DNS, broadcast, or other
mechanism. Example: a P2PSIP Overlay Peer that reboots and has no
knowledge of other peers uses a P2PSIP Overlay Bootstrap Server to
find other peers in the P2P Overlay Network and establish P2PSIP
Overlay Peer Insertion. (Note: An overlay peer might or might not
provide this functionality). Short forms: bootstrap server, boot
server.
These short forms seem very likely to conflict with lower-layer usage of the
same terms, where "bootstrap server" and "boot server" have a
well-understood usage. "Overlay bootstrap server" as short form?
3. Discussion
3.1. What Kinds of P2PSIP Overlay Peers and Clients Might Exist?
3. Gateway: a peer or client that converts from P2PSIP to some other
protocol, such as PSTN.
"PSTN" should be expanded on first use. It is expanded, but not on first
use.
4. Redirector or Location Server: a peer or client that, given a SIP
Is this a "SIP INVITE", or something else? looks like a cut and paste error.
(or other SIP request) to a P2PSIP overlay resource identifier,
returns the route to a resource in a 302 or 305 response.
3.2. Reference Model
Note - this is my redrawn picture, with changes on the left...
--->PSTN
-----------/
-------- |N| | Gateway |
| |========|A|========| Peer |==============
| UA | |T| | | ||Client Protocol
| Peer | ----------- || GET/PUT
| C | || |
-------- || | \__/
|| || v / \
|NAT| ||---- / UA \
|| P2PSIP Overlay || /Client\
|| || |______|
|| Route Data || ^
-------- -------- || |
| | |N| | | || |
| UA |=|A|==| UA | || |
| Peer | |T| | Peer | || |
| D | | E | || |
-------- -------- || |SIP
Peer Protocol || --------- --------- || |
|| | | | | || |
====| Proxy |========| Redir |==== |
| Peer | | Peer | |
| | | | |
--------- ---------- |
/ \ /
/ \ /
\__/ / SIP SIP \ \__/ /
/\ / \ /\ /
/ \/ \/ \/
/ UA \ / UA \
/______\ /______\
SIP UA A SIP UA B
Figure: Reference Model
Here, the large rectangle represents the P2PSIP Overlay and its
associated routing data. Around the periphery of the P2PSIP Overlay
rectangle, we have several P2PSIP Overlay Peer nodes -- a PSTN
gateway, a user-agent, a proxy, and a redirector. To the left we
have two UA peers are behind network address translator. On the
right side, we have a P2PSIP Overlay "UA client", which uses the
P2PSIP Overlay Client Protocol to interact with the P2PSIP Overlay.
Below, we have conventional SIP UA "A", which has used SIP to
interact with the Proxy Peer and establish a dialog with the UA peer,
There were three unnamed "UA peers" on the diagram. I'm not sure which one
you were talking about, and I couldn't figure that out from the diagram (see
previous whining about combining logical network topology and call paths on
one diagram) but I at least named them in the diagram, so you can call one
out in the text.
and SIP UA "B" which has been redirected by the Redirect Peer and set
up a dialog with the UA Client. Note that the Proxy Peer and the UA
Peer interact using the P2PSIP Overlay Peer Protocol, which is also
presumably used on the keepalive links between the UA Peers and their
"keepalive links" hasn't been defined, and I'm not happy with the term. Are
these any more than "logical links", in this context?
neighbors.
3.3. Conceptual Outline of Operations
3.3.1. Enrolling and Inserting an P2PSIP Overlay Peer
Peers are the full-function "routing and storage" nodes of a P2PSIP
Overlay. When a new peer is first created, it must enroll in the
P2PSIP Overlay. We currently have no defined mechanism for this (do
we need one?), but we know that once the process is complete, the new
I think this is required for the ad hoc scenarios, isn't it?
peer will have at least a P2PSIP Overlay Peer Key and a set of
credentials.
After enrollment, each time the peer connects to the overlay, it must
insert itself. We don't have a defined protocol and process for
this, and assume we need one. Presumably the inserting peer connects
I agree that we need one.
to one or more existing peers (possibly with the aid of a bootstrap
server) presents its credentials, and ends up connected to the
overlay, with some knowledge of neighbors (successor, precursor,
finger tables, or whatever the distribution mechanism defines) and is
able to store data on behalf of and route requests to other nodes in
the P2PSIP overlay.
3.3.2. More on The Difference Between a Peer, Client, and User Agent
P2PSIP Overlay Peers directly interact with and contain the routing
and storage fabric of the overlay. P2PSIP Overlay Clients just use
the routing and storage facilities provided by the peers. The peers
speak the P2PSIP Overlay Peer Protocol, which presumably has a full
range of expressivity for the routing and storage facilities of the
"expressivity" is a great word. Is it defined anywhere? ;-)
overlay. Clients speak the P2PSIP Overlay Client protocol, which is
presumably a subset of the peer protocol, and is limited to storage
insertion (put), storage retrieval (get), and message routing (send).
Some peers and some clients may be coupled to SIP user agents, making
them P2PSIP Overlay User Agents capable of both sending and receiving
conventional SIP messages (as per a SIP UA) using conventional SIP
resolution procedures and of using the resolution facilities provided
by the overlay
(missing period after this sentence)
3.3.3. Enrolling a User and Inserting a P2PSIP Overlay User Agent
To get started, users must be enrolled in the overlay. We do not
have a process or protocol for this, nor are we certain we need a
standardized mechanism. We presume that after enrollment, the user
has a distinguished name within the overlay (example:
sip:bob at example.com) and a set of credentials useful for
authenticating its usage of the distinguished name. One possible
mechanism for these credentials would be an x.509 certificate. It
might also be possible to use a PGP key, a password, or some other
mechanism. Presumably following enrollment, the user is also
equipped with the information needed to connect to the overlay, such
as the address of a bootstrap server. Whether this startup
information is delivered as a part of enrollment of through some
separate configuration process remains an open question.
I would like to define this, but am concerned that the choice may differ
per-overlay. Do others agree?
3.3.4. Placing a Call from a P2PSIP Overlay Client UA to a P2PSIP
Overlay Client UA
Assume we have two users, Alice and Bob, who have successfully
enrolled and inserted themselves into a P2PSIP Overlay using clients.
Alice wants to call Bob, and enters Bob's user identity (AOR) into
her client. Alice's client does not have current knowledge of a
route-set to Bob's client(s), so it needs to discover one. Alice's
I was confused here. This text doesn't point anywhere for "it needs to
discover one", so the reader is left to assume that "Alice's Client then
does a GET operation on Bob's identity" is how that discovery happens, but
"then does a GET" sounds like it happens AFTER discovering a route-set. If
this is how discovery happens, please remove "then", and maybe even go to
"it needs to discover one by doing a GET operation on Bob's identity".
Client then does a GET operation on Bob's identity, using a
previously-discovered peer, or using whatever procedures are needed
(such as RFC 3263, a bootstrap server, etc.) to find a peer. Alice's
client send the GET request to the selected peer.
3.3.5. Bootstrapping
If a client or peer is just starting up and has no knowledge of how
to reach the other nodes of the overlay, it may exercise a bootstrap
server to find one. Presumably it discovers the bootstrap server by
some mechanism such as a DNS lookup, multicast, broadcast or
configuration, then queries the bootstrap server and receives an
address for a peer or set of peers that can be used to reach the
overlay. Ideally, these target peers will be selected from a
relatively large pool of peers that are currently online and
reachable.
This last sentence seems awfully use case-specific, doesn't it?
After discovering the address of a peer, the behavior of the starting
node will vary depending on whether it is intending to be a peer or a
Ouch - if I have a peer, I would think that I'm a peer, too. Is the client
actually discovering something like a "P2PSIP Overlay Server"?
client. If it is intending to be a peer, it goes into the P2PSIP
Overlay Peer Insertion process, at the conclusion of which it is
actively participating in the target overlay as a peer and is capable
of routing requests and storing records on behalf of the P2PSIP
overlay. If it is intending to be a client, it does not bother with
insertion, but merely contacts the discovered peer in order to use
the overlay.
4. Questions
4.4. Universal Routing:
Do all P2PSIP Overlay Peers route requests? How about clients?
I thought this was one of the differences between peers and clients. If it's
not, what's the difference?
4.9. Cryptotransparency
When forwarding requests, are the bodies of the requests visible to
peers? If so, this creates substantial security problems that the
deployers of conventional SIP have been willing to mostly ignore.
Can we make peers cryptotransparent (like HTTP proxies) when security
is requested?
I believe this question is key when we discuss what an endpoint is (see
previous comments on whether clients are endpoints).
4.13. Bootstrapping
We know that sometimes peers or clients will start up without
knowledge of how to find a peer for insertion. Do we need to define
a bootstrap mechanism or mechanisms? Do we need to define supporting
protocols?
I believe the answer to both of these is "yes" to support anything like ad
hoc use cases.
4.15. Overlapping Domains
If the P2PSIP Overlay User Identifier is not scoped to a single DNS
domain, this would appear to allow nodes from two or more apparent
domains to share a single P2PSIP Overlay. What, if anything, do we
need to say about this mode of operation?
If a peer can locate an appropriate overlay AND provide appropriate
credentials, what would prevent us from supporting this?
4.16. Hybrid Domains
It appears possible to have some hosts within a domain using
conventional SIP and some using P2PSIP. This potentially raises a
number of questions: 1) What should happen if we want to run a P2PSIP
overlay in an existing SIP domain? 2) Do the existing redir/proxy
servers need to be coupled with a peer layer? 3) When would an
overlay peer want to discover them as opposed to looking in the
overlay? 4) Is better not to run conventional SIP with overlay SIP?
5) When conventional and P2PSIP are run together, shall the existing
redir servers keep their local databases or switch to the overlay
storage.
We've had some discussion on-list here about whether I have the same AOR in
conventional SIP and P2PSIP overlays or not. Did we converge?
4.17. Admissions Control
What do we need to say about admissions control with respect to the
enrollment of peers and users? Do we need to discuss per-call
admissions control in a P2P environment?
I can imagine admissions control for enrollment, but I'm having a hard time
imagining per-call admissions control in a decentralized P2P overlay - or
was this the point of the question?
From spencer at mcsr-labs.org Thu Sep 7 16:07:45 2006
From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 7 Sep 2006 15:07:45 -0500
Subject: [p2p-sip] Fw: Use cases attributes
Message-ID: <07ac01c6d2b9$48df3c10$0500a8c0@china.huawei.com>
It's been two or three weeks since David posted a pointer to
http://www.p2psip.org/P2PUseCases.php.
I'd like to have some discussion on this, starting with Enrico's note, but
am wondering if we managed to post this the last week before everyone
returned from vacation - just as a heads-up...
Thanks,
Spencer
----- Original Message -----
From: "Enrico Marocco"
Spencer Dawkins wrote:
> I would like to keep this spreadsheet in sync with the drafts, of course,
> so the contents will change as people discuss use cases.
>
> I should add that this spreadsheet is the product of discussions with a
> number of people, including Seaward, so please view me as the editor, not
> as the author.
>
> As always for editors, comments are welcome.
First of all, thank you for the great work!
Then, a couple of comments on the "Interaction with CS-SIP" column,
which is the one I care more about ;-) I expected to see a "when
available" instead of a cold "no" at least in the following rows:
+ Impeded Access
+ Ad-Hoc and Ephemeral Groups
+ Extending the Reach of Mobile Devices
In such use cases, when some peer in the overlay shares the resources
for relaying SIP and media traffic to and from the Internet, the overlay
itself should act exactly as a conventional SIP network, IMHO.
--
Enrico
--------------------------------------------------------------------
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons above
and may contain confidential information. If you have received the message
in error, be informed that any use of the content hereof is prohibited.
Please return it immediately to the sender and delete the message. Should
you have any questions, please contact us by replying to
webmaster at telecomitalia.it.
Thank you
www.telecomitalia.it
--------------------------------------------------------------------
From spencer at mcsr-labs.org Fri Sep 8 00:07:46 2006
From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 7 Sep 2006 23:07:46 -0500
Subject: [p2p-sip] Questions on draft-marocco-p2psip-interwork-00
Message-ID: <091d01c6d2fc$577d2a50$0500a8c0@china.huawei.com>
Hi, Enrico and David,
It's probably premature to discuss this draft in detail, but I did have some
questions as I read it, and asking now might help you prepare for the next
version...
The draft calls out I-D.willis-p2psip-concepts specifically, but the
Introduction says
This document describes how user agents registered in P2PSIP overlay
networks [I-D.willis-p2psip-concepts] can interwork with those in
conventional SIP networks [RFC3261]. In particular, no assumption is
made about the overlay but that it allows clients to insert and
retrieve routing information, possibly bound to URIs [RFC3986].
Does "clients" mean "clients" in the I-D.willis-p2psip-concepts sense, or in
some other sense?
I really like the "P2PSIP Proxy Peers" term and description. You may have
noticed some musing in my notes on I-D.willis-p2psip-concepts about a P2PSIP
Overlay Server - I think this is pretty close to what I was thinking of. The
direction of "proxying" is reversed, I think, but this might be
symmetrical... Is it possible that the same concept might also work for the
P2PSIP clients described in I-D.willis-p2psip-concepts?
The Security Considerations section correctly describes the tension between
"too easy to insert into DNS" and "too difficult to insert into DNS" - but
that's awfully late in the draft to bring this up. Although
security-related, it's pretty fundamental to what we're trying to do, I
think.
I'll stop here for now - but thanks for starting this work.
Spencer
From enrico.marocco at telecomitalia.it Fri Sep 8 11:57:26 2006
From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Fri, 08 Sep 2006 17:57:26 +0200
Subject: [p2p-sip] Questions on draft-marocco-p2psip-interwork-00
In-Reply-To: <091d01c6d2fc$577d2a50$0500a8c0@china.huawei.com>
References: <091d01c6d2fc$577d2a50$0500a8c0@china.huawei.com>
Message-ID: <450192E6.7070905@telecomitalia.it>
Spencer Dawkins wrote:
> It's probably premature to discuss this draft in detail, but I did have some
> questions as I read it, and asking now might help you prepare for the next
> version...
It will certainly do :-)
> The draft calls out I-D.willis-p2psip-concepts specifically, but the
> Introduction says
>
> This document describes how user agents registered in P2PSIP overlay
> networks [I-D.willis-p2psip-concepts] can interwork with those in
> conventional SIP networks [RFC3261]. In particular, no assumption is
> made about the overlay but that it allows clients to insert and
> retrieve routing information, possibly bound to URIs [RFC3986].
>
> Does "clients" mean "clients" in the I-D.willis-p2psip-concepts sense, or in
> some other sense?
Here "clients" mean "clients" in the concepts draft sense. Perhaps it
would be more appropriate to say "clients and peers" instead of just
"clients", since also peers perform store/retrieve operations.
> I really like the "P2PSIP Proxy Peers" term and description. You may have
> noticed some musing in my notes on I-D.willis-p2psip-concepts about a P2PSIP
> Overlay Server - I think this is pretty close to what I was thinking of. The
> direction of "proxying" is reversed, I think, but this might be
> symmetrical... Is it possible that the same concept might also work for the
> P2PSIP clients described in I-D.willis-p2psip-concepts?
In my view a "P2PSIP Proxy Peer" is a node which acts as a gateway for
SIP messages between the overlay and the Internet. I'm not sure I've
understood well what you mean by "P2PSIP Overlay Server", but your
question makes me think that perhaps our teminology is misleading. In
fact a "P2PSIP Proxy Peer" does not need to be a "P2PSIP Overlay Peer";
it is sufficient that it is registered in the overlay. If it routes
messages (across overlay's bounds obviously it does because it's a gw,
but also inside the overlay), stores data and performs join/leave
operations, we can say it's also a "P2PSIP Overlay Peer"; if it only
registers itself in the overlay, we can say it is a "P2PSIP Overlay
Client". If someone else registers it in the overlay, we can't say it
is a "P2PSIP Overlay Client" nor a "P2PSIP Overlay Peer", but it still
is a "P2PSIP Proxy Peer".
I'd like to further investigate on this.
> The Security Considerations section correctly describes the tension between
> "too easy to insert into DNS" and "too difficult to insert into DNS" - but
> that's awfully late in the draft to bring this up. Although
> security-related, it's pretty fundamental to what we're trying to do, I
> think.
That's true: that's exactly what open issue #5 means :-)
--
Ciao,
Enrico
--------------------------------------------------------------------
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster at telecomitalia.it.
Thank you
www.telecomitalia.it
--------------------------------------------------------------------
From abum at aftek.com Mon Sep 18 07:39:54 2006
From: abum at aftek.com (Abu M. Muttalib)
Date: Mon, 18 Sep 2006 17:09:54 +0530
Subject: [p2p-sip] Not able to get OK response for INVITE request
Message-ID:
Hi,
I am registered to one VoIP server.
In the first log, named,
"arcor.outgoing.on.landline.from.xpro.selected.cap", I am successfully
registered to the Server and am able to make outgoing call to a PSTN no.
In the second log, named,
"arcor.outgoing.on.landline.from.device.selected.cap", though I am
successfully registered, I am not able to make an outgoing call to a PSTN
no.
I tried to analyze the logs but was not able to figure out why I am not
getting the 200 OK in the response of my INVITE request.
Any lead will be appreciated. Please help.
Regards and anticipation,
Abu.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arcor.outgoing.on.landline.from.device.selected.cap
Type: application/octet-stream
Size: 10977 bytes
Desc: not available
Url : https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060918/0ccfebc6/arcor.outgoing.on.landline.from.device.selected-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arcor.outgoing.on.landline.from.xpro.selected.cap
Type: application/octet-stream
Size: 10977 bytes
Desc: not available
Url : https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060918/0ccfebc6/arcor.outgoing.on.landline.from.xpro.selected-0001.obj
From victor.pascual.avila at gmail.com Mon Sep 18 07:45:34 2006
From: victor.pascual.avila at gmail.com (=?ISO-8859-1?Q?Victor_Pascual_=C1vila?=)
Date: Mon, 18 Sep 2006 13:45:34 +0200
Subject: [p2p-sip] Re: Not able to get OK response for INVITE request
In-Reply-To:
References:
Message-ID: <618e24240609180445m7857ab0udc8bc0474342dd21@mail.gmail.com>
Hi abu,
2006/9/18, Abu M. Muttalib :
>
> Hi,
>
I am registered to one VoIP server.
>
> In the first log, named,
> "arcor.outgoing.on.landline.from.xpro.selected.cap", I am successfully
> registered to the Server and am able to make outgoing call to a PSTN no.
>
> In the second log, named,
> "arcor.outgoing.on.landline.from.device.selected.cap", though I am
> successfully registered, I am not able to make an outgoing call to a PSTN
> no.
are you using NAT? does the incoming call work?
Check nat configuration,maybe the VIA and Contact are not correct
I tried to analyze the logs but was not able to figure out why I am not
> getting the 200 OK in the response of my INVITE request.
do you get any 18x message (trying, ringing...)?
is the INVITE's SDP correct?
Any lead will be appreciated. Please help.
try to send an OPTIONS message to the proxy and see if you get response. If
not, verify port blocking configuration.
You can send an options just using sipsak tool.
Regards and anticipation,
> Abu.
You're welcome, i hope it'll be useful :)
_______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
>
>
>
--
Victor Pascual ?vila
mail:victor.pascual.avila at gmail.com
sip:victor.pascual at iptel.org
linux user: 224443
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060918/c0179aee/attachment.html
From Aisling.ODriscoll at cit.ie Mon Sep 18 16:46:40 2006
From: Aisling.ODriscoll at cit.ie (Aisling ODriscoll)
Date: Mon, 18 Sep 2006 21:46:40 +0100
Subject: [p2p-sip] P2P SIP MANETs
Message-ID: <07C0AAD24E652548B1F528DED7C034FDAD1E5C@sf-1.cit.ie>
?
Hello,
I would really appreciate if someone could perhaps explain if theres research issues to be addressed for using p2p sip over MANETs (mobile ad-hoc networks) and if so what are they?....I've seen some discussion about this but am a little bit confused about the conclusions drawn....does the underlying nework matter? I presume it would given that within a MANET some form of link breakage prediction may be required which may affect the DHT tables or something.....I've been reading alot of documents/presentations on p2p sip and chord etc....a few briefly mention MANETs but not in any great detail...This could be a good thing because it presents an open research area or a bad thing because theres nothing to research!!....any opinions would be appreciated.
Many thanks,
Aisling.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060918/997a8756/attachment.html
From softgear at dcn.ssu.ac.kr Mon Sep 18 20:43:53 2006
From: softgear at dcn.ssu.ac.kr (softgear)
Date: Tue, 19 Sep 2006 09:43:53 +0900
Subject: [p2p-sip] Not able to get OK response for INVITE request
In-Reply-To:
Message-ID: <003701c6db84$ae9d2ca0$dc5495dc@softgear>
Hello,
Both of two attached files are same to each other.
You got "503 Service Unavailable.". The cause 42 in that response means
following (from Q.850) "Cause No. 42 - Switching equipment congestion This
cause indicates that the switching equipment generating this cause is
experiencing a period of high traffic."
You may try again later or there is another reason (NAT is also possible
reason)
Seokkap Ko.
-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Abu M. Muttalib
Sent: Monday, September 18, 2006 8:40 PM
To: p2p-sip at cs.columbia.edu
Subject: [p2p-sip] Not able to get OK response for INVITE request
Hi,
I am registered to one VoIP server.
In the first log, named,
"arcor.outgoing.on.landline.from.xpro.selected.cap", I am successfully
registered to the Server and am able to make outgoing call to a PSTN no.
In the second log, named,
"arcor.outgoing.on.landline.from.device.selected.cap", though I am
successfully registered, I am not able to make an outgoing call to a PSTN
no.
I tried to analyze the logs but was not able to figure out why I am not
getting the 200 OK in the response of my INVITE request.
Any lead will be appreciated. Please help.
Regards and anticipation,
Abu.
From abum at aftek.com Tue Sep 19 02:47:11 2006
From: abum at aftek.com (Abu M. Muttalib)
Date: Tue, 19 Sep 2006 12:17:11 +0530
Subject: [p2p-sip] Not able to get OK response for INVITE request
In-Reply-To: <003701c6db84$ae9d2ca0$dc5495dc@softgear>
Message-ID:
Hi,
There is a difference in both the logs, in one I am getting proper 200 OK
for my INVITE but in another I am not. In the 1st I have dialed the PSTN no
from XPRO and in 2nd from My application. Still in the 2nd log I got 503. If
there were any congestion, I should have got the same error in both the
logs. This is not the case and I am not able to understand why its so.
Please help.
Regards,
Abu.
-----Original Message-----
From: softgear [mailto:softgear at dcn.ssu.ac.kr]
Sent: Tuesday, September 19, 2006 6:14 AM
To: 'Abu M. Muttalib'; p2p-sip at cs.columbia.edu
Subject: RE: [p2p-sip] Not able to get OK response for INVITE request
Hello,
Both of two attached files are same to each other.
You got "503 Service Unavailable.". The cause 42 in that response means
following (from Q.850) "Cause No. 42 - Switching equipment congestion This
cause indicates that the switching equipment generating this cause is
experiencing a period of high traffic."
You may try again later or there is another reason (NAT is also possible
reason)
Seokkap Ko.
-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Abu M. Muttalib
Sent: Monday, September 18, 2006 8:40 PM
To: p2p-sip at cs.columbia.edu
Subject: [p2p-sip] Not able to get OK response for INVITE request
Hi,
I am registered to one VoIP server.
In the first log, named,
"arcor.outgoing.on.landline.from.xpro.selected.cap", I am successfully
registered to the Server and am able to make outgoing call to a PSTN no.
In the second log, named,
"arcor.outgoing.on.landline.from.device.selected.cap", though I am
successfully registered, I am not able to make an outgoing call to a PSTN
no.
I tried to analyze the logs but was not able to figure out why I am not
getting the 200 OK in the response of my INVITE request.
Any lead will be appreciated. Please help.
Regards and anticipation,
Abu.
From fluffy at cisco.com Tue Sep 19 12:15:49 2006
From: fluffy at cisco.com (Cullen Jennings)
Date: Tue, 19 Sep 2006 09:15:49 -0700
Subject: [p2p-sip] __A_New_Internet-draft_is_available
In-Reply-To: <002b01c6c7bc$62d76460$7f0010ac@pi2000>
References: <00b101c6c7a0$1f4072d0$51bd3d05@matthewdesk>
<008601c6c7a3$044894a0$030aa8c0@comcast.net>
<002b01c6c7bc$62d76460$7f0010ac@pi2000>
Message-ID: <3C8242B4-F1C7-4547-B8A5-E9FAD686F121@cisco.com>
On Aug 24, 2006, at 1:32 PM, Peter Pan wrote:
> When some Asian spell burrito (slang) and drumstick, they are not
> fast food
> but ... :)
I apologize for my lack of understanding here but what is "burrito"
slang for? and drumstick?
From huang-ming.pan at comcast.net Tue Sep 19 14:23:53 2006
From: huang-ming.pan at comcast.net (Peter Pan)
Date: Tue, 19 Sep 2006 11:23:53 -0700
Subject: [p2p-sip] __A_New_Internet-draft_is_available
References: <00b101c6c7a0$1f4072d0$51bd3d05@matthewdesk>
<008601c6c7a3$044894a0$030aa8c0@comcast.net>
<002b01c6c7bc$62d76460$7f0010ac@pi2000>
<3C8242B4-F1C7-4547-B8A5-E9FAD686F121@cisco.com>
Message-ID: <001201c6dc18$c3323090$030aa8c0@comcast.net>
Theoretical P2P-SIP is too boring, so needs some rated R :?
Wanna understand it? Come visiting the beautiful country of Naruw'an
island -- Taiwan.
(http://202.39.225.132/jsp/Eng/html/search/index.jsp)
Enjoy.
----- Original Message -----
From: "Cullen Jennings"
To: "Peter Pan"
Cc: "P2P-SIP"
Sent: Tuesday, September 19, 2006 9:15 AM
Subject: Re: [p2p-sip] __A_New_Internet-draft_is_available
>
> On Aug 24, 2006, at 1:32 PM, Peter Pan wrote:
>
> > When some Asian spell burrito (slang) and drumstick, they are not
> > fast food
> > but ... :)
>
> I apologize for my lack of understanding here but what is "burrito"
> slang for? and drumstick?
>
From softgear at dcn.ssu.ac.kr Wed Sep 20 02:56:05 2006
From: softgear at dcn.ssu.ac.kr (Softgear Ko)
Date: Wed, 20 Sep 2006 15:56:05 +0900
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
In-Reply-To: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com>
Message-ID: <001901c6dc81$d84a7cd0$dc5495dc@softgear>
Hello.
In Reference Model Figure, "Client Protocol" is connected to "Peer
Protocol" directly. I don't think it makes sense. We have to insert the node
which can connect to two protocols. It can be "Peer".
I think, original figure's lines around P2PSIP overlay stand for kind of
network cloud -not connection.
Seokkap Ko.
-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Spencer Dawkins
Sent: Friday, September 08, 2006 4:58 AM
To: p2p-sip at cs.columbia.edu
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
I'm trying to get through this document at several levels - I hope these
comments are coherent (and helpful).
Summary - the document is really a good start, even though I have lots of
notes and suggestions. Thanks for the hard work.
Thanks,
Spencer Dawkins
High-level comments ...
- in general, I'd like to tighten up the terminology that we use. There are
terms with four additional "short forms" listed. This seems unnecessarily
confusing. It is OK to have a short form, but can we deprecate at least some
of the choices?
- as a follow-on, it's not clear to me how much of the terminology is P2PSIP
and how much is P2P in general. For example, is there anything special about
a "P2PSIP Overlay Key", compared to an "overlay key"?
- Figure 1 seems confused on whether the UA/Peers behind the NATs are part
of the overlay or not - I think I can draw the lines more clearly (shown
below), assuming that they ARE part of the overlay.
- Figure 1 is also trying to do more than you can do in ASCII art (at least
I think so) - the dotted lines either mean (a) logical connectivity in the
overlay, (b) physical connectivity through the NATs, or (c) a SIP call. I
doubled the lines for the overlay topology, but left the SIP calls in and
don't like the result. If people agree, I can do ASCII art for (a) and (c),
as two figures.
- I'm very confused about how both clients and peers can be "endpoints". For
one thing, I'm not sure how "endpoint-to-endpoint trust" works. I suspect
that this is conflating P2P endpoints (peers) with SIP endpoints (either a
UA-peer or a UA-client). If you guys understand this perfectly, please keep
typing...
- I'm somewhat confused about how we can talk about P2PSIP peers and clients
without talking about something like a P2PSIP Overlay Server (see comments
below).
Detailed comments ...
2. Definitions
P2PSIP Overlay User Agent: A SIP user agent that is coupled to a
P2PSIP Overlay Peer or P2PSIP Overlay Client, such that the peer
or client can assist the UA with registration (storage of a route
to users of the UA) and/or routing of requests using the P2PSIP
Overlay. A P2PSIP Overlay SUer Agent differs from a conventional
s/SU/Us/
SIP user agent in that it is coupled directly to a P2PSIP Overlay
Peer or P2PSIP Overlay Client, and can therefore directly interact
with a P2PSIP Overlay, which a conventional SIP UA cannot do.
P2PSIP Overlay User Agents are presumed to have no distinguished
name or identifier. Short forms: overlay UA, P2PSIP UA.
P2PSIP Overlay Bootstrap Server: A network node used by P2PSIP
Overlay Peers or Clients who are attempting to enter to locate an
entry into the P2P Overlay Network. It may return an entry point
(address of a Peer) to the P2PSIP Overlay or act as one itself.
This should be a quasi-stable and well known host, located using a
configuration or discovered via , DNS, broadcast, or other
mechanism. Example: a P2PSIP Overlay Peer that reboots and has no
knowledge of other peers uses a P2PSIP Overlay Bootstrap Server to
find other peers in the P2P Overlay Network and establish P2PSIP
Overlay Peer Insertion. (Note: An overlay peer might or might not
provide this functionality). Short forms: bootstrap server, boot
server.
These short forms seem very likely to conflict with lower-layer usage of the
same terms, where "bootstrap server" and "boot server" have a
well-understood usage. "Overlay bootstrap server" as short form?
3. Discussion
3.1. What Kinds of P2PSIP Overlay Peers and Clients Might Exist?
3. Gateway: a peer or client that converts from P2PSIP to some other
protocol, such as PSTN.
"PSTN" should be expanded on first use. It is expanded, but not on first
use.
4. Redirector or Location Server: a peer or client that, given a SIP
Is this a "SIP INVITE", or something else? looks like a cut and paste error.
(or other SIP request) to a P2PSIP overlay resource identifier,
returns the route to a resource in a 302 or 305 response.
3.2. Reference Model
Note - this is my redrawn picture, with changes on the left...
--->PSTN
-----------/
-------- |N| | Gateway |
| |========|A|========| Peer |==============
| UA | |T| | | ||Client Protocol
| Peer | ----------- || GET/PUT
| C | || |
-------- || | \__/
|| || v / \
|NAT| ||---- / UA \
|| P2PSIP Overlay || /Client\
|| || |______|
|| Route Data || ^
-------- -------- || |
| | |N| | | || |
| UA |=|A|==| UA | || |
| Peer | |T| | Peer | || |
| D | | E | || |
-------- -------- || |SIP
Peer Protocol || --------- --------- || |
|| | | | | || |
====| Proxy |========| Redir |==== |
| Peer | | Peer | |
| | | | |
--------- ---------- |
/ \ /
/ \ /
\__/ / SIP SIP \ \__/ /
/\ / \ /\ /
/ \/ \/ \/
/ UA \ / UA \
/______\ /______\
SIP UA A SIP UA B
Figure: Reference Model
Here, the large rectangle represents the P2PSIP Overlay and its
associated routing data. Around the periphery of the P2PSIP Overlay
rectangle, we have several P2PSIP Overlay Peer nodes -- a PSTN
gateway, a user-agent, a proxy, and a redirector. To the left we
have two UA peers are behind network address translator. On the
right side, we have a P2PSIP Overlay "UA client", which uses the
P2PSIP Overlay Client Protocol to interact with the P2PSIP Overlay.
Below, we have conventional SIP UA "A", which has used SIP to
interact with the Proxy Peer and establish a dialog with the UA peer,
There were three unnamed "UA peers" on the diagram. I'm not sure which one
you were talking about, and I couldn't figure that out from the diagram (see
previous whining about combining logical network topology and call paths on
one diagram) but I at least named them in the diagram, so you can call one
out in the text.
and SIP UA "B" which has been redirected by the Redirect Peer and set
up a dialog with the UA Client. Note that the Proxy Peer and the UA
Peer interact using the P2PSIP Overlay Peer Protocol, which is also
presumably used on the keepalive links between the UA Peers and their
"keepalive links" hasn't been defined, and I'm not happy with the term. Are
these any more than "logical links", in this context?
neighbors.
3.3. Conceptual Outline of Operations
3.3.1. Enrolling and Inserting an P2PSIP Overlay Peer
Peers are the full-function "routing and storage" nodes of a P2PSIP
Overlay. When a new peer is first created, it must enroll in the
P2PSIP Overlay. We currently have no defined mechanism for this (do
we need one?), but we know that once the process is complete, the new
I think this is required for the ad hoc scenarios, isn't it?
peer will have at least a P2PSIP Overlay Peer Key and a set of
credentials.
After enrollment, each time the peer connects to the overlay, it must
insert itself. We don't have a defined protocol and process for
this, and assume we need one. Presumably the inserting peer connects
I agree that we need one.
to one or more existing peers (possibly with the aid of a bootstrap
server) presents its credentials, and ends up connected to the
overlay, with some knowledge of neighbors (successor, precursor,
finger tables, or whatever the distribution mechanism defines) and is
able to store data on behalf of and route requests to other nodes in
the P2PSIP overlay.
3.3.2. More on The Difference Between a Peer, Client, and User Agent
P2PSIP Overlay Peers directly interact with and contain the routing
and storage fabric of the overlay. P2PSIP Overlay Clients just use
the routing and storage facilities provided by the peers. The peers
speak the P2PSIP Overlay Peer Protocol, which presumably has a full
range of expressivity for the routing and storage facilities of the
"expressivity" is a great word. Is it defined anywhere? ;-)
overlay. Clients speak the P2PSIP Overlay Client protocol, which is
presumably a subset of the peer protocol, and is limited to storage
insertion (put), storage retrieval (get), and message routing (send).
Some peers and some clients may be coupled to SIP user agents, making
them P2PSIP Overlay User Agents capable of both sending and receiving
conventional SIP messages (as per a SIP UA) using conventional SIP
resolution procedures and of using the resolution facilities provided
by the overlay
(missing period after this sentence)
3.3.3. Enrolling a User and Inserting a P2PSIP Overlay User Agent
To get started, users must be enrolled in the overlay. We do not
have a process or protocol for this, nor are we certain we need a
standardized mechanism. We presume that after enrollment, the user
has a distinguished name within the overlay (example:
sip:bob at example.com) and a set of credentials useful for
authenticating its usage of the distinguished name. One possible
mechanism for these credentials would be an x.509 certificate. It
might also be possible to use a PGP key, a password, or some other
mechanism. Presumably following enrollment, the user is also
equipped with the information needed to connect to the overlay, such
as the address of a bootstrap server. Whether this startup
information is delivered as a part of enrollment of through some
separate configuration process remains an open question.
I would like to define this, but am concerned that the choice may differ
per-overlay. Do others agree?
3.3.4. Placing a Call from a P2PSIP Overlay Client UA to a P2PSIP
Overlay Client UA
Assume we have two users, Alice and Bob, who have successfully
enrolled and inserted themselves into a P2PSIP Overlay using clients.
Alice wants to call Bob, and enters Bob's user identity (AOR) into
her client. Alice's client does not have current knowledge of a
route-set to Bob's client(s), so it needs to discover one. Alice's
I was confused here. This text doesn't point anywhere for "it needs to
discover one", so the reader is left to assume that "Alice's Client then
does a GET operation on Bob's identity" is how that discovery happens, but
"then does a GET" sounds like it happens AFTER discovering a route-set. If
this is how discovery happens, please remove "then", and maybe even go to
"it needs to discover one by doing a GET operation on Bob's identity".
Client then does a GET operation on Bob's identity, using a
previously-discovered peer, or using whatever procedures are needed
(such as RFC 3263, a bootstrap server, etc.) to find a peer. Alice's
client send the GET request to the selected peer.
3.3.5. Bootstrapping
If a client or peer is just starting up and has no knowledge of how
to reach the other nodes of the overlay, it may exercise a bootstrap
server to find one. Presumably it discovers the bootstrap server by
some mechanism such as a DNS lookup, multicast, broadcast or
configuration, then queries the bootstrap server and receives an
address for a peer or set of peers that can be used to reach the
overlay. Ideally, these target peers will be selected from a
relatively large pool of peers that are currently online and
reachable.
This last sentence seems awfully use case-specific, doesn't it?
After discovering the address of a peer, the behavior of the starting
node will vary depending on whether it is intending to be a peer or a
Ouch - if I have a peer, I would think that I'm a peer, too. Is the client
actually discovering something like a "P2PSIP Overlay Server"?
client. If it is intending to be a peer, it goes into the P2PSIP
Overlay Peer Insertion process, at the conclusion of which it is
actively participating in the target overlay as a peer and is capable
of routing requests and storing records on behalf of the P2PSIP
overlay. If it is intending to be a client, it does not bother with
insertion, but merely contacts the discovered peer in order to use
the overlay.
4. Questions
4.4. Universal Routing:
Do all P2PSIP Overlay Peers route requests? How about clients?
I thought this was one of the differences between peers and clients. If it's
not, what's the difference?
4.9. Cryptotransparency
When forwarding requests, are the bodies of the requests visible to
peers? If so, this creates substantial security problems that the
deployers of conventional SIP have been willing to mostly ignore.
Can we make peers cryptotransparent (like HTTP proxies) when security
is requested?
I believe this question is key when we discuss what an endpoint is (see
previous comments on whether clients are endpoints).
4.13. Bootstrapping
We know that sometimes peers or clients will start up without
knowledge of how to find a peer for insertion. Do we need to define
a bootstrap mechanism or mechanisms? Do we need to define supporting
protocols?
I believe the answer to both of these is "yes" to support anything like ad
hoc use cases.
4.15. Overlapping Domains
If the P2PSIP Overlay User Identifier is not scoped to a single DNS
domain, this would appear to allow nodes from two or more apparent
domains to share a single P2PSIP Overlay. What, if anything, do we
need to say about this mode of operation?
If a peer can locate an appropriate overlay AND provide appropriate
credentials, what would prevent us from supporting this?
4.16. Hybrid Domains
It appears possible to have some hosts within a domain using
conventional SIP and some using P2PSIP. This potentially raises a
number of questions: 1) What should happen if we want to run a P2PSIP
overlay in an existing SIP domain? 2) Do the existing redir/proxy
servers need to be coupled with a peer layer? 3) When would an
overlay peer want to discover them as opposed to looking in the
overlay? 4) Is better not to run conventional SIP with overlay SIP?
5) When conventional and P2PSIP are run together, shall the existing
redir servers keep their local databases or switch to the overlay
storage.
We've had some discussion on-list here about whether I have the same AOR in
conventional SIP and P2PSIP overlays or not. Did we converge?
4.17. Admissions Control
What do we need to say about admissions control with respect to the
enrollment of peers and users? Do we need to discuss per-call
admissions control in a P2P environment?
I can imagine admissions control for enrollment, but I'm having a hard time
imagining per-call admissions control in a decentralized P2P overlay - or
was this the point of the question?
_______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
From dean.willis at softarmor.com Wed Sep 20 10:49:59 2006
From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 20 Sep 2006 09:49:59 -0500
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
In-Reply-To: <001901c6dc81$d84a7cd0$dc5495dc@softgear>
References: <001901c6dc81$d84a7cd0$dc5495dc@softgear>
Message-ID: <56C17ACF-4531-45B4-A978-3147DA694B61@softarmor.com>
On Sep 20, 2006, at 1:56 AM, Softgear Ko wrote:
> Hello.
>
> In Reference Model Figure, "Client Protocol" is connected to "Peer
> Protocol" directly. I don't think it makes sense. We have to insert
> the node
> which can connect to two protocols. It can be "Peer".
> I think, original figure's lines around P2PSIP overlay stand for
> kind of
> network cloud -not connection.
Hmm. I'm not reading the figure that way, but the fact that you are
concerns me. I'm becoming less and less fond of this drawing as time
progresses.
Anybody have a better idea they can render in ASCII art?
--
Dean
From spencer at mcsr-labs.org Wed Sep 20 10:56:38 2006
From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Wed, 20 Sep 2006 09:56:38 -0500
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
References: <001901c6dc81$d84a7cd0$dc5495dc@softgear>
<56C17ACF-4531-45B4-A978-3147DA694B61@softarmor.com>
Message-ID: <094b01c6dcc4$fc3c0350$0300a8c0@china.huawei.com>
>> Hello.
>>
>> In Reference Model Figure, "Client Protocol" is connected to "Peer
>> Protocol" directly. I don't think it makes sense. We have to insert the
>> node
>> which can connect to two protocols. It can be "Peer".
>> I think, original figure's lines around P2PSIP overlay stand for kind of
>> network cloud -not connection.
>
> Hmm. I'm not reading the figure that way, but the fact that you are
> concerns me. I'm becoming less and less fond of this drawing as time
> progresses.
>
> Anybody have a better idea they can render in ASCII art?
Hi, Dean,
Have you gotten a chance to look at my revision?
>From the first note in this thread...
--->PSTN
-----------/
-------- |N| | Gateway |
| |========|A|========| Peer |==============
| UA | |T| | | ||Client Protocol
| Peer | ----------- || GET/PUT
| C | || |
-------- || | \__/
|| || v / \
|NAT| ||---- / UA \
|| P2PSIP Overlay || /Client\
|| || |______|
|| Route Data || ^
-------- -------- || |
| | |N| | | || |
| UA |=|A|==| UA | || |
| Peer | |T| | Peer | || |
| D | | E | || |
-------- -------- || |SIP
Peer Protocol || --------- --------- || |
|| | | | | || |
====| Proxy |========| Redir |==== |
| Peer | | Peer | |
| | | | |
--------- ---------- |
/ \ /
/ \ /
\__/ / SIP SIP \ \__/ /
/\ / \ /\ /
/ \/ \/ \/
/ UA \ / UA \
/______\ /______\
SIP UA A SIP UA B
Figure: Reference Model
My comments on the original version were
- Figure 1 seems confused on whether the UA/Peers behind the NATs are part
of the overlay or not - I think I can draw the lines more clearly (shown
below), assuming that they ARE part of the overlay.
- Figure 1 is also trying to do more than you can do in ASCII art (at least
I think so) - the dotted lines either mean (a) logical connectivity in the
overlay, (b) physical connectivity through the NATs, or (c) a SIP call. I
doubled the lines for the overlay topology, but left the SIP calls in and
don't like the result. If people agree, I can do ASCII art for (a) and (c),
as two figures.
Any thoughts?
Thanks,
Spencer
From dean.willis at softarmor.com Wed Sep 20 16:01:09 2006
From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 20 Sep 2006 15:01:09 -0500
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
Message-ID: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
Eunsoo, David, Bryan, Cullen and I have gone around on the charter
several times, hoping to build-in what we learned at the last ad-hoc
and from IESG comments received.
Here's where I think we're at. It's MUCH smaller than what we started
with, and I feel fairly good about it.
Peer-to-Peer Session Initiation Protocol (P2PSIP)
Chairs:
TBD
RAI Area Director(s):
Cullen Jennings
Jon Peterson
RAI Area Advisor:
Cullen Jennings
Mailing Lists:
General Discussion: p2p-sip at cs.columbia.edu
Subscribe at: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/
Description of the Working Group:
The Peer-to-Peer (P2P) Session Initiation Protocol working group
(P2PSIP WG) is chartered to develop protocols and mechanisms for the
use of the Session Initiation Protocol (SIP) in settings where the
service of establishing and managing sessions is principally handled
by a collection of intelligent endpoints, or P2PSIP overlay peers,
rather
than centralized servers as in client-server SIP as currently deployed.
A number of cases where such an architecture is desirable have been
documented in [1].
The terminology and concepts draft [2] explains the terms and concepts
used here. The work focuses on collections of nodes called "P2PSIP
overlay peers" and "P2PSIP overlay clients". P2PSIP overlay peers
manifest
a distributed namespace in which overlay users are identified and
provides
mechanisms for locating users or resources within the P2PSIP overlay.
P2PSIP overlay clients and peers use the resolution services of the
peers
as an alternative to the SIP correspondent discovery process of RFC
3263.
Session management, messaging, and presence functions are performed
using traditional SIP.
This group's primary tasks are to produce:
1. An overview document explaining concepts, terminology, rationale,
and illustrative use cases for the remaining work.
2. A proposed standard defining a P2PSIP Overlay Peer Protocol. This
protocol is used between P2PSIP overlay peers, some of which may be
behind NATs. This protocol will define how the P2PSIP overlay peers
collectively provide for user and resource location in a SIP environment
with no or minimal centralized serves. This protocol may or may not be
syntactically based on SIP, a decision to be made by the WG. The
group will identify and require one base P2P algorithm (likely a
particular
Distributed Hash Table (DHT) algorithm), while allowing for additional
optional algorithms in the future.
3. A proposed standard defining a P2PSIP Overlay Client Protocol for
use by P2PSIP overlay clients, some of which may be behind NATs. This
protocol will define how the P2PSIP overlay clients query and/or modify,
the resource location information of the overlay. While clearly a
logical
subset of the P2PSIP Overlay Protocol, the WG will determine if the
client
protocol is a syntactic subset of the peer protocol, and whether the
client
protocol has SIP based syntax.
4. An architecture document. This document will address how the
protocols
defined above, along with existing IETF protocols, can be used to
produce
systems to locate a user, identify appropriate resources to facilitate
communications (for example media relays), and establish communications
between the users, without relying on centralized servers.
The work planned for the P2PSIP working group is distinct from, but
requires close participation with other IETF WGs, particularly SIP,
SIPPING, SIMPLE, BEHAVE and MMUSIC. The group cannot modify the
baseline SIP behavior, define a new version of SIP, or attempt to
produce a parallel protocol for session establishment. If
the group determines that any capabilities requiring an extension to
SIP are needed, the group will seek to define such extensions within
the SIP working group using the SIP change process (RFC 3427).
Similarly, existing tools developed in the BEHAVE and MMUSIC groups
will be used for NAT traversal, with extensions or changes desired to
support P2PSIP created in these groups.
The working group takes it as an unfortunate fact that NATs and
firewalls exist in the Internet, and will ensure that the protocols
produced work in their presence as much as possible. Similarly, the
group will attempt not to make design decisions that preclude
anonymous communications systems from being crafted using the
protocols defined by this WG.
The following topics are excluded from the Working Group's scope:
1. Issues specific to applications other than locating users and
resources for SIP-based communications and presence.
2. Solving "research" type questions related to P2PSIP or P2P in
general. The WG will instead forward such work to the IRTF. Examples
include fully distributed schemes for assuring unique user identities
and the development of P2P-based replacements for DNS.
3. Locating resources based on something other than URIs.
In other words, arbitrary search of attributes is out of scope, but
locating resources based on their URIs is in scope.
4. Multicast and dynamic DNS based approaches for locating
users and resources.
Goals and Milestones
Sep 2007 Submit P2PSIP overview document to the IESG
(Informational)
Sep 2008 Submit P2PSIP overlay client protocol document to the
IESG (Standards track)
Sep 2008 Submit P2PSIP overlay peer protocol document to the
IESG (Standards track)
May 2009 Submit P2PSIP architecture document to the IESG
(Standards track)
References
[1] D. Bryan, E. Shim, B. B. Lowekamp, "Use Cases for Peer-to-Peer
Session Initiation Protocol (P2PSIP)",
draft-bryan-sipping-p2p-usecases-00.txt, November 29, 2005
[2] D. Willis, D. Bryan, P. Matthews, E. Shim, "Concepts and
Terminology for Peer to Peer SIP," draft-willis-p2psip-concepts-01.txt
(work-in-progress), August 18, 2006
From spencer at mcsr-labs.org Wed Sep 20 16:34:38 2006
From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Wed, 20 Sep 2006 15:34:38 -0500
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
Message-ID: <0e4d01c6dcf4$31b90da0$0300a8c0@china.huawei.com>
Hi, Dean/Eunsoo/David/Bryan/Cullen,
This actually does look fairly good (Dean's words). I have a couple of
questions.
- I have unanswered comments on the current concepts/terminology draft that
are applicable to the charter (since it uses terminology from that draft).
Does this mean that I have comments on the charter?
- I won't challenge the dates because they may very well be realistic, but
they sure are a long way into the future.
- The current use cases draft has use cases that would benefit from
multicast discovery. Does excluding multicast discovery sidestep
prioritization of use cases?
- Forwarding research topics "to the IRTF" - does this mean "to the IRTF
P2PRG research group"?
Thanks,
Spencer
>
> Eunsoo, David, Bryan, Cullen and I have gone around on the charter
> several times, hoping to build-in what we learned at the last ad-hoc
> and from IESG comments received.
>
> Here's where I think we're at. It's MUCH smaller than what we started
> with, and I feel fairly good about it.
>
>
>
>
> Peer-to-Peer Session Initiation Protocol (P2PSIP)
>
> Chairs:
> TBD
>
> RAI Area Director(s):
> Cullen Jennings
> Jon Peterson
>
> RAI Area Advisor:
> Cullen Jennings
>
> Mailing Lists:
> General Discussion: p2p-sip at cs.columbia.edu
> Subscribe at: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
> Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/
>
> Description of the Working Group:
>
> The Peer-to-Peer (P2P) Session Initiation Protocol working group
> (P2PSIP WG) is chartered to develop protocols and mechanisms for the
> use of the Session Initiation Protocol (SIP) in settings where the
> service of establishing and managing sessions is principally handled
> by a collection of intelligent endpoints, or P2PSIP overlay peers,
> rather
> than centralized servers as in client-server SIP as currently deployed.
> A number of cases where such an architecture is desirable have been
> documented in [1].
>
> The terminology and concepts draft [2] explains the terms and concepts
> used here. The work focuses on collections of nodes called "P2PSIP
> overlay peers" and "P2PSIP overlay clients". P2PSIP overlay peers
> manifest
> a distributed namespace in which overlay users are identified and
> provides
> mechanisms for locating users or resources within the P2PSIP overlay.
> P2PSIP overlay clients and peers use the resolution services of the
> peers
> as an alternative to the SIP correspondent discovery process of RFC
> 3263.
> Session management, messaging, and presence functions are performed
> using traditional SIP.
>
> This group's primary tasks are to produce:
>
> 1. An overview document explaining concepts, terminology, rationale,
> and illustrative use cases for the remaining work.
>
> 2. A proposed standard defining a P2PSIP Overlay Peer Protocol. This
> protocol is used between P2PSIP overlay peers, some of which may be
> behind NATs. This protocol will define how the P2PSIP overlay peers
> collectively provide for user and resource location in a SIP environment
> with no or minimal centralized serves. This protocol may or may not be
> syntactically based on SIP, a decision to be made by the WG. The
> group will identify and require one base P2P algorithm (likely a
> particular
> Distributed Hash Table (DHT) algorithm), while allowing for additional
> optional algorithms in the future.
>
> 3. A proposed standard defining a P2PSIP Overlay Client Protocol for
> use by P2PSIP overlay clients, some of which may be behind NATs. This
> protocol will define how the P2PSIP overlay clients query and/or modify,
> the resource location information of the overlay. While clearly a
> logical
> subset of the P2PSIP Overlay Protocol, the WG will determine if the
> client
> protocol is a syntactic subset of the peer protocol, and whether the
> client
> protocol has SIP based syntax.
>
> 4. An architecture document. This document will address how the
> protocols
> defined above, along with existing IETF protocols, can be used to
> produce
> systems to locate a user, identify appropriate resources to facilitate
> communications (for example media relays), and establish communications
> between the users, without relying on centralized servers.
>
> The work planned for the P2PSIP working group is distinct from, but
> requires close participation with other IETF WGs, particularly SIP,
> SIPPING, SIMPLE, BEHAVE and MMUSIC. The group cannot modify the
> baseline SIP behavior, define a new version of SIP, or attempt to
> produce a parallel protocol for session establishment. If
> the group determines that any capabilities requiring an extension to
> SIP are needed, the group will seek to define such extensions within
> the SIP working group using the SIP change process (RFC 3427).
> Similarly, existing tools developed in the BEHAVE and MMUSIC groups
> will be used for NAT traversal, with extensions or changes desired to
> support P2PSIP created in these groups.
>
> The working group takes it as an unfortunate fact that NATs and
> firewalls exist in the Internet, and will ensure that the protocols
> produced work in their presence as much as possible. Similarly, the
> group will attempt not to make design decisions that preclude
> anonymous communications systems from being crafted using the
> protocols defined by this WG.
>
> The following topics are excluded from the Working Group's scope:
>
> 1. Issues specific to applications other than locating users and
> resources for SIP-based communications and presence.
>
> 2. Solving "research" type questions related to P2PSIP or P2P in
> general. The WG will instead forward such work to the IRTF. Examples
> include fully distributed schemes for assuring unique user identities
> and the development of P2P-based replacements for DNS.
>
> 3. Locating resources based on something other than URIs.
> In other words, arbitrary search of attributes is out of scope, but
> locating resources based on their URIs is in scope.
>
> 4. Multicast and dynamic DNS based approaches for locating
> users and resources.
>
> Goals and Milestones
>
> Sep 2007 Submit P2PSIP overview document to the IESG
> (Informational)
>
> Sep 2008 Submit P2PSIP overlay client protocol document to the
> IESG (Standards track)
>
> Sep 2008 Submit P2PSIP overlay peer protocol document to the
> IESG (Standards track)
>
> May 2009 Submit P2PSIP architecture document to the IESG
> (Standards track)
>
>
> References
>
> [1] D. Bryan, E. Shim, B. B. Lowekamp, "Use Cases for Peer-to-Peer
> Session Initiation Protocol (P2PSIP)",
> draft-bryan-sipping-p2p-usecases-00.txt, November 29, 2005
>
> [2] D. Willis, D. Bryan, P. Matthews, E. Shim, "Concepts and
> Terminology for Peer to Peer SIP," draft-willis-p2psip-concepts-01.txt
> (work-in-progress), August 18, 2006
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
From hsinnrei at adobe.com Wed Sep 20 16:47:54 2006
From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Wed, 20 Sep 2006 13:47:54 -0700
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D221558FA@namail5.corp.adobe.com>
This is an excellent charter.
Nothing is perfect so I suggest we leave 'as is'.
The only comment I have is that 3 years is a long time for this work on
definitions (mainly).
How many users will Skype have by then? :-)
Or even worse, how many incompatible P2P SIP implementations will there
be?
Henry
-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Dean Willis
Sent: Wednesday, September 20, 2006 4:01 PM
To: p2p-sip at cs.columbia.edu
Cc: David A. Bryan
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
Eunsoo, David, Bryan, Cullen and I have gone around on the charter
several times, hoping to build-in what we learned at the last ad-hoc
and from IESG comments received.
Here's where I think we're at. It's MUCH smaller than what we started
with, and I feel fairly good about it.
Peer-to-Peer Session Initiation Protocol (P2PSIP)
Chairs:
TBD
RAI Area Director(s):
Cullen Jennings
Jon Peterson
RAI Area Advisor:
Cullen Jennings
Mailing Lists:
General Discussion: p2p-sip at cs.columbia.edu
Subscribe at: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/
Description of the Working Group:
The Peer-to-Peer (P2P) Session Initiation Protocol working group
(P2PSIP WG) is chartered to develop protocols and mechanisms for the
use of the Session Initiation Protocol (SIP) in settings where the
service of establishing and managing sessions is principally handled
by a collection of intelligent endpoints, or P2PSIP overlay peers,
rather
than centralized servers as in client-server SIP as currently deployed.
A number of cases where such an architecture is desirable have been
documented in [1].
The terminology and concepts draft [2] explains the terms and concepts
used here. The work focuses on collections of nodes called "P2PSIP
overlay peers" and "P2PSIP overlay clients". P2PSIP overlay peers
manifest
a distributed namespace in which overlay users are identified and
provides
mechanisms for locating users or resources within the P2PSIP overlay.
P2PSIP overlay clients and peers use the resolution services of the
peers
as an alternative to the SIP correspondent discovery process of RFC
3263.
Session management, messaging, and presence functions are performed
using traditional SIP.
This group's primary tasks are to produce:
1. An overview document explaining concepts, terminology, rationale,
and illustrative use cases for the remaining work.
2. A proposed standard defining a P2PSIP Overlay Peer Protocol. This
protocol is used between P2PSIP overlay peers, some of which may be
behind NATs. This protocol will define how the P2PSIP overlay peers
collectively provide for user and resource location in a SIP environment
with no or minimal centralized serves. This protocol may or may not be
syntactically based on SIP, a decision to be made by the WG. The
group will identify and require one base P2P algorithm (likely a
particular
Distributed Hash Table (DHT) algorithm), while allowing for additional
optional algorithms in the future.
3. A proposed standard defining a P2PSIP Overlay Client Protocol for
use by P2PSIP overlay clients, some of which may be behind NATs. This
protocol will define how the P2PSIP overlay clients query and/or modify,
the resource location information of the overlay. While clearly a
logical
subset of the P2PSIP Overlay Protocol, the WG will determine if the
client
protocol is a syntactic subset of the peer protocol, and whether the
client
protocol has SIP based syntax.
4. An architecture document. This document will address how the
protocols
defined above, along with existing IETF protocols, can be used to
produce
systems to locate a user, identify appropriate resources to facilitate
communications (for example media relays), and establish communications
between the users, without relying on centralized servers.
The work planned for the P2PSIP working group is distinct from, but
requires close participation with other IETF WGs, particularly SIP,
SIPPING, SIMPLE, BEHAVE and MMUSIC. The group cannot modify the
baseline SIP behavior, define a new version of SIP, or attempt to
produce a parallel protocol for session establishment. If
the group determines that any capabilities requiring an extension to
SIP are needed, the group will seek to define such extensions within
the SIP working group using the SIP change process (RFC 3427).
Similarly, existing tools developed in the BEHAVE and MMUSIC groups
will be used for NAT traversal, with extensions or changes desired to
support P2PSIP created in these groups.
The working group takes it as an unfortunate fact that NATs and
firewalls exist in the Internet, and will ensure that the protocols
produced work in their presence as much as possible. Similarly, the
group will attempt not to make design decisions that preclude
anonymous communications systems from being crafted using the
protocols defined by this WG.
The following topics are excluded from the Working Group's scope:
1. Issues specific to applications other than locating users and
resources for SIP-based communications and presence.
2. Solving "research" type questions related to P2PSIP or P2P in
general. The WG will instead forward such work to the IRTF. Examples
include fully distributed schemes for assuring unique user identities
and the development of P2P-based replacements for DNS.
3. Locating resources based on something other than URIs.
In other words, arbitrary search of attributes is out of scope, but
locating resources based on their URIs is in scope.
4. Multicast and dynamic DNS based approaches for locating
users and resources.
Goals and Milestones
Sep 2007 Submit P2PSIP overview document to the IESG
(Informational)
Sep 2008 Submit P2PSIP overlay client protocol document to the
IESG (Standards track)
Sep 2008 Submit P2PSIP overlay peer protocol document to the
IESG (Standards track)
May 2009 Submit P2PSIP architecture document to the IESG
(Standards track)
References
[1] D. Bryan, E. Shim, B. B. Lowekamp, "Use Cases for Peer-to-Peer
Session Initiation Protocol (P2PSIP)",
draft-bryan-sipping-p2p-usecases-00.txt, November 29, 2005
[2] D. Willis, D. Bryan, P. Matthews, E. Shim, "Concepts and
Terminology for Peer to Peer SIP," draft-willis-p2psip-concepts-01.txt
(work-in-progress), August 18, 2006
_______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
From dean.willis at softarmor.com Wed Sep 20 16:58:22 2006
From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 20 Sep 2006 15:58:22 -0500
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <0e4d01c6dcf4$31b90da0$0300a8c0@china.huawei.com>
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
<0e4d01c6dcf4$31b90da0$0300a8c0@china.huawei.com>
Message-ID: <7E2D51C5-E51A-42E5-8740-8CFF000962CB@softarmor.com>
On Sep 20, 2006, at 3:34 PM, Spencer Dawkins wrote:
> Hi, Dean/Eunsoo/David/Bryan/Cullen,
>
> This actually does look fairly good (Dean's words). I have a couple of
> questions.
>
> - I have unanswered comments on the current concepts/terminology
> draft that
> are applicable to the charter (since it uses terminology from that
> draft).
> Does this mean that I have comments on the charter?
Only if the comments change the words in the concepts and terms draft
that are used in the charter.
>
> - I won't challenge the dates because they may very well be
> realistic, but
> they sure are a long way into the future.
>
My therapist says I'm becoming more of a realist. But my minister
thinks I'm a hopeless optimist.
Of course, nobody complains if we get done sooner.
> - The current use cases draft has use cases that would benefit from
> multicast discovery. Does excluding multicast discovery sidestep
> prioritization of use cases?
I don't know. Do we have a use-case deliverable in greater detail
than that required for the concepts or architectures deliverables?
> - Forwarding research topics "to the IRTF" - does this mean "to the
> IRTF
> P2PRG research group"?
Maybe. Depends on the topic ;-).
--
Dean
From dean.willis at softarmor.com Wed Sep 20 17:20:09 2006
From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 20 Sep 2006 16:20:09 -0500
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
In-Reply-To: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com>
References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com>
Message-ID: <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com>
On Sep 7, 2006, at 2:58 PM, Spencer Dawkins wrote:
> I'm trying to get through this document at several levels - I hope
> these
> comments are coherent (and helpful).
>
> Summary - the document is really a good start, even though I have
> lots of
> notes and suggestions. Thanks for the hard work.
>
> Thanks,
>
> Spencer Dawkins
>
> High-level comments ...
>
> - in general, I'd like to tighten up the terminology that we use.
> There are
> terms with four additional "short forms" listed. This seems
> unnecessarily
> confusing. It is OK to have a short form, but can we deprecate at
> least some
> of the choices?
The intent was to list the "also known as" terms here. Perhaps we
need to distinguish between aka terms and "the official, in the
context of P2PSIP, short form"?
>
> - as a follow-on, it's not clear to me how much of the terminology
> is P2PSIP
> and how much is P2P in general. For example, is there anything
> special about
> a "P2PSIP Overlay Key", compared to an "overlay key"?
Yes. A P2PSIP Overlay Key is unique to P2PSIP. Other overlay
mechanisms might also use keys, but they might be of a different
format, size, or intent. Or maybe I don't understand the question.
>
> - Figure 1 seems confused on whether the UA/Peers behind the NATs
> are part
> of the overlay or not - I think I can draw the lines more clearly
> (shown
> below), assuming that they ARE part of the overlay.
>
No doubt. They're meant to be part of the overlay.
> - Figure 1 is also trying to do more than you can do in ASCII art
> (at least
> I think so) - the dotted lines either mean (a) logical connectivity
> in the
> overlay, (b) physical connectivity through the NATs, or (c) a SIP
> call. I
> doubled the lines for the overlay topology, but left the SIP calls
> in and
> don't like the result. If people agree, I can do ASCII art for (a)
> and (c),
> as two figures.
That might work.
>
> - I'm very confused about how both clients and peers can be
> "endpoints". For
> one thing, I'm not sure how "endpoint-to-endpoint trust" works. I
> suspect
> that this is conflating P2P endpoints (peers) with SIP endpoints
> (either a
> UA-peer or a UA-client). If you guys understand this perfectly,
> please keep
> typing...
>
Peers are supersets of clients. Everything a client can do, a peer
can do.
> - I'm somewhat confused about how we can talk about P2PSIP peers
> and clients
> without talking about something like a P2PSIP Overlay Server (see
> comments
> below).
>
> Detailed comments ...
>
> 2. Definitions
>
> P2PSIP Overlay User Agent: A SIP user agent that is coupled to a
> P2PSIP Overlay Peer or P2PSIP Overlay Client, such that the peer
> or client can assist the UA with registration (storage of a
> route
> to users of the UA) and/or routing of requests using the P2PSIP
> Overlay. A P2PSIP Overlay SUer Agent differs from a
> conventional
>
> s/SU/Us/
yeah, that's a typo.
>
> SIP user agent in that it is coupled directly to a P2PSIP
> Overlay
> Peer or P2PSIP Overlay Client, and can therefore directly
> interact
> with a P2PSIP Overlay, which a conventional SIP UA cannot do.
> P2PSIP Overlay User Agents are presumed to have no distinguished
> name or identifier. Short forms: overlay UA, P2PSIP UA.
>
> P2PSIP Overlay Bootstrap Server: A network node used by P2PSIP
> Overlay Peers or Clients who are attempting to enter to
> locate an
> entry into the P2P Overlay Network. It may return an entry
> point
> (address of a Peer) to the P2PSIP Overlay or act as one itself.
> This should be a quasi-stable and well known host, located
> using a
> configuration or discovered via , DNS, broadcast, or other
> mechanism. Example: a P2PSIP Overlay Peer that reboots and
> has no
> knowledge of other peers uses a P2PSIP Overlay Bootstrap
> Server to
> find other peers in the P2P Overlay Network and establish P2PSIP
> Overlay Peer Insertion. (Note: An overlay peer might or
> might not
> provide this functionality). Short forms: bootstrap server,
> boot
> server.
>
> These short forms seem very likely to conflict with lower-layer
> usage of the
> same terms, where "bootstrap server" and "boot server" have a
> well-understood usage. "Overlay bootstrap server" as short form?
>
> 3. Discussion
>
> 3.1. What Kinds of P2PSIP Overlay Peers and Clients Might Exist?
>
> 3. Gateway: a peer or client that converts from P2PSIP to some
> other
> protocol, such as PSTN.
>
> "PSTN" should be expanded on first use. It is expanded, but not on
> first
> use.
>
> 4. Redirector or Location Server: a peer or client that, given
> a SIP
>
> Is this a "SIP INVITE", or something else? looks like a cut and
> paste error.
>
Probably.
> (or other SIP request) to a P2PSIP overlay resource identifier,
> returns the route to a resource in a 302 or 305 response.
>
> 3.2. Reference Model
>
> Note - this is my redrawn picture, with changes on the left...
>
> --->PSTN
> -----------/
> -------- |N| | Gateway |
> | |========|A|========| Peer |==============
> | UA | |T| | | ||Client
> Protocol
> | Peer | ----------- || GET/PUT
> | C | || |
> -------- || | \__/
> || || v / \
> |NAT| ||---- / UA \
> || P2PSIP Overlay || /Client\
> || || |______|
> || Route Data || ^
> -------- -------- || |
> | | |N| | | || |
> | UA |=|A|==| UA | || |
> | Peer | |T| | Peer | || |
> | D | | E | || |
> -------- -------- || |SIP
> Peer Protocol || --------- --------- || |
> || | | | | || |
> ====| Proxy |========| Redir |==== |
> | Peer | | Peer | |
> | | | | |
> --------- ---------- |
> / \ /
> / \ /
> \__/ / SIP SIP \ \__/ /
> /\ / \ /\ /
> / \/ \/ \/
> / UA \ / UA \
> /______\ /______\
> SIP UA A SIP UA B
>
> Figure: Reference Model
>
> Here, the large rectangle represents the P2PSIP Overlay and its
> associated routing data. Around the periphery of the P2PSIP
> Overlay
> rectangle, we have several P2PSIP Overlay Peer nodes -- a PSTN
> gateway, a user-agent, a proxy, and a redirector. To the left we
> have two UA peers are behind network address translator. On the
> right side, we have a P2PSIP Overlay "UA client", which uses the
> P2PSIP Overlay Client Protocol to interact with the P2PSIP Overlay.
> Below, we have conventional SIP UA "A", which has used SIP to
> interact with the Proxy Peer and establish a dialog with the UA
> peer,
>
> There were three unnamed "UA peers" on the diagram. I'm not sure
> which one
> you were talking about, and I couldn't figure that out from the
> diagram (see
> previous whining about combining logical network topology and call
> paths on
> one diagram) but I at least named them in the diagram, so you can
> call one
> out in the text.
>
mostly.
> and SIP UA "B" which has been redirected by the Redirect Peer
> and set
> up a dialog with the UA Client. Note that the Proxy Peer and
> the UA
> Peer interact using the P2PSIP Overlay Peer Protocol, which is also
> presumably used on the keepalive links between the UA Peers and
> their
>
> "keepalive links" hasn't been defined, and I'm not happy with the
> term. Are
> these any more than "logical links", in this context?
I think the term might have come from "outbound", but the idea is
that there's a STUN keepalive usage there.
> neighbors.
>
> 3.3. Conceptual Outline of Operations
>
> 3.3.1. Enrolling and Inserting an P2PSIP Overlay Peer
>
> Peers are the full-function "routing and storage" nodes of a P2PSIP
> Overlay. When a new peer is first created, it must enroll in the
> P2PSIP Overlay. We currently have no defined mechanism for this
> (do
> we need one?), but we know that once the process is complete,
> the new
>
> I think this is required for the ad hoc scenarios, isn't it?
Can't have an overlay without peers.
But we don't have to do a full systems specification here. Somebody
doing a full ad-hoc systems spec would have to solve enrollment.
But the idea was to leave the "do we need one" question to the WG,
post-chartering.
>
> peer will have at least a P2PSIP Overlay Peer Key and a set of
> credentials.
>
> After enrollment, each time the peer connects to the overlay, it
> must
> insert itself. We don't have a defined protocol and process for
> this, and assume we need one. Presumably the inserting peer
> connects
>
> I agree that we need one.
Yep. This is a fundamental part of the "P2PSIP Overlay Peer Protocol".
>
> to one or more existing peers (possibly with the aid of a bootstrap
> server) presents its credentials, and ends up connected to the
> overlay, with some knowledge of neighbors (successor, precursor,
> finger tables, or whatever the distribution mechanism defines)
> and is
> able to store data on behalf of and route requests to other
> nodes in
> the P2PSIP overlay.
>
> 3.3.2. More on The Difference Between a Peer, Client, and User Agent
>
> P2PSIP Overlay Peers directly interact with and contain the routing
> and storage fabric of the overlay. P2PSIP Overlay Clients just use
> the routing and storage facilities provided by the peers. The
> peers
> speak the P2PSIP Overlay Peer Protocol, which presumably has a full
> range of expressivity for the routing and storage facilities of the
>
> "expressivity" is a great word. Is it defined anywhere? ;-)
http://www.merriam-webster.com/dictionary/expressivity+
I've been doing a lot of genetics work lately relative to
experimental oncology, and I'm afraid it's flavoring my vocabulary.
>
> overlay. Clients speak the P2PSIP Overlay Client protocol,
> which is
> presumably a subset of the peer protocol, and is limited to storage
> insertion (put), storage retrieval (get), and message routing
> (send).
>
> Some peers and some clients may be coupled to SIP user agents,
> making
> them P2PSIP Overlay User Agents capable of both sending and
> receiving
> conventional SIP messages (as per a SIP UA) using conventional SIP
> resolution procedures and of using the resolution facilities
> provided
> by the overlay
> (missing period after this sentence)
>
yep.
> 3.3.3. Enrolling a User and Inserting a P2PSIP Overlay User Agent
>
> To get started, users must be enrolled in the overlay. We do not
> have a process or protocol for this, nor are we certain we need a
> standardized mechanism. We presume that after enrollment, the user
> has a distinguished name within the overlay (example:
> sip:bob at example.com) and a set of credentials useful for
> authenticating its usage of the distinguished name. One possible
> mechanism for these credentials would be an x.509 certificate. It
> might also be possible to use a PGP key, a password, or some other
> mechanism. Presumably following enrollment, the user is also
> equipped with the information needed to connect to the overlay,
> such
> as the address of a bootstrap server. Whether this startup
> information is delivered as a part of enrollment of through some
> separate configuration process remains an open question.
>
> I would like to define this, but am concerned that the choice may
> differ
> per-overlay. Do others agree?
>
> 3.3.4. Placing a Call from a P2PSIP Overlay Client UA to a P2PSIP
> Overlay Client UA
>
> Assume we have two users, Alice and Bob, who have successfully
> enrolled and inserted themselves into a P2PSIP Overlay using
> clients.
> Alice wants to call Bob, and enters Bob's user identity (AOR) into
> her client. Alice's client does not have current knowledge of a
> route-set to Bob's client(s), so it needs to discover one. Alice's
>
> I was confused here. This text doesn't point anywhere for "it needs to
> discover one", so the reader is left to assume that "Alice's Client
> then
> does a GET operation on Bob's identity" is how that discovery
> happens, but
> "then does a GET" sounds like it happens AFTER discovering a route-
> set. If
> this is how discovery happens, please remove "then", and maybe even
> go to
> "it needs to discover one by doing a GET operation on Bob's identity".
>
ok, maybe some rewriting needed.
> Client then does a GET operation on Bob's identity, using a
> previously-discovered peer, or using whatever procedures are needed
> (such as RFC 3263, a bootstrap server, etc.) to find a peer.
> Alice's
> client send the GET request to the selected peer.
>
> 3.3.5. Bootstrapping
>
> If a client or peer is just starting up and has no knowledge of how
> to reach the other nodes of the overlay, it may exercise a
> bootstrap
> server to find one. Presumably it discovers the bootstrap
> server by
> some mechanism such as a DNS lookup, multicast, broadcast or
> configuration, then queries the bootstrap server and receives an
> address for a peer or set of peers that can be used to reach the
> overlay. Ideally, these target peers will be selected from a
> relatively large pool of peers that are currently online and
> reachable.
>
> This last sentence seems awfully use case-specific, doesn't it?
>
> After discovering the address of a peer, the behavior of the
> starting
> node will vary depending on whether it is intending to be a peer
> or a
>
> Ouch - if I have a peer, I would think that I'm a peer, too. Is the
> client
> actually discovering something like a "P2PSIP Overlay Server"?
nope. It's discovering a P2PSIP Overlay Peer.
>
> client. If it is intending to be a peer, it goes into the P2PSIP
> Overlay Peer Insertion process, at the conclusion of which it is
> actively participating in the target overlay as a peer and is
> capable
> of routing requests and storing records on behalf of the P2PSIP
> overlay. If it is intending to be a client, it does not bother
> with
> insertion, but merely contacts the discovered peer in order to use
> the overlay.
>
> 4. Questions
>
> 4.4. Universal Routing:
>
> Do all P2PSIP Overlay Peers route requests? How about clients?
>
> I thought this was one of the differences between peers and
> clients. If it's
> not, what's the difference?
Nope. Some peers might possibly return a redirection instead of
routing the request.
>
> 4.9. Cryptotransparency
>
> When forwarding requests, are the bodies of the requests visible to
> peers? If so, this creates substantial security problems that the
> deployers of conventional SIP have been willing to mostly ignore.
> Can we make peers cryptotransparent (like HTTP proxies) when
> security
> is requested?
>
> I believe this question is key when we discuss what an endpoint is
> (see
> previous comments on whether clients are endpoints).
>
> 4.13. Bootstrapping
>
> We know that sometimes peers or clients will start up without
> knowledge of how to find a peer for insertion. Do we need to
> define
> a bootstrap mechanism or mechanisms? Do we need to define
> supporting
> protocols?
>
> I believe the answer to both of these is "yes" to support anything
> like ad
> hoc use cases.
not unreasonable.
>
> 4.15. Overlapping Domains
>
> If the P2PSIP Overlay User Identifier is not scoped to a single DNS
> domain, this would appear to allow nodes from two or more apparent
> domains to share a single P2PSIP Overlay. What, if anything, do we
> need to say about this mode of operation?
>
> If a peer can locate an appropriate overlay AND provide appropriate
> credentials, what would prevent us from supporting this?
>
One would have to define search-ordering in the transdomain case.
> 4.16. Hybrid Domains
>
> It appears possible to have some hosts within a domain using
> conventional SIP and some using P2PSIP. This potentially raises a
> number of questions: 1) What should happen if we want to run a
> P2PSIP
> overlay in an existing SIP domain? 2) Do the existing redir/proxy
> servers need to be coupled with a peer layer? 3) When would an
> overlay peer want to discover them as opposed to looking in the
> overlay? 4) Is better not to run conventional SIP with overlay SIP?
> 5) When conventional and P2PSIP are run together, shall the
> existing
> redir servers keep their local databases or switch to the overlay
> storage.
>
> We've had some discussion on-list here about whether I have the
> same AOR in
> conventional SIP and P2PSIP overlays or not. Did we converge?
nope.
>
> 4.17. Admissions Control
>
> What do we need to say about admissions control with respect to the
> enrollment of peers and users? Do we need to discuss per-call
> admissions control in a P2P environment?
>
> I can imagine admissions control for enrollment, but I'm having a
> hard time
> imagining per-call admissions control in a decentralized P2P
> overlay - or
> was this the point of the question?
Both, really. Clearly we need some sort of enrollment and insertion
control. Do we need a per-call admissions control? What might one
look like if it were to exist? My personal belief is that this is an
interesting question, but out of scope for now.
--
Dean
From huang-ming.pan at comcast.net Thu Sep 21 01:43:27 2006
From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 20 Sep 2006 22:43:27 -0700
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
References: <24CCCC428EFEA2469BF046DB3C7A8D221558FA@namail5.corp.adobe.com>
Message-ID: <001101c6dd40$dd156490$030aa8c0@comcast.net>
> How many users will Skype have by then? :-)
[pp]: the cruel is, with competition from p2p-sip or not, skype in years
will gain a even larger number of users that very few folks here will like
to see, so the worry is needless for your health.
the good is, p2p-sip and skype can coexist, just like my son always opens
msn/aol and my colleagues open msn/gtalk/skype on their screens. such a
disloyalty is for your sleep.
> Or even worse, how many incompatible P2P SIP implementations will there
> be?
>
> Henry
>
[pp]: "even worse"? if the history created by linux (against unix) or by
skype (against cs-sip) can carry you back to an eternity -- "the best takes
it.", there CAN'T be any INcompatible p2p-sip implementation eventually.
the best will take it, regardless of its (in)compatibility with the P2P SIP
*here* or elsewhere.
maybe yours this time for Adobe can be the one :-)
peter!
From enrico.marocco at telecomitalia.it Thu Sep 21 08:36:11 2006
From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Thu, 21 Sep 2006 14:36:11 +0200
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
Message-ID: <4512873B.4080303@telecomitalia.it>
Hi Dean,
thank you for a very good job! I have just a few comments.
> 4. An architecture document. This document will address how the
> protocols
> defined above, along with existing IETF protocols, can be used to
> produce
> systems to locate a user, identify appropriate resources to facilitate
> communications (for example media relays), and establish communications
> between the users, without relying on centralized servers.
Some architectural assumptions -- mainly the client/peer distinction --
are at the very base of the work. I understand (do I?) that here
"architecture" means something different or at least more complex, but
maybe it could be misinterpreted. I think that if we don't change the
wording, we'll have to deal many and many times with the objection "Hey,
you are going to work on a protocol before deciding how to use it in
real life".
Just off the top of my head, instead of current #4, if I've actually
understood what it means, I'd prefer something like:
4'. A document defining some additional resources which can be
registered in overlays and used to facilitate communications (e.g. media
relays).
5'. A document addressing how communications can happen between users
registered in different overlays and/or canonical SIP networks.
> The following topics are excluded from the Working Group's scope:
> [..]
> 4. Multicast and dynamic DNS based approaches for locating
> users and resources.
This does not preclude some solutions for problems that are actually in
scope (e.g. bootstrap, interworking) from using multicast and dynamic
DNS, does it?
> References
>
> [1] D. Bryan, E. Shim, B. B. Lowekamp, "Use Cases for Peer-to-Peer
> Session Initiation Protocol (P2PSIP)",
> draft-bryan-sipping-p2p-usecases-00.txt, November 29, 2005
>
> [2] D. Willis, D. Bryan, P. Matthews, E. Shim, "Concepts and
> Terminology for Peer to Peer SIP," draft-willis-p2psip-concepts-01.txt
> (work-in-progress), August 18, 2006
Just an editorial note: all the charters I've read have references to
drafts directly inline. I don't know if it is better to have a
traditional "Reference" section, but, since the charter is likely to be
long-living and drafts will be certainly updated, maybe it is at least
worth stripping the version number from the name.
--
Ciao,
Enrico
--------------------------------------------------------------------
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster at telecomitalia.it.
Thank you
www.telecomitalia.it
--------------------------------------------------------------------
From bryan at ethernot.org Thu Sep 21 09:08:05 2006
From: bryan at ethernot.org (David A. Bryan)
Date: Thu, 21 Sep 2006 09:08:05 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <4512873B.4080303@telecomitalia.it>
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
<4512873B.4080303@telecomitalia.it>
Message-ID: <8b2769930609210608i1bba06e7rf609589e4875298a@mail.gmail.com>
On 9/21/06, Enrico Marocco wrote:
> Hi Dean,
>
> thank you for a very good job! I have just a few comments.
Thanks. Nice to know folks appreciate our work!
More comments inline...
> > 4. An architecture document. This document will address how the
> > protocols
> > defined above, along with existing IETF protocols, can be used to
> > produce
> > systems to locate a user, identify appropriate resources to facilitate
> > communications (for example media relays), and establish communications
> > between the users, without relying on centralized servers.
>
> Some architectural assumptions -- mainly the client/peer distinction --
> are at the very base of the work. I understand (do I?) that here
> "architecture" means something different or at least more complex, but
> maybe it could be misinterpreted. I think that if we don't change the
> wording, we'll have to deal many and many times with the objection "Hey,
> you are going to work on a protocol before deciding how to use it in
> real life".
>
> Just off the top of my head, instead of current #4, if I've actually
> understood what it means, I'd prefer something like:
> 4'. A document defining some additional resources which can be
> registered in overlays and used to facilitate communications (e.g. media
> relays).
> 5'. A document addressing how communications can happen between users
> registered in different overlays and/or canonical SIP networks.
Hmmm...what I was going for there was a "now that we defined the
tools, here is how you would put them together to do things" sort of a
concept. I think we all agreed that architecture might not have been
the best word, but not sure what else to call it.
The idea is to document how to do things (like what you mention above)
and actually build a workable system with the tools the earlier
charter items deliver. Other name suggestions?
>
> > The following topics are excluded from the Working Group's scope:
> > [..]
> > 4. Multicast and dynamic DNS based approaches for locating
> > users and resources.
>
> This does not preclude some solutions for problems that are actually in
> scope (e.g. bootstrap, interworking) from using multicast and dynamic
> DNS, does it?
Nope. I don't think anyone is trying to preclude those from being
mechanisms for bootstrap or interworking, but rather as the underlying
resource location mechanism. I thought I captured that by saying
"locating users and resources", but I maybe not. Others think this is
too vauge?
David
> > References
> >
> > [1] D. Bryan, E. Shim, B. B. Lowekamp, "Use Cases for Peer-to-Peer
> > Session Initiation Protocol (P2PSIP)",
> > draft-bryan-sipping-p2p-usecases-00.txt, November 29, 2005
> >
> > [2] D. Willis, D. Bryan, P. Matthews, E. Shim, "Concepts and
> > Terminology for Peer to Peer SIP," draft-willis-p2psip-concepts-01.txt
> > (work-in-progress), August 18, 2006
>
> Just an editorial note: all the charters I've read have references to
> drafts directly inline. I don't know if it is better to have a
> traditional "Reference" section, but, since the charter is likely to be
> long-living and drafts will be certainly updated, maybe it is at least
> worth stripping the version number from the name.
> --
> Ciao,
> Enrico
> --------------------------------------------------------------------
>
> CONFIDENTIALITY NOTICE
>
> This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster at telecomitalia.it.
>
> Thank you
>
> www.telecomitalia.it
>
> --------------------------------------------------------------------
>
>
From slavitch at gmail.com Thu Sep 21 10:24:57 2006
From: slavitch at gmail.com (Michael Slavitch)
Date: Thu, 21 Sep 2006 10:24:57 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <8b2769930609210608i1bba06e7rf609589e4875298a@mail.gmail.com>
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
<4512873B.4080303@telecomitalia.it>
<8b2769930609210608i1bba06e7rf609589e4875298a@mail.gmail.com>
Message-ID: <1fc32c8f0609210724h7933df6etaebf816c2c4797f6@mail.gmail.com>
I have but one comment:
"The working group takes it as an unfortunate fact that NATs and
firewalls exist in the Internet, and will ensure that the protocols
produced work in their presence as much as possible. "
The word 'unfortunate' is editorializing, . NATs have a purpose and people
use them. The IETF doesn't decide what is good.
Such pejorative comments have no place in a charter.
Apart from that I am happy and we should get on with it.
I agree with Henry that three years is a long time but that is a deadline
for the charter, not for the group itself. Let's deliver ahead of
schedule.
Regards
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060921/dadb14e4/attachment.html
From eunsoo at research.panasonic.com Thu Sep 21 11:48:56 2006
From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 21 Sep 2006 11:48:56 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <1fc32c8f0609210724h7933df6etaebf816c2c4797f6@mail.gmail.com>
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com> <4512873B.4080303@telecomitalia.it> <8b2769930609210608i1bba06e7rf609589e4875298a@mail.gmail.com>
<1fc32c8f0609210724h7933df6etaebf816c2c4797f6@mail.gmail.com>
Message-ID: <4512B468.6020307@research.panasonic.com>
Michael Slavitch wrote:
> I have but one comment:
>
> "The working group takes it as an unfortunate fact that NATs and
> firewalls exist in the Internet, and will ensure that the protocols
> produced work in their presence as much as possible. "
>
> The word 'unfortunate' is editorializing, . NATs have a purpose and people
> use them. The IETF doesn't decide what is good.
> Such pejorative comments have no place in a charter.
>
I think we can remove the word 'unfortunate' from the charter without
hurting the charter.
> Apart from that I am happy and we should get on with it.
>
> I agree with Henry that three years is a long time but that is a deadline
> for the charter, not for the group itself. Let's deliver ahead of
> schedule.
It's a good spirit! :-)
Thanks.
Eunsoo
From eunsoo at research.panasonic.com Thu Sep 21 12:02:13 2006
From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 21 Sep 2006 12:02:13 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <8b2769930609210608i1bba06e7rf609589e4875298a@mail.gmail.com>
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com> <4512873B.4080303@telecomitalia.it>
<8b2769930609210608i1bba06e7rf609589e4875298a@mail.gmail.com>
Message-ID: <4512B785.2000808@research.panasonic.com>
My comments are inline.
David A. Bryan wrote:
> On 9/21/06, Enrico Marocco wrote:
>> Hi Dean,
>>
>> thank you for a very good job! I have just a few comments.
>
> Thanks. Nice to know folks appreciate our work!
>
> More comments inline...
>
>>> 4. An architecture document. This document will address how the
>>> protocols
>>> defined above, along with existing IETF protocols, can be used to
>>> produce
>>> systems to locate a user, identify appropriate resources to facilitate
>>> communications (for example media relays), and establish communications
>>> between the users, without relying on centralized servers.
>> Some architectural assumptions -- mainly the client/peer distinction --
>> are at the very base of the work. I understand (do I?) that here
>> "architecture" means something different or at least more complex, but
>> maybe it could be misinterpreted. I think that if we don't change the
>> wording, we'll have to deal many and many times with the objection "Hey,
>> you are going to work on a protocol before deciding how to use it in
>> real life".
>>
>> Just off the top of my head, instead of current #4, if I've actually
>> understood what it means, I'd prefer something like:
>> 4'. A document defining some additional resources which can be
>> registered in overlays and used to facilitate communications (e.g. media
>> relays).
I think this is covered by the current text. The current text targets at
more than this as explained below by David.
>> 5'. A document addressing how communications can happen between users
>> registered in different overlays and/or canonical SIP networks.
>
I think it is covered by the current text. Otherwise it is case I don't
understand the meaning of the proposed text above.
> Hmmm...what I was going for there was a "now that we defined the
> tools, here is how you would put them together to do things" sort of a
> concept. I think we all agreed that architecture might not have been
> the best word, but not sure what else to call it.
>
> The idea is to document how to do things (like what you mention above)
> and actually build a workable system with the tools the earlier
> charter items deliver. Other name suggestions?
>
>>> The following topics are excluded from the Working Group's scope:
>>> [..]
>>> 4. Multicast and dynamic DNS based approaches for locating
>>> users and resources.
>> This does not preclude some solutions for problems that are actually in
>> scope (e.g. bootstrap, interworking) from using multicast and dynamic
>> DNS, does it?
>
> Nope. I don't think anyone is trying to preclude those from being
> mechanisms for bootstrap or interworking, but rather as the underlying
> resource location mechanism. I thought I captured that by saying
> "locating users and resources", but I maybe not. Others think this is
> too vauge?
>
>
>>> References
>>>
>>> [1] D. Bryan, E. Shim, B. B. Lowekamp, "Use Cases for Peer-to-Peer
>>> Session Initiation Protocol (P2PSIP)",
>>> draft-bryan-sipping-p2p-usecases-00.txt, November 29, 2005
>>>
>>> [2] D. Willis, D. Bryan, P. Matthews, E. Shim, "Concepts and
>>> Terminology for Peer to Peer SIP," draft-willis-p2psip-concepts-01.txt
>>> (work-in-progress), August 18, 2006
>> Just an editorial note: all the charters I've read have references to
>> drafts directly inline. I don't know if it is better to have a
>> traditional "Reference" section, but, since the charter is likely to be
>> long-living and drafts will be certainly updated, maybe it is at least
>> worth stripping the version number from the name.
Hmm, it is a problem of referring to drafts in the charter.
Your suggestion sounds OK. Well, the draft names may change in the
future, too. :-(
Thanks.
Eunsoo
From swb at employees.org Thu Sep 21 12:20:32 2006
From: swb at employees.org (Scott W Brim)
Date: Thu, 21 Sep 2006 12:20:32 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
Message-ID: <4512BBD0.1070804@employees.org>
First, I'm hesitant about referring to drafts in the charter.
RFCs yes, but drafts are evanescent. Second, even assuming it's okay
to do so, it makes the charter circular.
> The terminology and concepts draft [2] explains the terms and
> concepts used here.
and
> This group's primary tasks are to produce:
>
> 1. An overview document explaining concepts, terminology,
> rationale, and illustrative use cases for the remaining work.
So the charter is based on the terminology and concepts draft as
fundamental in defining the scope of the work to be done, but the
first task is to finish defining them (and even possibly package them
differently). Also the terminology and concepts do make assumptions
about architecture, and an architecture document is yet another
output. Circular?
> The group will identify and require one base P2P algorithm (likely a
> particular Distributed Hash Table (DHT) algorithm), while allowing
> for additional optional algorithms in the future.
Is there a need for the () in the charter?
> The following topics are excluded from the Working Group's scope:
>
> 1. Issues specific to applications other than locating users and
> resources for SIP-based communications and presence.
OK as long as "locate" is broadly defined. Allow for "location" to be
determined "late" depending on the details of the desired
communication, etc.
> May 2009 Submit P2PSIP architecture document to the IESG
> (Standards track)
If an "architecture" is to be useful then it should be done before, or
at least at the same time as, the protocols. We will certainly know
what the architecture is as we do the protocols. So either it can be
bumped to Sep 2008 if not earlier, or you don't really mean an
architecture document -- perhaps the architecture will be in the
overview, and this will be an applicability document?
swb
From enrico.marocco at telecomitalia.it Thu Sep 21 12:22:56 2006
From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Thu, 21 Sep 2006 18:22:56 +0200
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <4512B785.2000808@research.panasonic.com>
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com> <4512873B.4080303@telecomitalia.it>
<8b2769930609210608i1bba06e7rf609589e4875298a@mail.gmail.com>
<4512B785.2000808@research.panasonic.com>
Message-ID: <4512BC60.5030106@telecomitalia.it>
Eunsoo Shim wrote:
>>> Just off the top of my head, instead of current #4, if I've actually
>>> understood what it means, I'd prefer something like:
>>> 4'. A document defining some additional resources which can be
>>> registered in overlays and used to facilitate communications (e.g. media
>>> relays).
> I think this is covered by the current text. The current text targets at
> more than this as explained below by David.
>
>>> 5'. A document addressing how communications can happen between users
>>> registered in different overlays and/or canonical SIP networks.
>
> I think it is covered by the current text. Otherwise it is case I don't
> understand the meaning of the proposed text above.
It just mean to be a rewording of the current text without the term
"architecture", so... I'm glad to see that you think it doesn't state
anything different :-)
>>>> [2] D. Willis, D. Bryan, P. Matthews, E. Shim, "Concepts and
>>>> Terminology for Peer to Peer SIP," draft-willis-p2psip-concepts-01.txt
>>>> (work-in-progress), August 18, 2006
>>> Just an editorial note: all the charters I've read have references to
>>> drafts directly inline. I don't know if it is better to have a
>>> traditional "Reference" section, but, since the charter is likely to be
>>> long-living and drafts will be certainly updated, maybe it is at least
>>> worth stripping the version number from the name.
>
> Hmm, it is a problem of referring to drafts in the charter.
> Your suggestion sounds OK. Well, the draft names may change in the
> future, too. :-(
Ok, I understand the problem is bigger than what I noticed.
--
Ciao,
Enrico
Ahem.. Sorry, the notice below is not my fault :-(
--------------------------------------------------------------------
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster at telecomitalia.it.
Thank you
www.telecomitalia.it
--------------------------------------------------------------------
From RADHIKA.R.ROY at saic.com Thu Sep 21 12:35:10 2006
From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Thu, 21 Sep 2006 12:35:10 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
Message-ID: <62D92A9A02BCC845B202323D49A48426E1CE70@0591-ITS-EXMP02.us.saic.com>
Mike and all:
I am commenting on NATs.
>From IETF point of view, the use of NATs as it is done these days is
"unfortunate."
Let us see what had been the history of NAT standardization in the IETF?
The IETF charter had been to help the "scarcity" of IPv4 addresses (before
IPv6 even been proposed). It was hoped that, by the time IPv6 is
standardized, there is will be no more requirements of NATs to provide more
address spaces.
Now, people have forgot the original usage of NATs. People are using NATs as
a part of "security" for hiding the configurations behind NATs. It is
completely an "illusion" to be happy to know that people are "secured" by
using NATs. It is still going on in a mass scale throughout the world, and
no one knows when this will be stopped.
Should the purpose of the NAT standardization be "SECURITY" or "TOPOLOGY
HIDING in the name of security," IETF would NEVER standardized NATs for
these purposes. The rest is history!!!
So, it is UNFORTUNATE so far the MIS-use of NATs is concerned because NATs
are not needed anymore due to shortage of IPv4 addresses or NATs cannot
provide security through hiding configurations.
Therefore, the draft charter is CORRECT in this context to use the word
"UNFORTUNATE."
Best regards,
Radhika
_____
From: p2p-sip-bounces at cs.columbia.edu on behalf of Michael Slavitch
Sent: Thu 9/21/2006 10:24 AM
To: David A. Bryan
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Revised Draft Charter for P2PSIP
I have but one comment:
"The working group takes it as an unfortunate fact that NATs and
firewalls exist in the Internet, and will ensure that the protocols
produced work in their presence as much as possible. "
The word 'unfortunate' is editorializing, . NATs have a purpose and people
use them. The IETF doesn't decide what is good.
Such pejorative comments have no place in a charter.
Apart from that I am happy and we should get on with it.
I agree with Henry that three years is a long time but that is a deadline
for the charter, not for the group itself. Let's deliver ahead of schedule.
Regards
Michael
From RADHIKA.R.ROY at saic.com Thu Sep 21 12:53:17 2006
From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Thu, 21 Sep 2006 12:53:17 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
Message-ID: <62D92A9A02BCC845B202323D49A48426E1CE71@0591-ITS-EXMP02.us.saic.com>
Hi, Scott and all:
A couple of points are as follows:
1.
References of p2p-SIP drafts in the charter are perfectly OK. Drafts
are not RFCs, and can be modified by the WG as needed based on the charter.
For now, these drafts are providing some guidelines to make the objectives
of the charter clear. These are good pointers because we have done a good
amount of discussions based on these drafts to form the WG in the first
place. Otherwise, people will not get any reference to start with, and all
of our valuable discussions will almost be lost without getting any
reference pointers.
2.
The term "architecture" seems to be very problematic because there
is no "precise" standard in the IETF what is meant by "architecture." Some
may say that it is the "p2p protocol arch." Others may say it is the "p2p
network configurations arch." Others may say it is the "protocol,
interfaces, and network arch" combining the CS SIP and p2p-SIP network so
that p2p-SIP overlay arch will work as the top most network with all details
of anything and everything.
What I suggest is this:
Let the concept and other p2p-SIP draft deal with protocol and some sort of
high-level view of networking (as can be seen in CS SIP RFCs and other IETF
RFCs) diagrams that have been used so far will be appropriate without being
bogged down to defining "p2p-SIP Architecture" per se.
Best regards,
Radhika
_____
From: p2p-sip-bounces at cs.columbia.edu on behalf of Scott W Brim
Sent: Thu 9/21/2006 12:20 PM
To: Dean Willis
Cc: p2p-sip at cs.columbia.edu; David A. Bryan
Subject: Re: [p2p-sip] Revised Draft Charter for P2PSIP
First, I'm hesitant about referring to drafts in the charter.
RFCs yes, but drafts are evanescent. Second, even assuming it's okay
to do so, it makes the charter circular.
> The terminology and concepts draft [2] explains the terms and
> concepts used here.
and
> This group's primary tasks are to produce:
>
> 1. An overview document explaining concepts, terminology,
> rationale, and illustrative use cases for the remaining work.
So the charter is based on the terminology and concepts draft as
fundamental in defining the scope of the work to be done, but the
first task is to finish defining them (and even possibly package them
differently). Also the terminology and concepts do make assumptions
about architecture, and an architecture document is yet another
output. Circular?
> The group will identify and require one base P2P algorithm (likely a
> particular Distributed Hash Table (DHT) algorithm), while allowing
> for additional optional algorithms in the future.
Is there a need for the () in the charter?
> The following topics are excluded from the Working Group's scope:
>
> 1. Issues specific to applications other than locating users and
> resources for SIP-based communications and presence.
OK as long as "locate" is broadly defined. Allow for "location" to be
determined "late" depending on the details of the desired
communication, etc.
> May 2009 Submit P2PSIP architecture document to the IESG
> (Standards track)
If an "architecture" is to be useful then it should be done before, or
at least at the same time as, the protocols. We will certainly know
what the architecture is as we do the protocols. So either it can be
bumped to Sep 2008 if not earlier, or you don't really mean an
architecture document -- perhaps the architecture will be in the
overview, and this will be an applicability document?
swb
From fluffy at cisco.com Thu Sep 21 13:11:05 2006
From: fluffy at cisco.com (Cullen Jennings)
Date: Thu, 21 Sep 2006 10:11:05 -0700
Subject: [p2p-sip] P2PSIP BOF will be aproved
Message-ID: <1686E204-C45E-422D-B935-EFE0D9EB5822@cisco.com>
The IESG is going to approve the P2PSIP BoF. We need to get the
formal request in this weekend. I will keep working with Dean and
Brian to get this in. No specific feedback on the charter was
provided yet but hopefully some will show up.
Cullen
From eunsoo at research.panasonic.com Thu Sep 21 13:14:19 2006
From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 21 Sep 2006 13:14:19 -0400
Subject: [p2p-sip] P2PSIP BOF will be aproved
In-Reply-To: <1686E204-C45E-422D-B935-EFE0D9EB5822@cisco.com>
References: <1686E204-C45E-422D-B935-EFE0D9EB5822@cisco.com>
Message-ID: <4512C86B.3050405@research.panasonic.com>
Great news!
Thanks.
Eunsoo
Cullen Jennings wrote:
> The IESG is going to approve the P2PSIP BoF. We need to get the
> formal request in this weekend. I will keep working with Dean and
> Brian to get this in. No specific feedback on the charter was
> provided yet but hopefully some will show up.
>
> Cullen
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
From bryan at ethernot.org Thu Sep 21 13:23:02 2006
From: bryan at ethernot.org (David A. Bryan)
Date: Thu, 21 Sep 2006 13:23:02 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <4512BBD0.1070804@employees.org>
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
<4512BBD0.1070804@employees.org>
Message-ID: <8b2769930609211023hfbbf1efma9b48b83814ae65b@mail.gmail.com>
It definitely seems clear we need a new name for the latter
"architecture" document. The idea was that the "overview" deliverable
(the first one) was the background/basic framework document, and the
later architecture document (the last deliverable listed) was a "how
to use the tools produced by this group" sort of thing.
Applicability document is going down the right path name-wise. Any
other suggestions?
David
On 9/21/06, Scott W Brim wrote:
> First, I'm hesitant about referring to drafts in the charter.
> RFCs yes, but drafts are evanescent. Second, even assuming it's okay
> to do so, it makes the charter circular.
>
> > The terminology and concepts draft [2] explains the terms and
> > concepts used here.
>
> and
>
> > This group's primary tasks are to produce:
> >
> > 1. An overview document explaining concepts, terminology,
> > rationale, and illustrative use cases for the remaining work.
>
> So the charter is based on the terminology and concepts draft as
> fundamental in defining the scope of the work to be done, but the
> first task is to finish defining them (and even possibly package them
> differently). Also the terminology and concepts do make assumptions
> about architecture, and an architecture document is yet another
> output. Circular?
>
> > The group will identify and require one base P2P algorithm (likely a
> > particular Distributed Hash Table (DHT) algorithm), while allowing
> > for additional optional algorithms in the future.
>
> Is there a need for the () in the charter?
>
> > The following topics are excluded from the Working Group's scope:
> >
> > 1. Issues specific to applications other than locating users and
> > resources for SIP-based communications and presence.
>
> OK as long as "locate" is broadly defined. Allow for "location" to be
> determined "late" depending on the details of the desired
> communication, etc.
>
> > May 2009 Submit P2PSIP architecture document to the IESG
> > (Standards track)
>
> If an "architecture" is to be useful then it should be done before, or
> at least at the same time as, the protocols. We will certainly know
> what the architecture is as we do the protocols. So either it can be
> bumped to Sep 2008 if not earlier, or you don't really mean an
> architecture document -- perhaps the architecture will be in the
> overview, and this will be an applicability document?
>
> swb
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
From eunsoo at research.panasonic.com Thu Sep 21 13:27:55 2006
From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 21 Sep 2006 13:27:55 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <4512BBD0.1070804@employees.org>
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
<4512BBD0.1070804@employees.org>
Message-ID: <4512CB9B.5040909@research.panasonic.com>
I see the problem of 'being circular' in referring to the drafts.
Well, things are not happening strictly sequentially here for P2P SIP
standardization.
I believe it is because P2P SIP is one of major innovations rather than
a small extension of any existing IETF protocol. So even establishing
agreeable terminology is not a trivial task. Neither is establishing
agreeable architecture description. Then we have a problem in
identifying what protocols we are going to design.
One possible approach is chartering only for terminology, concepts, and
architecture, and so except the protocols.
Another possible approach is reaching a quite ROUGH agreement on the
terminology and concept, identifying the protocols to design and writing
the charter. In this approach, the terminology and so on need to be
reviewed and refined (or reworked) by the working group to be formed.
Well, we took the second approach and here we are. I think it was a good
and practical approach for the P2P SIP case.
The authors of the charter draft put references to the draft to avoid
confusion about the newly introduced terminology.
One solution is removing the reference section and somehow making sure
future readers of the charter know that there are such reference
documents. I don't know how to achieve the second part but I think it is
not a bad idea if it is important to avoid the 'circularity' problem.
Regarding the architecture document, first please take a look at David
Bryan's response to Enrico's comments about the architecture document.
Anyway usually major work and discussion are done much before than
submission to IESG. So later target does not mean we will have nothing
when we work on the protocol specifications. In any case I think we can
make the target date earlier as you suggested.
Thanks.
Eunsoo
Scott W Brim wrote:
> First, I'm hesitant about referring to drafts in the charter.
> RFCs yes, but drafts are evanescent. Second, even assuming it's okay
> to do so, it makes the charter circular.
>
> > The terminology and concepts draft [2] explains the terms and
> > concepts used here.
>
> and
>
> > This group's primary tasks are to produce:
> >
> > 1. An overview document explaining concepts, terminology,
> > rationale, and illustrative use cases for the remaining work.
>
> So the charter is based on the terminology and concepts draft as
> fundamental in defining the scope of the work to be done, but the
> first task is to finish defining them (and even possibly package them
> differently). Also the terminology and concepts do make assumptions
> about architecture, and an architecture document is yet another
> output. Circular?
>
>> The group will identify and require one base P2P algorithm (likely a
>> particular Distributed Hash Table (DHT) algorithm), while allowing
>> for additional optional algorithms in the future.
>
> Is there a need for the () in the charter?
>
>> The following topics are excluded from the Working Group's scope:
>>
>> 1. Issues specific to applications other than locating users and
>> resources for SIP-based communications and presence.
>
> OK as long as "locate" is broadly defined. Allow for "location" to be
> determined "late" depending on the details of the desired
> communication, etc.
>
>> May 2009 Submit P2PSIP architecture document to the IESG
>> (Standards track)
>
> If an "architecture" is to be useful then it should be done before, or
> at least at the same time as, the protocols. We will certainly know
> what the architecture is as we do the protocols. So either it can be
> bumped to Sep 2008 if not earlier, or you don't really mean an
> architecture document -- perhaps the architecture will be in the
> overview, and this will be an applicability document?
>
> swb
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
From swb at employees.org Thu Sep 21 13:30:32 2006
From: swb at employees.org (Scott W Brim)
Date: Thu, 21 Sep 2006 13:30:32 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <8b2769930609211023hfbbf1efma9b48b83814ae65b@mail.gmail.com>
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
<4512BBD0.1070804@employees.org>
<8b2769930609211023hfbbf1efma9b48b83814ae65b@mail.gmail.com>
Message-ID: <4512CC38.20307@employees.org>
On 09/21/2006 13:23 PM, David A. Bryan allegedly wrote:
> It definitely seems clear we need a new name for the latter
> "architecture" document. The idea was that the "overview" deliverable
> (the first one) was the background/basic framework document, and the
> later architecture document (the last deliverable listed) was a "how
> to use the tools produced by this group" sort of thing.
>
> Applicability document is going down the right path name-wise. Any
> other suggestions?
>
> David
See below for RFC 2026 on applicability statements. It can be called
a framework, an AS, anything -- even an architecture :-). In the
charter you can just refer to it generically as an AS.
swb
3. INTERNET STANDARD SPECIFICATIONS
Specifications subject to the Internet Standards Process fall into
one of two categories: Technical Specification (TS) and
Applicability Statement (AS).
...
3.2 Applicability Statement (AS)
An Applicability Statement specifies how, and under what
circumstances, one or more TSs may be applied to support a
particular Internet capability. An AS may specify uses for TSs
that are not Internet Standards, as discussed in Section 7.
An AS identifies the relevant TSs and the specific way in which
they are to be combined, and may also specify particular values or
ranges of TS parameters or subfunctions of a TS protocol that must
be implemented. An AS also specifies the circumstances in which
the use of a particular TS is required, recommended, or elective
(see section
3.3).
An AS may describe particular methods of using a TS in a restricted
"domain of applicability", such as Internet routers, terminal
servers, Internet systems that interface to Ethernets, or datagram-
based database servers.
The broadest type of AS is a comprehensive conformance
specification, commonly called a "requirements document", for a
particular class of Internet systems, such as Internet routers or
Internet hosts.
An AS may not have a higher maturity level in the standards track
than any standards-track TS on which the AS relies (see section
4.1). For example, a TS at Draft Standard level may be referenced
by an AS at the Proposed Standard or Draft Standard level, but not
by an AS at the Standard level.
From spencer at mcsr-labs.org Thu Sep 21 13:41:26 2006
From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 21 Sep 2006 12:41:26 -0500
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com>
<85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com>
Message-ID: <00ab01c6dda5$2a6bad80$0300a8c0@china.huawei.com>
Hi, Dean,
I think we're good on many of the things I listed earlier - just to follow
up on a couple of questions...
(inline)
Spencer
>>
>> High-level comments ...
>>
>> - in general, I'd like to tighten up the terminology that we use. There
>> are
>> terms with four additional "short forms" listed. This seems
>> unnecessarily
>> confusing. It is OK to have a short form, but can we deprecate at least
>> some
>> of the choices?
>
> The intent was to list the "also known as" terms here. Perhaps we need
> to distinguish between aka terms and "the official, in the context of
> P2PSIP, short form"?
That would be helpful for me.
>> - as a follow-on, it's not clear to me how much of the terminology is
>> P2PSIP
>> and how much is P2P in general. For example, is there anything special
>> about
>> a "P2PSIP Overlay Key", compared to an "overlay key"?
>
> Yes. A P2PSIP Overlay Key is unique to P2PSIP. Other overlay mechanisms
> might also use keys, but they might be of a different format, size, or
> intent. Or maybe I don't understand the question.
Well, I didn't ask the question very clearly. What I was trying to ask was,
would the overlay operate differently for a P2PSIP Overlay key than it would
for any other overlay key. I understand that the P2PSIP Overlay key has a
specific format/size/intent, I'm asking if the definition is true for
generic DHT operation.
>
>> - Figure 1 is also trying to do more than you can do in ASCII art (at
>> least
>> I think so) - the dotted lines either mean (a) logical connectivity in
>> the
>> overlay, (b) physical connectivity through the NATs, or (c) a SIP call.
>> I
>> doubled the lines for the overlay topology, but left the SIP calls in
>> and
>> don't like the result. If people agree, I can do ASCII art for (a) and
>> (c),
>> as two figures.
>
> That might work.
I'll send this along soon.
>> - I'm very confused about how both clients and peers can be "endpoints".
>> For
>> one thing, I'm not sure how "endpoint-to-endpoint trust" works. I
>> suspect
>> that this is conflating P2P endpoints (peers) with SIP endpoints (either
>> a
>> UA-peer or a UA-client). If you guys understand this perfectly, please
>> keep
>> typing...
>>
>
> Peers are supersets of clients. Everything a client can do, a peer can
> do.
It would be good to include this text in the next draft of the document. It
helped enormously.
>> - I'm somewhat confused about how we can talk about P2PSIP peers and
>> clients
>> without talking about something like a P2PSIP Overlay Server (see
>> comments
>> below).
>>
>> Detailed comments ...
>>
>> 2. Definitions
>>
>>
>> P2PSIP Overlay Bootstrap Server: A network node used by P2PSIP
>> Overlay Peers or Clients who are attempting to enter to locate an
>> entry into the P2P Overlay Network. It may return an entry point
>> (address of a Peer) to the P2PSIP Overlay or act as one itself.
>> This should be a quasi-stable and well known host, located using a
>> configuration or discovered via , DNS, broadcast, or other
>> mechanism. Example: a P2PSIP Overlay Peer that reboots and has no
>> knowledge of other peers uses a P2PSIP Overlay Bootstrap Server to
>> find other peers in the P2P Overlay Network and establish P2PSIP
>> Overlay Peer Insertion. (Note: An overlay peer might or might not
>> provide this functionality). Short forms: bootstrap server, boot
>> server.
>>
>> These short forms seem very likely to conflict with lower-layer usage of
>> the
>> same terms, where "bootstrap server" and "boot server" have a
>> well-understood usage. "Overlay bootstrap server" as short form?
>>
>> 3.2. Reference Model
>>
>> Note - this is my redrawn picture, with changes on the left...
>>
>> --->PSTN
>> -----------/
>> -------- |N| | Gateway |
>> | |========|A|========| Peer |==============
>> | UA | |T| | | ||Client Protocol
>> | Peer | ----------- || GET/PUT
>> | C | || |
>> -------- || | \__/
>> || || v / \
>> |NAT| ||---- / UA \
>> || P2PSIP Overlay || /Client\
>> || || |______|
>> || Route Data || ^
>> -------- -------- || |
>> | | |N| | | || |
>> | UA |=|A|==| UA | || |
>> | Peer | |T| | Peer | || |
>> | D | | E | || |
>> -------- -------- || |SIP
>> Peer Protocol || --------- --------- || |
>> || | | | | || |
>> ====| Proxy |========| Redir |==== |
>> | Peer | | Peer | |
>> | | | | |
>> --------- ---------- |
>> / \ /
>> / \ /
>> \__/ / SIP SIP \ \__/ /
>> /\ / \ /\ /
>> / \/ \/ \/
>> / UA \ / UA \
>> /______\ /______\
>> SIP UA A SIP UA B
>>
>> Figure: Reference Model
>>
>> Here, the large rectangle represents the P2PSIP Overlay and its
>> associated routing data. Around the periphery of the P2PSIP Overlay
>> rectangle, we have several P2PSIP Overlay Peer nodes -- a PSTN
>> gateway, a user-agent, a proxy, and a redirector. To the left we
>> have two UA peers are behind network address translator. On the
>> right side, we have a P2PSIP Overlay "UA client", which uses the
>> P2PSIP Overlay Client Protocol to interact with the P2PSIP Overlay.
>> Below, we have conventional SIP UA "A", which has used SIP to
>> interact with the Proxy Peer and establish a dialog with the UA peer,
>>
>> There were three unnamed "UA peers" on the diagram. I'm not sure which
>> one
>> you were talking about, and I couldn't figure that out from the diagram
>> (see
>> previous whining about combining logical network topology and call paths
>> on
>> one diagram) but I at least named them in the diagram, so you can call
>> one
>> out in the text.
>>
>
> mostly.
>
>> and SIP UA "B" which has been redirected by the Redirect Peer and set
>> up a dialog with the UA Client. Note that the Proxy Peer and the UA
>> Peer interact using the P2PSIP Overlay Peer Protocol, which is also
>> presumably used on the keepalive links between the UA Peers and their
>>
>> "keepalive links" hasn't been defined, and I'm not happy with the term.
>> Are
>> these any more than "logical links", in this context?
>
> I think the term might have come from "outbound", but the idea is that
> there's a STUN keepalive usage there.
OK. It would be good to spell this out a bit (since the term "keepalive
link" does not appear in "outbound"). Is this text intended to require STUN?
>> neighbors.
>>
>> 3.3.5. Bootstrapping
>>
>> If a client or peer is just starting up and has no knowledge of how
>> to reach the other nodes of the overlay, it may exercise a bootstrap
>> server to find one. Presumably it discovers the bootstrap server by
>> some mechanism such as a DNS lookup, multicast, broadcast or
>> configuration, then queries the bootstrap server and receives an
>> address for a peer or set of peers that can be used to reach the
>> overlay. Ideally, these target peers will be selected from a
>> relatively large pool of peers that are currently online and
>> reachable.
>>
>> This last sentence seems awfully use case-specific, doesn't it?
>>
>> After discovering the address of a peer, the behavior of the starting
>> node will vary depending on whether it is intending to be a peer or a
>>
>> Ouch - if I have a peer, I would think that I'm a peer, too. Is the
>> client
>> actually discovering something like a "P2PSIP Overlay Server"?
>
> nope. It's discovering a P2PSIP Overlay Peer.
I'm with you as far as the current text goes. What I'm trying to point out
is that there is nothing in the reference architecture that allows me to
distinguish between P2PSIP overlay peers that DO "serve" clients and peers
that do not. This seems to be a missing concept that I'd like to see
discussed.
I seem to have confused more people than just Dean when I used the term
P2PSIP Overlay Server, but this captured what I was trying to say - the
P2PSIP Overlay is the resource, made up entirely of peers, and the client
wants a participant in the P2PSIP Overlay to allow an endpoint that is not
an overlay peer to store and retrieve information in the overlay.
So, I'm thinking of a picture that looks like this
+---+ +---+---+ +---+
| p1|==========| p2| s5|------| c6|
+---+ +---+---+ +---+
# #
# overlay #
# #
+---+ +---+
| p3|==========| p4|
+---+ +---+
Where p1,p2,p3,and p4 make up a P2PSIP overlay, c6 is the client that wants
to use P2PSIP resources, and s5 is the server entity that allows the client
to put and get P2PSIP Overlay entries without being a peer. There is no "s5"
in the reference architecture today. Today's picture would look like this
+---+ +---+ +---+
| p1|==========| p2|-----------| c6|
+---+ +---+ +---+
# #
# overlay #
# #
+---+ +---+
| p3|==========| p4|
+---+ +---+
>> client. If it is intending to be a peer, it goes into the P2PSIP
>> Overlay Peer Insertion process, at the conclusion of which it is
>> actively participating in the target overlay as a peer and is capable
>> of routing requests and storing records on behalf of the P2PSIP
>> overlay. If it is intending to be a client, it does not bother with
>> insertion, but merely contacts the discovered peer in order to use
>> the overlay.
>>
>> 4. Questions
>>
>> 4.4. Universal Routing:
>>
>> Do all P2PSIP Overlay Peers route requests? How about clients?
>>
>> I thought this was one of the differences between peers and clients. If
>> it's
>> not, what's the difference?
>
> Nope. Some peers might possibly return a redirection instead of routing
> the request.
Again, this response was enormously helpful, and I'd like to see mention of
redirection in the revised draft, but I asked my question too badly for you
to actually grok it. What I was trying to say was, "I thought clients never
routed requests OR returned redirections". If we're talking about a client
receiving requests from the P2PSIP overlay that still need to be routed or
redirected, some peer(/overlay server, but ignoring this for now) sent a
request to the wrong place - or am I still face down in the snow?
From spencer at mcsr-labs.org Thu Sep 21 14:14:25 2006
From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 21 Sep 2006 13:14:25 -0500
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com><4512873B.4080303@telecomitalia.it>
<8b2769930609210608i1bba06e7rf609589e4875298a@mail.gmail.com>
Message-ID: <00db01c6dda9$c61256e0$0300a8c0@china.huawei.com>
Hi, David,
>> > The following topics are excluded from the Working Group's scope:
>> > [..]
>> > 4. Multicast and dynamic DNS based approaches for locating
>> > users and resources.
>>
>> This does not preclude some solutions for problems that are actually in
>> scope (e.g. bootstrap, interworking) from using multicast and dynamic
>> DNS, does it?
>
> Nope. I don't think anyone is trying to preclude those from being
> mechanisms for bootstrap or interworking, but rather as the underlying
> resource location mechanism. I thought I captured that by saying
> "locating users and resources", but I maybe not. Others think this is
> too vauge?
I confess that I seem to have read this text the same way Enrico did. It
SHOULD have been clearer than it was. If we all have the same understanding,
the text could be OK.
Thanks,
Spencer
From slavitch at gmail.com Thu Sep 21 14:32:49 2006
From: slavitch at gmail.com (Michael Slavitch)
Date: Thu, 21 Sep 2006 14:32:49 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <62D92A9A02BCC845B202323D49A48426E1CE70@0591-ITS-EXMP02.us.saic.com>
References: <62D92A9A02BCC845B202323D49A48426E1CE70@0591-ITS-EXMP02.us.saic.com>
Message-ID: <1fc32c8f0609211132o2a0e72d2q63e192517fdbabf2@mail.gmail.com>
The "NAT is evil" argument is a matter of faith and belief, a moral
statement that has no place in a protocol working group charter.
Engineering solutions emerge from the judicious study of discernible
reality. NAT exists, therefore it must be dealt with. Period.
>From an engineering standpoint, it creates problems that need to be solved
with solutions that reflect the facts on the ground.
The P2PSIP Working Group must be part of the reality-based community, rather
than part of an ideological community, therefore the working group charter
must distinguish consensus external reality from ideologically created
reality if the working group is to be at all successful. There is
ample evidence that creating one's own reality despite evidence to the
contrary results in failure.
Given that, the word "unfortunate" has no place in an engineering document.
By definition it must be struck.
Regards,
M
On 9/21/06, Roy, Radhika R. RADHIKA.R.ROY at saic.com wrote:
> Mike and all:
>
> I am commenting on NATs.
>
> From IETF point of view, the use of NATs as it is done these days is
> "unfortunate."
>
> Let us see what had been the history of NAT standardization in the IETF?
>
> The IETF charter had been to help the "scarcity" of IPv4 addresses (before
> IPv6 even been proposed). It was hoped that, by the time IPv6 is
> standardized, there is will be no more requirements of NATs to provide
> more
> address spaces.
>
> Now, people have forgot the original usage of NATs. People are using NATs
> as
> a part of "security" for hiding the configurations behind NATs. It is
> completely an "illusion" to be happy to know that people are "secured" by
> using NATs. It is still going on in a mass scale throughout the world, and
> no one knows when this will be stopped.
>
> Should the purpose of the NAT standardization be "SECURITY" or "TOPOLOGY
> HIDING in the name of security," IETF would NEVER standardized NATs for
> these purposes. The rest is history!!!
>
> So, it is UNFORTUNATE so far the MIS-use of NATs is concerned because NATs
> are not needed anymore due to shortage of IPv4 addresses or NATs cannot
> provide security through hiding configurations.
>
> Therefore, the draft charter is CORRECT in this context to use the word
> "UNFORTUNATE."
>
> Best regards,
> Radhika
>
> _____
>
> From: p2p-sip-bounces at cs.columbia.edu on behalf of Michael Slavitch
> Sent: Thu 9/21/2006 10:24 AM
> To: David A. Bryan
> Cc: p2p-sip at cs.columbia.edu
> Subject: Re: [p2p-sip] Revised Draft Charter for P2PSIP
>
>
> I have but one comment:
>
> "The working group takes it as an unfortunate fact that NATs and
> firewalls exist in the Internet, and will ensure that the protocols
> produced work in their presence as much as possible. "
>
> The word 'unfortunate' is editorializing, . NATs have a purpose and
> people
> use them. The IETF doesn't decide what is good.
> Such pejorative comments have no place in a charter.
>
> Apart from that I am happy and we should get on with it.
>
> I agree with Henry that three years is a long time but that is a deadline
> for the charter, not for the group itself. Let's deliver ahead of
> schedule.
>
>
> Regards
>
> Michael
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060921/dfd1cc68/attachment.html
From bryan at ethernot.org Thu Sep 21 14:49:51 2006
From: bryan at ethernot.org (David A. Bryan)
Date: Thu, 21 Sep 2006 14:49:51 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <00db01c6dda9$c61256e0$0300a8c0@china.huawei.com>
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
<4512873B.4080303@telecomitalia.it>
<8b2769930609210608i1bba06e7rf609589e4875298a@mail.gmail.com>
<00db01c6dda9$c61256e0$0300a8c0@china.huawei.com>
Message-ID: <8b2769930609211149kdc01b5epc5d5eebcf0509ab6@mail.gmail.com>
Then we definitely need to reword.
What I am trying to avoid is questions about if we design the system
so that resource location in general is done with a broadcast (flood)
type protocol, which I believe is not the concensus of most folks. We
want to rule that out, while allowing broadcast for things like
locating a bootstrap.
Let me think about some alternate wording, or I am open to any suggestions.
David
On 9/21/06, Spencer Dawkins wrote:
> Hi, David,
>
> >> > The following topics are excluded from the Working Group's scope:
> >> > [..]
> >> > 4. Multicast and dynamic DNS based approaches for locating
> >> > users and resources.
> >>
> >> This does not preclude some solutions for problems that are actually in
> >> scope (e.g. bootstrap, interworking) from using multicast and dynamic
> >> DNS, does it?
> >
> > Nope. I don't think anyone is trying to preclude those from being
> > mechanisms for bootstrap or interworking, but rather as the underlying
> > resource location mechanism. I thought I captured that by saying
> > "locating users and resources", but I maybe not. Others think this is
> > too vauge?
>
> I confess that I seem to have read this text the same way Enrico did. It
> SHOULD have been clearer than it was. If we all have the same understanding,
> the text could be OK.
>
> Thanks,
>
> Spencer
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
From spencer at mcsr-labs.org Thu Sep 21 14:56:06 2006
From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 21 Sep 2006 13:56:06 -0500
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
<4512873B.4080303@telecomitalia.it>
<8b2769930609210608i1bba06e7rf609589e4875298a@mail.gmail.com>
<00db01c6dda9$c61256e0$0300a8c0@china.huawei.com>
<8b2769930609211149kdc01b5epc5d5eebcf0509ab6@mail.gmail.com>
Message-ID: <018d01c6ddaf$9847b790$0300a8c0@china.huawei.com>
> Then we definitely need to reword.
>
> What I am trying to avoid is questions about if we design the system
> so that resource location in general is done with a broadcast (flood)
> type protocol, which I believe is not the concensus of most folks. We
> want to rule that out, while allowing broadcast for things like
> locating a bootstrap.
I agree.
> Let me think about some alternate wording, or I am open to any
> suggestions.
>
> David
"Multicast and dynamic DNS based approaches for locating users and resources
(although these approaches might be in-scope for overlay discovery,
bootstrapping, etc.)"?
(And just to be clear - I agree with Henry's post yesterday that the charter
would be acceptable as proposed, if charter chatter means that we lose focus
on the problem at hand)
Thanks,
Spencer
From RADHIKA.R.ROY at saic.com Thu Sep 21 15:35:58 2006
From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Thu, 21 Sep 2006 15:35:58 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
Message-ID: <62D92A9A02BCC845B202323D49A48426E1CE72@0591-ITS-EXMP02.us.saic.com>
M:
The ONLY reason is this: It is an unsolvable problem.
All IETF WGs have been trying, and have been failing successully!!!
The word UNFORTUNATE is there to discourage for spending too much time for
this technically nonsense problem. That is, p2p-SIP may not be even p2p-SIP
WG anymore at the end of the solution - all fear is this: It might make
p2p-SIP NAT crossing solution as non-p2p-SIP NAT crossing protocol.
I hope I would be be wrong! Who knows what is coming out of by SIP,
SIPPING, NSIS, IPSEC, DIAMETER, and others almost after 6-10 years! Now,
MMUSIC has turned their attention to ICE-xxxxxx versions.
Let us wait for ICE (versions # infinite) to see whether it could be used
for p2p-SP!!! How about this?
RRR
_____
From: Michael Slavitch [mailto:slavitch at gmail.com]
Sent: Thu 9/21/2006 2:32 PM
To: Roy, Radhika R.
Cc: David A. Bryan; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Revised Draft Charter for P2PSIP
The "NAT is evil" argument is a matter of faith and belief, a moral
statement that has no place in a protocol working group charter.
Engineering solutions emerge from the judicious study of discernible
reality. NAT exists, therefore it must be dealt with. Period.
>From an engineering standpoint, it creates problems that need to be solved
with solutions that reflect the facts on the ground.
The P2PSIP Working Group must be part of the reality-based community, rather
than part of an ideological community, therefore the working group charter
must distinguish consensus external reality from ideologically created
reality if the working group is to be at all successful. There is ample
evidence that creating one's own reality despite evidence to the contrary
results in failure.
Given that, the word "unfortunate" has no place in an engineering document.
By definition it must be struck.
Regards,
M
On 9/21/06, Roy, Radhika R. RADHIKA.R.ROY at saic.com
wrote:
Mike and all:
I am commenting on NATs.
>From IETF point of view, the use of NATs as it is done these days is
"unfortunate."
Let us see what had been the history of NAT standardization in the IETF?
The IETF charter had been to help the "scarcity" of IPv4 addresses (before
IPv6 even been proposed). It was hoped that, by the time IPv6 is
standardized, there is will be no more requirements of NATs to provide more
address spaces.
Now, people have forgot the original usage of NATs. People are using NATs as
a part of "security" for hiding the configurations behind NATs. It is
completely an "illusion" to be happy to know that people are "secured" by
using NATs. It is still going on in a mass scale throughout the world, and
no one knows when this will be stopped.
Should the purpose of the NAT standardization be "SECURITY" or "TOPOLOGY
HIDING in the name of security," IETF would NEVER standardized NATs for
these purposes. The rest is history!!!
So, it is UNFORTUNATE so far the MIS-use of NATs is concerned because NATs
are not needed anymore due to shortage of IPv4 addresses or NATs cannot
provide security through hiding configurations.
Therefore, the draft charter is CORRECT in this context to use the word
"UNFORTUNATE."
Best regards,
Radhika
From philip_matthews at magma.ca Thu Sep 21 16:22:45 2006
From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 21 Sep 2006 16:22:45 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <018d01c6ddaf$9847b790$0300a8c0@china.huawei.com>
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
<4512873B.4080303@telecomitalia.it>
<8b2769930609210608i1bba06e7rf609589e4875298a@mail.gmail.com>
<00db01c6dda9$c61256e0$0300a8c0@china.huawei.com>
<8b2769930609211149kdc01b5epc5d5eebcf0509ab6@mail.gmail.com>
<018d01c6ddaf$9847b790$0300a8c0@china.huawei.com>
Message-ID:
On 21-Sep-06, at 14:56 , Spencer Dawkins wrote:
>> Then we definitely need to reword.
>>
>> What I am trying to avoid is questions about if we design the system
>> so that resource location in general is done with a broadcast (flood)
>> type protocol, which I believe is not the concensus of most folks. We
>> want to rule that out, while allowing broadcast for things like
>> locating a bootstrap.
>
> I agree.
>
>> Let me think about some alternate wording, or I am open to any
>> suggestions.
>>
>> David
>
> "Multicast and dynamic DNS based approaches for locating users and
> resources
> (although these approaches might be in-scope for overlay discovery,
> bootstrapping, etc.)"?
>
I had the same question when I read the original paragraph,
and I think that Spencer's proposed re-wording make things clearer.
- Philip
From philip_matthews at magma.ca Thu Sep 21 16:37:14 2006
From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 21 Sep 2006 16:37:14 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <4512CC38.20307@employees.org>
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
<4512BBD0.1070804@employees.org>
<8b2769930609211023hfbbf1efma9b48b83814ae65b@mail.gmail.com>
<4512CC38.20307@employees.org>
Message-ID:
I think Scott's proposal to use the term "Applicability Statement"
is a good one, even if most Applicability Statements that I have
seen are brief documents that do not have the depth that I feel
we want from our proposed document
(e.g., see RFC 3037 or RFC 3210).
I don't think that we are going to give a better description
of what we intend in just one or two sentences in the charter,
so I suggest we go with Scott's proposed term,
given that it is already well-established.
- Philip
On 21-Sep-06, at 13:30 , Scott W Brim wrote:
> On 09/21/2006 13:23 PM, David A. Bryan allegedly wrote:
>> It definitely seems clear we need a new name for the latter
>> "architecture" document. The idea was that the "overview" deliverable
>> (the first one) was the background/basic framework document, and the
>> later architecture document (the last deliverable listed) was a "how
>> to use the tools produced by this group" sort of thing.
>>
>> Applicability document is going down the right path name-wise. Any
>> other suggestions?
>>
>> David
>
> See below for RFC 2026 on applicability statements. It can be called
> a framework, an AS, anything -- even an architecture :-). In the
> charter you can just refer to it generically as an AS.
>
> swb
>
>
> 3. INTERNET STANDARD SPECIFICATIONS
>
> Specifications subject to the Internet Standards Process fall into
> one of two categories: Technical Specification (TS) and
> Applicability Statement (AS).
>
> ...
>
> 3.2 Applicability Statement (AS)
>
> An Applicability Statement specifies how, and under what
> circumstances, one or more TSs may be applied to support a
> particular Internet capability. An AS may specify uses for TSs
> that are not Internet Standards, as discussed in Section 7.
>
> An AS identifies the relevant TSs and the specific way in which
> they are to be combined, and may also specify particular values or
> ranges of TS parameters or subfunctions of a TS protocol that must
> be implemented. An AS also specifies the circumstances in which
> the use of a particular TS is required, recommended, or elective
> (see section
> 3.3).
>
> An AS may describe particular methods of using a TS in a restricted
> "domain of applicability", such as Internet routers, terminal
> servers, Internet systems that interface to Ethernets, or datagram-
> based database servers.
>
> The broadest type of AS is a comprehensive conformance
> specification, commonly called a "requirements document", for a
> particular class of Internet systems, such as Internet routers or
> Internet hosts.
>
> An AS may not have a higher maturity level in the standards track
> than any standards-track TS on which the AS relies (see section
> 4.1). For example, a TS at Draft Standard level may be referenced
> by an AS at the Proposed Standard or Draft Standard level, but not
> by an AS at the Standard level.
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
From philip_matthews at magma.ca Thu Sep 21 17:34:15 2006
From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 21 Sep 2006 17:34:15 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
Message-ID: <73467A8C-0805-4C7D-9C1C-9745A23984A8@magma.ca>
The draft charter says:
> 2. A proposed standard defining a P2PSIP Overlay Peer Protocol. This
> protocol is used between P2PSIP overlay peers, some of which may be
> behind NATs.
Earlier versions of the charter had the word "many" in place of "some"
in a roughly corresponding place. I would prefer to see the word changed
to "most", or if there is strong disagreement on this, at least changed
back to "many".
- Philip
From enrico.marocco at telecomitalia.it Fri Sep 22 03:26:03 2006
From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Fri, 22 Sep 2006 09:26:03 +0200
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <73467A8C-0805-4C7D-9C1C-9745A23984A8@magma.ca>
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
<73467A8C-0805-4C7D-9C1C-9745A23984A8@magma.ca>
Message-ID: <4513900B.4010505@telecomitalia.it>
Philip Matthews wrote:
>> 2. A proposed standard defining a P2PSIP Overlay Peer Protocol. This
>> protocol is used between P2PSIP overlay peers, some of which may be
>> behind NATs.
>
> Earlier versions of the charter had the word "many" in place of "some"
> in a roughly corresponding place. I would prefer to see the word changed
> to "most", or if there is strong disagreement on this, at least changed
> back to "many".
If it was a requirement someone else had to satisfy, "many" would work.
However, since *we* will have to deal with it and since we all agree
that we have to support as many natted peers as we can, "some" is ok. A
stricter requirement here would just have the side effect of increasing
the probability of a failure.
--
Ciao,
Enrico
Ahem.. Sorry, the notice below is not my fault :-(
--------------------------------------------------------------------
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster at telecomitalia.it.
Thank you
www.telecomitalia.it
--------------------------------------------------------------------
From slavitch at gmail.com Fri Sep 22 09:45:29 2006
From: slavitch at gmail.com (Michael Slavitch)
Date: Fri, 22 Sep 2006 09:45:29 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <62D92A9A02BCC845B202323D49A48426E1CE72@0591-ITS-EXMP02.us.saic.com>
References: <62D92A9A02BCC845B202323D49A48426E1CE72@0591-ITS-EXMP02.us.saic.com>
Message-ID: <1fc32c8f0609220645i7df7fdf0i4d51f1231490674@mail.gmail.com>
It is certainly not a nonsense problem outside of some rare circles as
nearly all consumer and business networks fall behind NATs. Without NAT
crossing P2PSIP is useless. I agree that in a deterministic system a perfect
solution is required.
That is why deterministic systems are always so brittle. The world is a
messy fractal place.
By definition P2PSIP will not be deterministic so a perfect solution is not
only unnecessary, it is not desirable if the cost of complexity exceeds the
apparent benefit.
The solutions that exist are statistical and fractal, not perfect and
deterministic. Skype is living proof of a broadly used implementation that
shows that the problem is solved in a matter that meets the requirements for
P2P systems. Since all P2P systems share a common fractal nature a fractal
solution is perfectly suited to the domain.
For all the criticism of ICE, and I've done my fair share, it is getting
simple enough to implement from the draft to be expressed in BNF notation.
It is now fairly easy to build ICE into a finite state machine, as ICE now
describes a completion mechanism where the protocol is complete.
That encourages interoperability from the start.
Any inadequacies that remain result from the fact that client-server SIP is
the only official user of the protocol. These are minor issues that can
only be addressed by MMUSIC once we have a P2PSIP WG that can request
changes. That is a diplomatic problem, not an engineering problem, if the
underlying protocol in ICE can meet base P2PSIP requirements. That is why
WG chairs are chosen carefully.
Regarding unsolved problems: If the underlying system is fractal then a
statistical solution with a high probability of success meets the
requirements for the system. This is true for all fractal systems. The
only issue is determining the probability of success of different solutions
and either choosing one that meets the circumstances at hand or
modifying another to make it an appropriate choice.
I further argue that the fractal nature of ICE is far more suited to the
fractal P2P world than it is to the assumed-deterministic IMS/CS model. It
may be not ever be solved perfectly enough for IMS but for self-organizing
P2PSIP it won't have to be perfect as the nature of a self-organizing
systems is to work around their own shortcomings. P2PSIP will be rugged
enough such that perfect solutions are not needed. If the other working
groups are failing it may be because the systems they are building towards
may be broken and brittle and not rugged enough to tolerate statistical
solutions. Given the talent at hand that will certainly not be the case with
P2PSIP.
Regards
M
On 9/21/06, Roy, Radhika R. wrote:
>
> M:
>
> The ONLY reason is this: It is an unsolvable problem.
>
> All IETF WGs have been trying, and have been failing successully!!!
>
> The word UNFORTUNATE is there to discourage for spending too much time for
> this technically nonsense problem. That is, p2p-SIP may not be even
> p2p-SIP
> WG anymore at the end of the solution - all fear is this: It might make
> p2p-SIP NAT crossing solution as non-p2p-SIP NAT crossing protocol.
>
> I hope I would be be wrong! Who knows what is coming out of by SIP,
> SIPPING, NSIS, IPSEC, DIAMETER, and others almost after 6-10 years! Now,
> MMUSIC has turned their attention to ICE-xxxxxx versions.
>
> Let us wait for ICE (versions # infinite) to see whether it could be used
> for p2p-SP!!! How about this?
>
> RRR
>
> _____
>
> From: Michael Slavitch [mailto:slavitch at gmail.com]
> Sent: Thu 9/21/2006 2:32 PM
> To: Roy, Radhika R.
> Cc: David A. Bryan; p2p-sip at cs.columbia.edu
> Subject: Re: [p2p-sip] Revised Draft Charter for P2PSIP
>
>
> The "NAT is evil" argument is a matter of faith and belief, a moral
> statement that has no place in a protocol working group charter.
> Engineering solutions emerge from the judicious study of discernible
> reality. NAT exists, therefore it must be dealt with. Period.
> From an engineering standpoint, it creates problems that need to be solved
> with solutions that reflect the facts on the ground.
>
> The P2PSIP Working Group must be part of the reality-based community,
> rather
> than part of an ideological community, therefore the working group charter
> must distinguish consensus external reality from ideologically created
> reality if the working group is to be at all successful. There is ample
> evidence that creating one's own reality despite evidence to the contrary
> results in failure.
>
> Given that, the word "unfortunate" has no place in an engineering
> document.
> By definition it must be struck.
>
> Regards,
>
> M
>
>
>
>
> On 9/21/06, Roy, Radhika R. RADHIKA.R.ROY at saic.com
> wrote:
>
> Mike and all:
>
> I am commenting on NATs.
>
> From IETF point of view, the use of NATs as it is done these days is
> "unfortunate."
>
> Let us see what had been the history of NAT standardization in the IETF?
>
> The IETF charter had been to help the "scarcity" of IPv4 addresses (before
> IPv6 even been proposed). It was hoped that, by the time IPv6 is
> standardized, there is will be no more requirements of NATs to provide
> more
> address spaces.
>
> Now, people have forgot the original usage of NATs. People are using NATs
> as
> a part of "security" for hiding the configurations behind NATs. It is
> completely an "illusion" to be happy to know that people are "secured" by
> using NATs. It is still going on in a mass scale throughout the world, and
> no one knows when this will be stopped.
>
> Should the purpose of the NAT standardization be "SECURITY" or "TOPOLOGY
> HIDING in the name of security," IETF would NEVER standardized NATs for
> these purposes. The rest is history!!!
>
> So, it is UNFORTUNATE so far the MIS-use of NATs is concerned because NATs
> are not needed anymore due to shortage of IPv4 addresses or NATs cannot
> provide security through hiding configurations.
>
> Therefore, the draft charter is CORRECT in this context to use the word
> "UNFORTUNATE."
>
> Best regards,
> Radhika
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060922/0693a998/attachment.html
From hsinnrei at adobe.com Fri Sep 22 10:13:16 2006
From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Fri, 22 Sep 2006 07:13:16 -0700
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <1fc32c8f0609220645i7df7fdf0i4d51f1231490674@mail.gmail.com>
Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22155B29@namail5.corp.adobe.com>
This may not fit into the charter discussion, but joining Michael
Slavitch, I would be interested if any or what modifications ICE would
be required for P2P systems, where most peers reside behind a NAT.
Any opinions? Jonathan?
Thanks, Henry
________________________________
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Michael Slavitch
Sent: Friday, September 22, 2006 9:45 AM
To: Roy, Radhika R.
Cc: p2p-sip at cs.columbia.edu; David A. Bryan
Subject: Re: [p2p-sip] Revised Draft Charter for P2PSIP
It is certainly not a nonsense problem outside of some rare circles as
nearly all consumer and business networks fall behind NATs. Without NAT
crossing P2PSIP is useless. I agree that in a deterministic system a
perfect solution is required.
That is why deterministic systems are always so brittle. The world is a
messy fractal place.
By definition P2PSIP will not be deterministic so a perfect solution is
not only unnecessary, it is not desirable if the cost of complexity
exceeds the apparent benefit.
The solutions that exist are statistical and fractal, not perfect and
deterministic. Skype is living proof of a broadly used implementation
that shows that the problem is solved in a matter that meets the
requirements for P2P systems. Since all P2P systems share a common
fractal nature a fractal solution is perfectly suited to the domain.
For all the criticism of ICE, and I've done my fair share, it is getting
simple enough to implement from the draft to be expressed in BNF
notation. It is now fairly easy to build ICE into a finite state
machine, as ICE now describes a completion mechanism where the protocol
is complete. That encourages interoperability from the start.
Any inadequacies that remain result from the fact that client-server SIP
is the only official user of the protocol. These are minor issues that
can only be addressed by MMUSIC once we have a P2PSIP WG that can
request changes. That is a diplomatic problem, not an engineering
problem, if the underlying protocol in ICE can meet base P2PSIP
requirements. That is why WG chairs are chosen carefully.
Regarding unsolved problems: If the underlying system is fractal then a
statistical solution with a high probability of success meets the
requirements for the system. This is true for all fractal systems. The
only issue is determining the probability of success of different
solutions and either choosing one that meets the circumstances at hand
or modifying another to make it an appropriate choice.
I further argue that the fractal nature of ICE is far more suited to the
fractal P2P world than it is to the assumed-deterministic IMS/CS model.
It may be not ever be solved perfectly enough for IMS but for
self-organizing P2PSIP it won't have to be perfect as the nature of a
self-organizing systems is to work around their own shortcomings.
P2PSIP will be rugged enough such that perfect solutions are not needed.
If the other working groups are failing it may be because the systems
they are building towards may be broken and brittle and not rugged
enough to tolerate statistical solutions. Given the talent at hand that
will certainly not be the case with P2PSIP.
Regards
M
On 9/21/06, Roy, Radhika R. wrote:
M:
The ONLY reason is this: It is an unsolvable problem.
All IETF WGs have been trying, and have been failing successully!!!
The word UNFORTUNATE is there to discourage for spending too much time
for
this technically nonsense problem. That is, p2p-SIP may not be even
p2p-SIP
WG anymore at the end of the solution - all fear is this: It might make
p2p-SIP NAT crossing solution as non-p2p-SIP NAT crossing protocol.
I hope I would be be wrong! Who knows what is coming out of by SIP,
SIPPING, NSIS, IPSEC, DIAMETER, and others almost after 6-10 years!
Now,
MMUSIC has turned their attention to ICE-xxxxxx versions.
Let us wait for ICE (versions # infinite) to see whether it could be
used
for p2p-SP!!! How about this?
RRR
_____
From: Michael Slavitch [mailto: slavitch at gmail.com]
Sent: Thu 9/21/2006 2:32 PM
To: Roy, Radhika R.
Cc: David A. Bryan; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Revised Draft Charter for P2PSIP
The "NAT is evil" argument is a matter of faith and belief, a moral
statement that has no place in a protocol working group charter.
Engineering solutions emerge from the judicious study of discernible
reality. NAT exists, therefore it must be dealt with. Period.
>From an engineering standpoint, it creates problems that need to be
solved
with solutions that reflect the facts on the ground.
The P2PSIP Working Group must be part of the reality-based community,
rather
than part of an ideological community, therefore the working group
charter
must distinguish consensus external reality from ideologically created
reality if the working group is to be at all successful. There is ample
evidence that creating one's own reality despite evidence to the
contrary
results in failure.
Given that, the word "unfortunate" has no place in an engineering
document.
By definition it must be struck.
Regards,
M
On 9/21/06, Roy, Radhika R. RADHIKA.R.ROY at saic.com
wrote:
Mike and all:
I am commenting on NATs.
>From IETF point of view, the use of NATs as it is done these days is
"unfortunate."
Let us see what had been the history of NAT standardization in the IETF?
The IETF charter had been to help the "scarcity" of IPv4 addresses
(before
IPv6 even been proposed). It was hoped that, by the time IPv6 is
standardized, there is will be no more requirements of NATs to provide
more
address spaces.
Now, people have forgot the original usage of NATs. People are using
NATs as
a part of "security" for hiding the configurations behind NATs. It is
completely an "illusion" to be happy to know that people are "secured"
by
using NATs. It is still going on in a mass scale throughout the world,
and
no one knows when this will be stopped.
Should the purpose of the NAT standardization be "SECURITY" or "TOPOLOGY
HIDING in the name of security," IETF would NEVER standardized NATs for
these purposes. The rest is history!!!
So, it is UNFORTUNATE so far the MIS-use of NATs is concerned because
NATs
are not needed anymore due to shortage of IPv4 addresses or NATs cannot
provide security through hiding configurations.
Therefore, the draft charter is CORRECT in this context to use the word
"UNFORTUNATE."
Best regards,
Radhika
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060922/78eff884/attachment-0001.html
From RADHIKA.R.ROY at saic.com Fri Sep 22 10:38:46 2006
From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Fri, 22 Sep 2006 10:38:46 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
Message-ID: <62D92A9A02BCC845B202323D49A48426E1CE73@0591-ITS-EXMP02.us.saic.com>
M:
Let us see what comes out of this. I am stamping a time on it: September 22,
2006 - 10:38 AM EDT USA.
I have not seen even a single draft on NAT crossing in p2p-SIP other than
David gave some head start which is far away in solving the NAT crossing.
We will wait for the next 2 years to see the p2p-SIP NAT crossing solution.
ICE is still there even after 5 years.
RRR
BTW: NATs created their own problems for using them beyond what they have
been standardized by the IETF. Since NATs crossed their IETF standardized
boundary, they are also being solved by non-standard ways. We are getting
VoIP and other services through crossing of NATs all the time in
non-standardized ways. No one including Skype is coming for standards of NAT
crossing. Someday NATs will also have their natural death as IETF hoped for.
SIP standards have hinted even indirectly NAT-aware SIP proxy that can
modify SDP going beyond all standardized norms. Even it did not work.
Bottom line: NATs are hopeless in proving services like security and
configuration hiding. To get more address spaces, no one needs NATs anymore.
What is left for usage of NATs? So, the idea is to just cross it by
applications like SIP and p2p-SIP. To just cross the NATs and not to bother
about the security and other aspects, just keep them open as you want. If
this is the case, it is not a big deal as so many proprietary solutions are
used today. Is it is not good enough?
ICE: It wants a standardized way by IETF. So, it is concerned about
security, compatibility, interoperability, and billions of other features.
Here we go again: NATs can be crossed using some standard mechanisms someday
- may be 5 years from now. How about QOS aspects of NATs because they are
the bottleneck as they will be carrying out audio and video real-time media?
NSIS is working on it. It has no clue what kind of signaling messages will
be good to provide the indication that NATs will maintain QOS. Otherwise,
the whole network is OK to provide QOS, but NATs will not.
Conclusion: By the time we solve NAT problems, quantum computers will be a
reality, and IETF will have nothing, but NAT-standardization-supper power
house.
_____
From: Michael Slavitch [mailto:slavitch at gmail.com]
Sent: Fri 9/22/2006 9:45 AM
To: Roy, Radhika R.
Cc: David A. Bryan; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Revised Draft Charter for P2PSIP
It is certainly not a nonsense problem outside of some rare circles as
nearly all consumer and business networks fall behind NATs. Without NAT
crossing P2PSIP is useless. I agree that in a deterministic system a perfect
solution is required.
That is why deterministic systems are always so brittle. The world is a
messy fractal place.
By definition P2PSIP will not be deterministic so a perfect solution is not
only unnecessary, it is not desirable if the cost of complexity exceeds the
apparent benefit.
The solutions that exist are statistical and fractal, not perfect and
deterministic. Skype is living proof of a broadly used implementation that
shows that the problem is solved in a matter that meets the requirements for
P2P systems. Since all P2P systems share a common fractal nature a fractal
solution is perfectly suited to the domain.
For all the criticism of ICE, and I've done my fair share, it is getting
simple enough to implement from the draft to be expressed in BNF notation.
It is now fairly easy to build ICE into a finite state machine, as ICE now
describes a completion mechanism where the protocol is complete. That
encourages interoperability from the start.
Any inadequacies that remain result from the fact that client-server SIP is
the only official user of the protocol. These are minor issues that can
only be addressed by MMUSIC once we have a P2PSIP WG that can request
changes. That is a diplomatic problem, not an engineering problem, if the
underlying protocol in ICE can meet base P2PSIP requirements. That is why
WG chairs are chosen carefully.
Regarding unsolved problems: If the underlying system is fractal then a
statistical solution with a high probability of success meets the
requirements for the system. This is true for all fractal systems. The
only issue is determining the probability of success of different solutions
and either choosing one that meets the circumstances at hand or modifying
another to make it an appropriate choice.
I further argue that the fractal nature of ICE is far more suited to the
fractal P2P world than it is to the assumed-deterministic IMS/CS model. It
may be not ever be solved perfectly enough for IMS but for self-organizing
P2PSIP it won't have to be perfect as the nature of a self-organizing
systems is to work around their own shortcomings. P2PSIP will be rugged
enough such that perfect solutions are not needed. If the other working
groups are failing it may be because the systems they are building towards
may be broken and brittle and not rugged enough to tolerate statistical
solutions. Given the talent at hand that will certainly not be the case with
P2PSIP.
Regards
M
From philip_matthews at magma.ca Fri Sep 22 11:57:46 2006
From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 22 Sep 2006 11:57:46 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <4513900B.4010505@telecomitalia.it>
References: <40CE6C2D-05DF-498F-B44A-B94B882CB3B8@softarmor.com>
<73467A8C-0805-4C7D-9C1C-9745A23984A8@magma.ca>
<4513900B.4010505@telecomitalia.it>
Message-ID:
On 22-Sep-06, at 03:26 , Enrico Marocco wrote:
> Philip Matthews wrote:
>>> 2. A proposed standard defining a P2PSIP Overlay Peer Protocol. This
>>> protocol is used between P2PSIP overlay peers, some of which may be
>>> behind NATs.
>>
>> Earlier versions of the charter had the word "many" in place of
>> "some"
>> in a roughly corresponding place. I would prefer to see the word
>> changed
>> to "most", or if there is strong disagreement on this, at least
>> changed
>> back to "many".
>
> If it was a requirement someone else had to satisfy, "many" would
> work.
> However, since *we* will have to deal with it and since we all agree
> that we have to support as many natted peers as we can, "some" is
> ok. A
> stricter requirement here would just have the side effect of
> increasing
> the probability of a failure.
>
As long as everyone agrees that we will support as many natted peers
as possible,
then I am happy. However, the wording in the charter does not make
this clear
(at least to me), and this topic was a subject of some debate earlier
this year.
- Philip
From philip_matthews at magma.ca Fri Sep 22 13:24:03 2006
From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 22 Sep 2006 13:24:03 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22155B29@namail5.corp.adobe.com>
References: <24CCCC428EFEA2469BF046DB3C7A8D22155B29@namail5.corp.adobe.com>
Message-ID: <4458BB0B-D80A-4641-8799-4A4F08AA5299@magma.ca>
Henry:
Eric Cooper and I have spent quite a bit of time recently working on
ICE to make sure it is suitable for P2PSIP systems.
Back in April, when we first looked at ICE, it worked well when one
peer was behind a NAT and the other had a public IP address, but was
somewhat inefficient due to duplicated checks when both endpoints
were behind (separate) NATs. We published a draft just before the
Montreal meeting that proposed changes to the state machine to
eliminate that problem (draft-matthews-mmusic-ice-eliminating-
duplicates-00), and have since collaborated with Jonathan on this
issue so that the current version of ICE (ICE-10) handles this case
much better.
At present, I don't believe that any changes are required to ICE-UDP
itself to make it more suitable for P2PSIP systems. (I haven't looked
at ICE-TCP in detail yet). The only questions now are around how one
uses ICE in a P2PSIP network, and here at Avaya we are currently
investigating this issue, building on our proposals in draft-matthews-
p2psip-nats-and-overlays-00.
- Philip
On 22-Sep-06, at 10:13 , Henry Sinnreich wrote:
> This may not fit into the charter discussion, but joining Michael
> Slavitch, I would be interested if any or what modifications ICE
> would be required for P2P systems, where most peers reside behind a
> NAT.
>
>
>
> Any opinions? Jonathan?
>
>
>
> Thanks, Henry
>
>
>
> From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-
> bounces at cs.columbia.edu] On Behalf Of Michael Slavitch
> Sent: Friday, September 22, 2006 9:45 AM
> To: Roy, Radhika R.
> Cc: p2p-sip at cs.columbia.edu; David A. Bryan
> Subject: Re: [p2p-sip] Revised Draft Charter for P2PSIP
>
>
>
> It is certainly not a nonsense problem outside of some rare circles
> as nearly all consumer and business networks fall behind NATs.
> Without NAT crossing P2PSIP is useless. I agree that in a
> deterministic system a perfect solution is required.
>
>
>
> That is why deterministic systems are always so brittle. The world
> is a messy fractal place.
>
>
>
> By definition P2PSIP will not be deterministic so a perfect
> solution is not only unnecessary, it is not desirable if the cost
> of complexity exceeds the apparent benefit.
>
>
>
> The solutions that exist are statistical and fractal, not perfect
> and deterministic. Skype is living proof of a broadly used
> implementation that shows that the problem is solved in a matter
> that meets the requirements for P2P systems. Since all P2P systems
> share a common fractal nature a fractal solution is perfectly
> suited to the domain.
>
>
>
> For all the criticism of ICE, and I've done my fair share, it is
> getting simple enough to implement from the draft to be expressed
> in BNF notation. It is now fairly easy to build ICE into a finite
> state machine, as ICE now describes a completion mechanism where
> the protocol is complete. That encourages interoperability from
> the start.
>
>
>
> Any inadequacies that remain result from the fact that client-
> server SIP is the only official user of the protocol. These are
> minor issues that can only be addressed by MMUSIC once we have a
> P2PSIP WG that can request changes. That is a diplomatic problem,
> not an engineering problem, if the underlying protocol in ICE can
> meet base P2PSIP requirements. That is why WG chairs are chosen
> carefully.
>
>
>
> Regarding unsolved problems: If the underlying system is fractal
> then a statistical solution with a high probability of success
> meets the requirements for the system. This is true for all fractal
> systems. The only issue is determining the probability of success
> of different solutions and either choosing one that meets the
> circumstances at hand or modifying another to make it an
> appropriate choice.
>
>
>
> I further argue that the fractal nature of ICE is far more suited
> to the fractal P2P world than it is to the assumed-deterministic
> IMS/CS model. It may be not ever be solved perfectly enough for IMS
> but for self-organizing P2PSIP it won't have to be perfect as the
> nature of a self-organizing systems is to work around their own
> shortcomings. P2PSIP will be rugged enough such that perfect
> solutions are not needed. If the other working groups are failing
> it may be because the systems they are building towards may be
> broken and brittle and not rugged enough to tolerate statistical
> solutions. Given the talent at hand that will certainly not be the
> case with P2PSIP.
>
>
>
> Regards
>
>
>
> M
>
>
>
>
> On 9/21/06, Roy, Radhika R. wrote:
>
> M:
>
> The ONLY reason is this: It is an unsolvable problem.
>
> All IETF WGs have been trying, and have been failing successully!!!
>
> The word UNFORTUNATE is there to discourage for spending too much
> time for
> this technically nonsense problem. That is, p2p-SIP may not be even
> p2p-SIP
> WG anymore at the end of the solution - all fear is this: It might
> make
> p2p-SIP NAT crossing solution as non-p2p-SIP NAT crossing protocol.
>
> I hope I would be be wrong! Who knows what is coming out of by SIP,
> SIPPING, NSIS, IPSEC, DIAMETER, and others almost after 6-10
> years! Now,
> MMUSIC has turned their attention to ICE-xxxxxx versions.
>
> Let us wait for ICE (versions # infinite) to see whether it could
> be used
> for p2p-SP!!! How about this?
>
> RRR
>
> _____
>
> From: Michael Slavitch [mailto: slavitch at gmail.com]
> Sent: Thu 9/21/2006 2:32 PM
> To: Roy, Radhika R.
> Cc: David A. Bryan; p2p-sip at cs.columbia.edu
> Subject: Re: [p2p-sip] Revised Draft Charter for P2PSIP
>
>
> The "NAT is evil" argument is a matter of faith and belief, a moral
> statement that has no place in a protocol working group charter.
> Engineering solutions emerge from the judicious study of discernible
> reality. NAT exists, therefore it must be dealt with. Period.
> >From an engineering standpoint, it creates problems that need to
> be solved
> with solutions that reflect the facts on the ground.
>
> The P2PSIP Working Group must be part of the reality-based
> community, rather
> than part of an ideological community, therefore the working group
> charter
> must distinguish consensus external reality from ideologically created
> reality if the working group is to be at all successful. There is
> ample
> evidence that creating one's own reality despite evidence to the
> contrary
> results in failure.
>
> Given that, the word "unfortunate" has no place in an engineering
> document.
> By definition it must be struck.
>
> Regards,
>
> M
>
>
>
>
> On 9/21/06, Roy, Radhika R. RADHIKA.R.ROY at saic.com
> wrote:
>
> Mike and all:
>
> I am commenting on NATs.
>
> >From IETF point of view, the use of NATs as it is done these days is
> "unfortunate."
>
> Let us see what had been the history of NAT standardization in the
> IETF?
>
> The IETF charter had been to help the "scarcity" of IPv4 addresses
> (before
> IPv6 even been proposed). It was hoped that, by the time IPv6 is
> standardized, there is will be no more requirements of NATs to
> provide more
> address spaces.
>
> Now, people have forgot the original usage of NATs. People are
> using NATs as
> a part of "security" for hiding the configurations behind NATs. It is
> completely an "illusion" to be happy to know that people are
> "secured" by
> using NATs. It is still going on in a mass scale throughout the
> world, and
> no one knows when this will be stopped.
>
> Should the purpose of the NAT standardization be "SECURITY" or
> "TOPOLOGY
> HIDING in the name of security," IETF would NEVER standardized NATs
> for
> these purposes. The rest is history!!!
>
> So, it is UNFORTUNATE so far the MIS-use of NATs is concerned
> because NATs
> are not needed anymore due to shortage of IPv4 addresses or NATs
> cannot
> provide security through hiding configurations.
>
> Therefore, the draft charter is CORRECT in this context to use the
> word
> "UNFORTUNATE."
>
> Best regards,
> Radhika
>
>
>
>
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060922/4111d22f/attachment-0001.html
From philip_matthews at magma.ca Fri Sep 22 13:30:45 2006
From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 22 Sep 2006 13:30:45 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <62D92A9A02BCC845B202323D49A48426E1CE73@0591-ITS-EXMP02.us.saic.com>
References: <62D92A9A02BCC845B202323D49A48426E1CE73@0591-ITS-EXMP02.us.saic.com>
Message-ID: <0180AF1C-3B0E-4771-BFDB-D0BF2EC4DB3E@magma.ca>
On 22-Sep-06, at 10:38 , Roy, Radhika R. wrote:
>
> Let us see what comes out of this. I am stamping a time on it:
> September 22,
> 2006 - 10:38 AM EDT USA.
>
> I have not seen even a single draft on NAT crossing in p2p-SIP
> other than
> David gave some head start which is far away in solving the NAT
> crossing.
>
draft-matthews-p2psip-nats-and-overlays-00 was published back in
February
and presented at the P2PSIP ad-hoc in Dallas.
It has recently expired from the IETF directory, but can be still
retrieved
from www.p2psip.org.
At Avaya, we are actively working on extending these ideas and
incorporating
ICE into the proposal. We hope to have something that we can write up
and
publish fairly soon.
- Philip
From RADHIKA.R.ROY at saic.com Fri Sep 22 16:06:07 2006
From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Fri, 22 Sep 2006 16:06:07 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
Message-ID: <62D92A9A02BCC845B202323D49A48426E1CE75@0591-ITS-EXMP02.us.saic.com>
Philip:
It is OK to look into those solutions using ICE for p2p-SIP.
A 2-year time period for development NAT-crossing standard for p2p-SIP will
be OK.
However, let us spend our most energy to develop the best p2p-SIP protocol
which is the future direction of the Internet.
Best regards,
Radhika
PS:
BTW: Even it is OK to cross NATs by p2p-SIP, will you also be looking for
the support of QOS so that NATs are NOT forcing more intelligent entities
around NATs not to mention NAT-crossing clients, servers, security patches,
QOS brokering, and many others so that cannons are used to kill a mosquito?
If not, why not? If yes, would you and others provide suggestions to NSIS WG
as they are almost lost to do anything good that works well?
NATs will have their natural death as firewalls are much more superior to do
all those jobs of NATs without causing problems for SIP signaling and media
and other applications, but p2p-SIP is NOT.
_____
From: Philip Matthews [mailto:philip_matthews at magma.ca]
Sent: Fri 9/22/2006 1:24 PM
To: Henry Sinnreich
Cc: Michael Slavitch; Roy, Radhika R.; P2P-SIP
Subject: Re: [p2p-sip] Revised Draft Charter for P2PSIP
Henry:
Eric Cooper and I have spent quite a bit of time recently working on ICE to
make sure it is suitable for P2PSIP systems.
Back in April, when we first looked at ICE, it worked well when one peer was
behind a NAT and the other had a public IP address, but was somewhat
inefficient due to duplicated checks when both endpoints were behind
(separate) NATs. We published a draft just before the Montreal meeting that
proposed changes to the state machine to eliminate that problem
(draft-matthews-mmusic-ice-eliminating-duplicates-00), and have since
collaborated with Jonathan on this issue so that the current version of ICE
(ICE-10) handles this case much better.
At present, I don't believe that any changes are required to ICE-UDP itself
to make it more suitable for P2PSIP systems. (I haven't looked at ICE-TCP in
detail yet). The only questions now are around how one uses ICE in a P2PSIP
network, and here at Avaya we are currently investigating this issue,
building on our proposals in draft-matthews-p2psip-nats-and-overlays-00.
- Philip
On 22-Sep-06, at 10:13 , Henry Sinnreich wrote:
This may not fit into the charter discussion, but joining Michael Slavitch,
I would be interested if any or what modifications ICE would be required for
P2P systems, where most peers reside behind a NAT.
Any opinions? Jonathan?
Thanks, Henry
_____
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu
] On Behalf Of Michael Slavitch
Sent: Friday, September 22, 2006 9:45 AM
To: Roy, Radhika R.
Cc: p2p-sip at cs.columbia.edu ; David A.
Bryan
Subject: Re: [p2p-sip] Revised Draft Charter for P2PSIP
It is certainly not a nonsense problem outside of some rare circles as
nearly all consumer and business networks fall behind NATs. Without NAT
crossing P2PSIP is useless. I agree that in a deterministic system a perfect
solution is required.
That is why deterministic systems are always so brittle. The world is a
messy fractal place.
By definition P2PSIP will not be deterministic so a perfect solution is not
only unnecessary, it is not desirable if the cost of complexity exceeds the
apparent benefit.
The solutions that exist are statistical and fractal, not perfect and
deterministic. Skype is living proof of a broadly used implementation that
shows that the problem is solved in a matter that meets the requirements for
P2P systems. Since all P2P systems share a common fractal nature a fractal
solution is perfectly suited to the domain.
For all the criticism of ICE, and I've done my fair share, it is getting
simple enough to implement from the draft to be expressed in BNF notation.
It is now fairly easy to build ICE into a finite state machine, as ICE now
describes a completion mechanism where the protocol is complete. That
encourages interoperability from the start.
Any inadequacies that remain result from the fact that client-server SIP is
the only official user of the protocol. These are minor issues that can
only be addressed by MMUSIC once we have a P2PSIP WG that can request
changes. That is a diplomatic problem, not an engineering problem, if the
underlying protocol in ICE can meet base P2PSIP requirements. That is why
WG chairs are chosen carefully.
Regarding unsolved problems: If the underlying system is fractal then a
statistical solution with a high probability of success meets the
requirements for the system. This is true for all fractal systems. The
only issue is determining the probability of success of different solutions
and either choosing one that meets the circumstances at hand or modifying
another to make it an appropriate choice.
I further argue that the fractal nature of ICE is far more suited to the
fractal P2P world than it is to the assumed-deterministic IMS/CS model. It
may be not ever be solved perfectly enough for IMS but for self-organizing
P2PSIP it won't have to be perfect as the nature of a self-organizing
systems is to work around their own shortcomings. P2PSIP will be rugged
enough such that perfect solutions are not needed. If the other working
groups are failing it may be because the systems they are building towards
may be broken and brittle and not rugged enough to tolerate statistical
solutions. Given the talent at hand that will certainly not be the case with
P2PSIP.
Regards
M
On 9/21/06, Roy, Radhika R. > wrote:
M:
The ONLY reason is this: It is an unsolvable problem.
All IETF WGs have been trying, and have been failing successully!!!
The word UNFORTUNATE is there to discourage for spending too much time for
this technically nonsense problem. That is, p2p-SIP may not be even p2p-SIP
WG anymore at the end of the solution - all fear is this: It might make
p2p-SIP NAT crossing solution as non-p2p-SIP NAT crossing protocol.
I hope I would be be wrong! Who knows what is coming out of by SIP,
SIPPING, NSIS, IPSEC, DIAMETER, and others almost after 6-10 years! Now,
MMUSIC has turned their attention to ICE-xxxxxx versions.
Let us wait for ICE (versions # infinite) to see whether it could be used
for p2p-SP!!! How about this?
RRR
_____
From: Michael Slavitch [mailto: slavitch at gmail.com
]
Sent: Thu 9/21/2006 2:32 PM
To: Roy, Radhika R.
Cc: David A. Bryan; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Revised Draft Charter for P2PSIP
The "NAT is evil" argument is a matter of faith and belief, a moral
statement that has no place in a protocol working group charter.
Engineering solutions emerge from the judicious study of discernible
reality. NAT exists, therefore it must be dealt with. Period.
>From an engineering standpoint, it creates problems that need to be solved
with solutions that reflect the facts on the ground.
The P2PSIP Working Group must be part of the reality-based community, rather
than part of an ideological community, therefore the working group charter
must distinguish consensus external reality from ideologically created
reality if the working group is to be at all successful. There is ample
evidence that creating one's own reality despite evidence to the contrary
results in failure.
Given that, the word "unfortunate" has no place in an engineering document.
By definition it must be struck.
Regards,
M
On 9/21/06, Roy, Radhika R. RADHIKA.R.ROY at saic.com
> wrote:
Mike and all:
I am commenting on NATs.
>From IETF point of view, the use of NATs as it is done these days is
"unfortunate."
Let us see what had been the history of NAT standardization in the IETF?
The IETF charter had been to help the "scarcity" of IPv4 addresses (before
IPv6 even been proposed). It was hoped that, by the time IPv6 is
standardized, there is will be no more requirements of NATs to provide more
address spaces.
Now, people have forgot the original usage of NATs. People are using NATs as
a part of "security" for hiding the configurations behind NATs. It is
completely an "illusion" to be happy to know that people are "secured" by
using NATs. It is still going on in a mass scale throughout the world, and
no one knows when this will be stopped.
Should the purpose of the NAT standardization be "SECURITY" or "TOPOLOGY
HIDING in the name of security," IETF would NEVER standardized NATs for
these purposes. The rest is history!!!
So, it is UNFORTUNATE so far the MIS-use of NATs is concerned because NATs
are not needed anymore due to shortage of IPv4 addresses or NATs cannot
provide security through hiding configurations.
Therefore, the draft charter is CORRECT in this context to use the word
"UNFORTUNATE."
Best regards,
Radhika
_______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
From philip_matthews at magma.ca Sat Sep 23 12:36:08 2006
From: philip_matthews at magma.ca (Philip Matthews)
Date: Sat, 23 Sep 2006 12:36:08 -0400
Subject: [p2p-sip] Revised Draft Charter for P2PSIP
In-Reply-To: <62D92A9A02BCC845B202323D49A48426E1CE75@0591-ITS-EXMP02.us.saic.com>
References: <62D92A9A02BCC845B202323D49A48426E1CE75@0591-ITS-EXMP02.us.saic.com>
Message-ID: <1534D509-593E-459A-BFB9-1874444A701B@magma.ca>
On 22-Sep-06, at 16:06 , Roy, Radhika R. wrote:
> Philip:
>
> It is OK to look into those solutions using ICE for p2p-SIP.
>
> A 2-year time period for development NAT-crossing standard for p2p-
> SIP will
> be OK.
I am hoping that it will not take us two years to agree on a standard.
[Of course, it has taken us almost a year and a half so far to get
the WG formed,
so perhaps I am being foolishly optimistic]
>
> PS:
>
> BTW: Even it is OK to cross NATs by p2p-SIP, will you also be
> looking for
> the support of QOS so that NATs are NOT forcing more intelligent
> entities
> around NATs not to mention NAT-crossing clients, servers, security
> patches,
> QOS brokering, and many others so that cannons are used to kill a
> mosquito?
We have not considered QOS issues in our work to date.
We are still considering basic connectivity issues.
>
> If not, why not? If yes, would you and others provide suggestions
> to NSIS WG
> as they are almost lost to do anything good that works well?
>
> NATs will have their natural death as firewalls are much more
> superior to do
> all those jobs of NATs without causing problems for SIP signaling
> and media
> and other applications, but p2p-SIP is NOT.
- Philip
From tutschku at informatik.uni-wuerzburg.de Wed Sep 27 12:23:18 2006
From: tutschku at informatik.uni-wuerzburg.de (Kurt Tutschku)
Date: Wed, 27 Sep 2006 18:23:18 +0200
Subject: [p2p-sip] CfP: MobileP2P'07 - Deadline Extension
Message-ID: <001001c6e251$3de2f430$806abb84@Musa>
---------------------------------------------------------------------
Deadline extension: Oct. 13, 2006
---------------------------------------------------------------------
Call-for-Paper
---------------------------------------------------------------------
4th IEEE International Workshop on Mobile Peer-to-Peer Computing (MP2P'07)
http://www-info3.informatik.uni-wuerzburg.de/mp2p2007
White Plains, NY, USA, March 19-23, 2007
In conjunction with the 5th IEEE International Conference on
Pervasive Computing and Communications (PerCom07)
http://www.percom.org/
----------------------------------------------------------------------
Peer-to-Peer (P2P) computing is a networking and distributed computing
paradigm which allows the sharing of computing resources and services
by direct, symmetric interaction between computers. The advance in
mobile wireless communication technology and the increasing number of
mobile users, extend the arena of P2P computing to encompass mobile
devices and wireless networks. The special characteristics of mobile
environments, such as highly variable connectivity, disconnection,
location-dependency, resource contraints, and diversity in wireless
networks as well as carrier-grade performance requirements bring new
challenges for research in mobile P2P computing.
Based on the success of its three predecessors, MP2P?07 is intended to
serve as a continuing forum for scientists and engineers in academia and
industry to exchange and discuss their experiences, new ideas, and research
results about all aspects of mobile P2P computing.
It will address the challenges, technologies, and architectures leading
to real-world solutions that provide users with direct access and control
of their critical peer-based information and services, regardless of
location
or device. The principal theme of MP2P?07 is the development of protocols,
systems and applications of mobile P2P architectures and the evaluation
of their performance.
Topics of particular interest include, but are not limited to:
- Architecture and platforms for mobile P2P computing
- Measurement studies on mobile P2P systems
- Performance of mobile P2P services
- Resource and service discovery in mobile P2P computing
- Resource exchange mechanisms in mobile P2P application
- Multicast Protocols in mobile networks
- Energy saving P2P protocols for mobile devices
- Mobile P2P in wirelesss sensor networks
- Security in mobile P2P networks
- Mobile P2P over different kinds of bearer services: 2.5/3G (GPRS/UMTS) /
802.11 (WLAN)
- Mobile P2P & operator/provider requirements
- Reliability and carrier-gradeness of mobile P2P services
- Mobile P2P SIP
- Mobile P2P & fixed P2P system interworking
- Issues of combining P2P services with mobility (mobile IP / MANET)
- Peer access and control in mobile environment
- Location dependent mobile P2P services
- Data exchange and rendering techniques for mobile devices
- Secure communication protocols for mobile P2P computing
- Mobile P2P messaging systems
- Peer-to-peer broadband wireless communications
- Applications of mobile P2P
- Middleware for mobile P2P
- Nature-inspired algorithms for mobile P2P computing
- Theoretical issues on mobile information diffusion
- Mobile P2P video games
- Stimulating cooperation in mobile computing
- Multicast Protocols in mobile networks
- Energy saving P2P protocols for mobile devices
- Mobile P2P in wirelesss sensor networks
Paper Submission:
-----------------
Papers must be written in English and should not exceed 5 pages in IEEE
proceedings style. All submissions must describe original research, not
published nor currently under review for another conference or journal.
Authors MUST submit their papers through the PERDAS web site
(http://www.percom.org/perdas) in three steps:
* Creation of a personal account on PERDAS (if the author does not already
have one)
* Registration of the paper (requiring a short abstract of up to 150 words)
* Upload of the paper. Only in pdf format
Submission implies the willingness of at least one of the authors to
register and present the paper.
There is only one registration for the whole PerCom "convention", all
workshops included. The only exception from the full-registration rule is:
an author can register for her/his paper with a student registration if i)
(s)he is a student AND ii) on of her/his co-authors has a full registration
with PerCom.
All submissions will be reviewed and selected based on their originality of
the paper. Accepted papers must be presented at the workshop and will appear
in a combined PerCom 2007 workshop proceedings published by IEEE Computer
Society Press.
Authors that present a system in their paper are highly encouraged to
demonstrate also the system in the demo session of the workshop.
Important Dates:
----------------
Papers due: 5pm EST, October 13, 2006
(NEW)
Notification of acceptance November 25, 2006
Camera-ready papers due to IEEE December 22, 2006
Organizing Committee, Program Co-chairs:
----------------------------------------
Kurt Tutschku, Department of Distributed Systems, University of W?rzburg,
Germany.
John Buford, Panasonic Princeton Laboratory, USA.
Li Li, Communications Research Center Canada, Canada.
Steering Board:
---------------
- Jiannong Cao, Department of Computing, Hong Kong Polytechnic University.
- Y. Charlie Hu, School of Electrical and Computer Engineering, Purdue
University.
- Cecilia Mascolo, Department of Computer Science, University College
London.
- Maria Papadopouli, Department of Computer Science, University of North
Carolina at Chapel Hill.
- Frank-Uwe Andersen, Siemens Communications, Germany.
Publicity Chair:
----------------
Kurt Tutschku, Department of Distributed Systems, University of W?rzburg,
Germany
Program Committee Members:
--------------------------
- Arup Acharya, IBM Watson Research Lab, USA.
- Frank-Uwe Andersen, Siemens Communications, Germany.
- Jiannong Cao, Hong Kong Polytechnic University, Hong Kong.
- Geoff Coulson, Lancaster University, Lancaster, UK.
- Hermann de Meer, Department of Computer Networks & Computer
Communications, University of Passau, Germany.
- Franca Delmastro, CNR-IIT ,Pisa, Italy.
- Krishna Dhara, Avaya Labs Research.
- Babak Esfandiari, Carleton University, Canada.
- Stephen Hailes, Department of Computer Science, University College of
London, UK.
- Felix Hernandez-Campos, Department of Computer Science, University of
North Carolina at Chapel Hill, USA.
- Y. Charlie Hu, School of Electrical and Computer Engineering, Purdue
University, USA.
- Norihiro Ishikawa, NTT Docomo, Japan.
- Valerie Issarny, INRIA, France.
- Wolfgang Kellerer, DoCoMo Communications Laboratories Europe, Germany.
- Kazuhiro Kitagawa, Keio University, Japan.
- Rajeev Koodli, Nokia Research, USA.
- Thomas Kunz, Dept. of Systems and Comp. Engineering, Carleton University,
Canada.
- Li Li, Communications Research Center Canada, , Canada.
- Christoph Lindemann, Depart. of Communication Networks and Distributed
Systems, University of Leipzig, Germany.
- Vishal Misra, Dept. of Computer Science, Columbia University, New York,
USA.
- Maria Papadopouli, Department of Computer Science, University of North
Carolina at Chapel Hill , USA.
- Rudolf Riedi, Department of Statistics, Rice University , USA.
- George Roussos, School of Computer Science and Information Systems -
Birkbeck College, University of London, UK.
- Jochen Schiller, Institute of Computer Science, FU Berlin, Germany.
- Hans-Peter Schwefel, Department of Communication Technology, Aalborg
University, Denmark.
- Shervin Shirmohammadi, School of Information Technology and Engineering
(SITE), University of Ottawa, Canada.
- Apostolos Traganitis, Telecommunications and Networks
Laboratory,University of Crete, Greece.
- Kurt Tutschku, Department of Distributed Systems, University of W?rzburg,
Germany.
- Klaus Wehrle, Distributed Systems Group, RWTH Aachen, Germany.
- Chansu Yu, Department of Electrical and Computer Engineering, Cleveland
State University, USA.
From spencer at mcsr-labs.org Wed Sep 27 15:57:43 2006
From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Wed, 27 Sep 2006 14:57:43 -0500
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com>
<85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com>
Message-ID: <080601c6e26f$32492720$0300a8c0@china.huawei.com>
Hi, Dean,
Just following up on some ascii artwork, and some questions...
Thanks,
Spencer
>> - Figure 1 seems confused on whether the UA/Peers behind the NATs are
>> part
>> of the overlay or not - I think I can draw the lines more clearly (shown
>> below), assuming that they ARE part of the overlay.
>
> No doubt. They're meant to be part of the overlay.
>
>> - Figure 1 is also trying to do more than you can do in ASCII art (at
>> least
>> I think so) - the dotted lines either mean (a) logical connectivity in
>> the
>> overlay, (b) physical connectivity through the NATs, or (c) a SIP call.
>> I
>> doubled the lines for the overlay topology, but left the SIP calls in
>> and
>> don't like the result. If people agree, I can do ASCII art for (a) and
>> (c),
>> as two figures.
>
> That might work.
I ended up with three pictures - one with a reference architecture, one with
a SIP routed INCITE, and one with a SIP redirected INVITE.
I also did some cleanup with box corners and using "#" to delimit the P2PSIP
Overlay, and labeled all the boxes unambiguously.
Please let me know how to improve this. If it's worth including in the
draft, I'll write some descriptive text, starting with what's in the draft
now.
--->PSTN
+---------+ /
+------+ |N| | Gateway |-/
| |########|A|########| Peer |##############
| UA | |T| | G | # Client Protocol
| Peer | +---------+ # GET/PUT
| C | # |
+------+ # | \__/
# # v / \
|NAT| #======/ UA \
# P2PSIP Overlay # /Client\
# # |___C__|
# Route Data #
+------+ +------+ #
| | |N| | | #
| UA |#|A|##| UA | #
| Peer | |T| | Peer | #
| D | | E | #
+------+ +------+ #
Peer Protocol # +-------+ +-------+ #
# | | | | #
####| Proxy |########| Redir |####
| Peer | | Peer |
| P | | R |
+-------+ +-------+
\__/ \__/
/\ /\
/ \ / \
/ UA \ / UA \
/______\ /______\
SIP UA A SIP UA B
Figure: P2PSIP Overlay Reference Model
What I was trying to show in this figure was that the UA Client C is aware
of the P2PSIP overlay, while the SIP UAs A and B are not.
In the following picture, I'm showing normal SIP signaling through from SIP
UA A to UA Peer E, through Proxy Peer C.
--->PSTN
+---------+ /
+------+ |N| | Gateway |-/
| |########|A|########| Peer |##############
| UA | |T| | G | # Client Protocol
| Peer | +---------+ # GET/PUT
| C | # |
+------+ # | \__/
# # v / \
|NAT| #======/ UA \
# P2PSIP Overlay # /Client\
# # |___C__|
# Route Data #
+------+ +------+ #
| | |N| | | #
| UA |#|A|##| UA |----- SIP #
| Peer | |T| | Peer | | INVITE/200 OK #
| D | | E | | #
+------+ +------+ | #
Peer Protocol # +-------+ +-------+ #
# | | | | #
####| Proxy |########| Redir |####
| Peer | | Peer |
| P | | R |
+-------+ +-------+
/
/
\__/ / SIP INVITE/200 OK \__/
/\ / /\
/ \/ / \
/ UA \ / UA \
/______\ /______\
SIP UA A SIP UA B
Figure: Proxied SIP call from SIP UA to P2PSIP UA through Peer Proxy
In the following figure, I'm showing the SIP signaling for a call initiated
from outside the P2PSIP Overlay to a Client, with redirect from a Redirect
Server.
--->PSTN
+---------+ /
+------+ |N| | Gateway |-/
| |########|A|########| Peer |##############
| UA | |T| | | # Client Protocol
| Peer | +---------+ # GET/PUT
| C | # |
+------+ # | \__/
# # v / \
|NAT| #======/ UA \
# P2PSIP Overlay # /Client\
# # |______|
# Route Data # ^
+------+ +------+ # |
| | |N| | | # |
| UA |#|A|##| UA | # |
| Peer | |T| | Peer | # |
| D | | E | # |
+------+ +------+ # SIP |
Peer Protocol # +-------+ +-------+ # INVITE/200 OK
# | | | | # |
####| Proxy |########| Redir |#### |
| Peer | | Peer | |
| | | | |
+-------+ +-------+ |
\ |
SIP \ /
\__/ INVITE/302 Moved \ \__/ /
/\ \ /\ /
/ \ \/ \/
/ UA \ / UA \
/______\ /______\
SIP UA A SIP UA B
Figure: Redirect from P2PSIP Overlay
A little further into our discussion of the draft...
>> - I'm very confused about how both clients and peers can be "endpoints".
>> For
>> one thing, I'm not sure how "endpoint-to-endpoint trust" works. I
>> suspect
>> that this is conflating P2P endpoints (peers) with SIP endpoints (either
>> a
>> UA-peer or a UA-client). If you guys understand this perfectly, please
>> keep
>> typing...
>>
>
> Peers are supersets of clients. Everything a client can do, a peer can
> do.
I really like this sentence - if others agree, I'd like to see it in the
draft.
I did have one question - the Client GET/PUT protocol will be unicast to a
specific P2PSIP overlay peer, won't it? How should the Client choose a
specific overlay peer?
Thanks,
Spencer
From eunsoo at research.panasonic.com Wed Sep 27 16:21:51 2006
From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Wed, 27 Sep 2006 16:21:51 -0400
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
In-Reply-To: <080601c6e26f$32492720$0300a8c0@china.huawei.com>
References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com>
<080601c6e26f$32492720$0300a8c0@china.huawei.com>
Message-ID: <451ADD5F.6010206@research.panasonic.com>
Hi, Spencer,
All the three diagrams look good.
My comments are inline.
Spencer Dawkins wrote:
> Hi, Dean,
>
> Just following up on some ascii artwork, and some questions...
>
> Thanks,
>
> Spencer
>
>>> - Figure 1 seems confused on whether the UA/Peers behind the NATs are
>>> part
>>> of the overlay or not - I think I can draw the lines more clearly (shown
>>> below), assuming that they ARE part of the overlay.
>> No doubt. They're meant to be part of the overlay.
>>
>>> - Figure 1 is also trying to do more than you can do in ASCII art (at
>>> least
>>> I think so) - the dotted lines either mean (a) logical connectivity in
>>> the
>>> overlay, (b) physical connectivity through the NATs, or (c) a SIP call.
>>> I
>>> doubled the lines for the overlay topology, but left the SIP calls in
>>> and
>>> don't like the result. If people agree, I can do ASCII art for (a) and
>>> (c),
>>> as two figures.
>> That might work.
>
> I ended up with three pictures - one with a reference architecture, one with
> a SIP routed INCITE, and one with a SIP redirected INVITE.
>
> I also did some cleanup with box corners and using "#" to delimit the P2PSIP
> Overlay, and labeled all the boxes unambiguously.
>
> Please let me know how to improve this. If it's worth including in the
> draft, I'll write some descriptive text, starting with what's in the draft
> now.
>
> --->PSTN
> +---------+ /
> +------+ |N| | Gateway |-/
> | |########|A|########| Peer |##############
> | UA | |T| | G | # Client Protocol
> | Peer | +---------+ # GET/PUT
> | C | # |
> +------+ # | \__/
> # # v / \
> |NAT| #======/ UA \
> # P2PSIP Overlay # /Client\
> # # |___C__|
> # Route Data #
> +------+ +------+ #
> | | |N| | | #
> | UA |#|A|##| UA | #
> | Peer | |T| | Peer | #
> | D | | E | #
> +------+ +------+ #
> Peer Protocol # +-------+ +-------+ #
> # | | | | #
> ####| Proxy |########| Redir |####
> | Peer | | Peer |
> | P | | R |
> +-------+ +-------+
>
>
> \__/ \__/
> /\ /\
> / \ / \
> / UA \ / UA \
> /______\ /______\
> SIP UA A SIP UA B
>
> Figure: P2PSIP Overlay Reference Model
>
> What I was trying to show in this figure was that the UA Client C is aware
> of the P2PSIP overlay, while the SIP UAs A and B are not.
A Client node should send its GET/PUT requests to a Peer (or Peers). In
other words, the Client Protocol is spoken between a Client and a Peer.
In that sense, I guess it would be better if the line from UA Client C
is connected to one of Peers. What do you think?
>
> In the following picture, I'm showing normal SIP signaling through from SIP
> UA A to UA Peer E, through Proxy Peer C.
>
> --->PSTN
> +---------+ /
> +------+ |N| | Gateway |-/
> | |########|A|########| Peer |##############
> | UA | |T| | G | # Client Protocol
> | Peer | +---------+ # GET/PUT
> | C | # |
> +------+ # | \__/
> # # v / \
> |NAT| #======/ UA \
> # P2PSIP Overlay # /Client\
> # # |___C__|
> # Route Data #
> +------+ +------+ #
> | | |N| | | #
> | UA |#|A|##| UA |----- SIP #
> | Peer | |T| | Peer | | INVITE/200 OK #
> | D | | E | | #
> +------+ +------+ | #
> Peer Protocol # +-------+ +-------+ #
> # | | | | #
> ####| Proxy |########| Redir |####
> | Peer | | Peer |
> | P | | R |
> +-------+ +-------+
> /
> /
> \__/ / SIP INVITE/200 OK \__/
> /\ / /\
> / \/ / \
> / UA \ / UA \
> /______\ /______\
> SIP UA A SIP UA B
>
> Figure: Proxied SIP call from SIP UA to P2PSIP UA through Peer Proxy
>
> In the following figure, I'm showing the SIP signaling for a call initiated
> from outside the P2PSIP Overlay to a Client, with redirect from a Redirect
> Server.
>
> --->PSTN
> +---------+ /
> +------+ |N| | Gateway |-/
> | |########|A|########| Peer |##############
> | UA | |T| | | # Client Protocol
> | Peer | +---------+ # GET/PUT
> | C | # |
> +------+ # | \__/
> # # v / \
> |NAT| #======/ UA \
> # P2PSIP Overlay # /Client\
> # # |______|
> # Route Data # ^
> +------+ +------+ # |
> | | |N| | | # |
> | UA |#|A|##| UA | # |
> | Peer | |T| | Peer | # |
> | D | | E | # |
> +------+ +------+ # SIP |
> Peer Protocol # +-------+ +-------+ # INVITE/200 OK
> # | | | | # |
> ####| Proxy |########| Redir |#### |
> | Peer | | Peer | |
> | | | | |
> +-------+ +-------+ |
> \ |
> SIP \ /
> \__/ INVITE/302 Moved \ \__/ /
> /\ \ /\ /
> / \ \/ \/
> / UA \ / UA \
> /______\ /______\
> SIP UA A SIP UA B
>
> Figure: Redirect from P2PSIP Overlay
>
> A little further into our discussion of the draft...
>
>>> - I'm very confused about how both clients and peers can be "endpoints".
>>> For
>>> one thing, I'm not sure how "endpoint-to-endpoint trust" works. I
>>> suspect
>>> that this is conflating P2P endpoints (peers) with SIP endpoints (either
>>> a
>>> UA-peer or a UA-client). If you guys understand this perfectly, please
>>> keep
>>> typing...
>>>
>> Peers are supersets of clients. Everything a client can do, a peer can
>> do.
>
> I really like this sentence - if others agree, I'd like to see it in the
> draft.
>
I agree.
> I did have one question - the Client GET/PUT protocol will be unicast to a
> specific P2PSIP overlay peer, won't it?
I think so.
How should the Client choose a
> specific overlay peer?
A Client can get information about some existing Peers from P2PSIP
Overlay Bootstrap Server. The Client can keep the information and send
the PUT/GET request to those Peers.
Over the time, the Client may be able to find other Peers. We should
make sure there is a mechanism for that. Otherwise, many Clients may be
stuck with the same set of Peers that are known to the Bootstrap Server.
One possible solution is to assign a Node ID to the Client as well and
let the Client talk to the Peer whose Node ID is closest to the Client's
Node ID. It works because the Client should be able to find a Peer whose
Node ID is closest to the Client's Node ID from DHT.
Thanks.
Eunsoo
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
From bryan at ethernot.org Wed Sep 27 16:55:41 2006
From: bryan at ethernot.org (David A. Bryan)
Date: Wed, 27 Sep 2006 16:55:41 -0400
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
In-Reply-To: <451ADD5F.6010206@research.panasonic.com>
References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com>
<85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com>
<080601c6e26f$32492720$0300a8c0@china.huawei.com>
<451ADD5F.6010206@research.panasonic.com>
Message-ID: <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com>
Comments inline.
On 9/27/06, Eunsoo Shim wrote:
> Hi, Spencer,
>
> All the three diagrams look good.
> My comments are inline.
>
> Spencer Dawkins wrote:
> > Hi, Dean,
> >
> > Just following up on some ascii artwork, and some questions...
> >
> > Thanks,
> >
> > Spencer
> >
> >>> - Figure 1 seems confused on whether the UA/Peers behind the NATs are
> >>> part
> >>> of the overlay or not - I think I can draw the lines more clearly (shown
> >>> below), assuming that they ARE part of the overlay.
> >> No doubt. They're meant to be part of the overlay.
> >>
> >>> - Figure 1 is also trying to do more than you can do in ASCII art (at
> >>> least
> >>> I think so) - the dotted lines either mean (a) logical connectivity in
> >>> the
> >>> overlay, (b) physical connectivity through the NATs, or (c) a SIP call.
> >>> I
> >>> doubled the lines for the overlay topology, but left the SIP calls in
> >>> and
> >>> don't like the result. If people agree, I can do ASCII art for (a) and
> >>> (c),
> >>> as two figures.
> >> That might work.
> >
> > I ended up with three pictures - one with a reference architecture, one with
> > a SIP routed INCITE, and one with a SIP redirected INVITE.
> >
> > I also did some cleanup with box corners and using "#" to delimit the P2PSIP
> > Overlay, and labeled all the boxes unambiguously.
> >
> > Please let me know how to improve this. If it's worth including in the
> > draft, I'll write some descriptive text, starting with what's in the draft
> > now.
> >
> > --->PSTN
> > +---------+ /
> > +------+ |N| | Gateway |-/
> > | |########|A|########| Peer |##############
> > | UA | |T| | G | # Client Protocol
> > | Peer | +---------+ # GET/PUT
> > | C | # |
> > +------+ # | \__/
> > # # v / \
> > |NAT| #======/ UA \
> > # P2PSIP Overlay # /Client\
> > # # |___C__|
> > # Route Data #
> > +------+ +------+ #
> > | | |N| | | #
> > | UA |#|A|##| UA | #
> > | Peer | |T| | Peer | #
> > | D | | E | #
> > +------+ +------+ #
> > Peer Protocol # +-------+ +-------+ #
> > # | | | | #
> > ####| Proxy |########| Redir |####
> > | Peer | | Peer |
> > | P | | R |
> > +-------+ +-------+
> >
> >
> > \__/ \__/
> > /\ /\
> > / \ / \
> > / UA \ / UA \
> > /______\ /______\
> > SIP UA A SIP UA B
> >
> > Figure: P2PSIP Overlay Reference Model
> >
> > What I was trying to show in this figure was that the UA Client C is aware
> > of the P2PSIP overlay, while the SIP UAs A and B are not.
>
> A Client node should send its GET/PUT requests to a Peer (or Peers). In
> other words, the Client Protocol is spoken between a Client and a Peer.
> In that sense, I guess it would be better if the line from UA Client C
> is connected to one of Peers. What do you think?
Agree
> > In the following picture, I'm showing normal SIP signaling through from SIP
> > UA A to UA Peer E, through Proxy Peer C.
> >
> > --->PSTN
> > +---------+ /
> > +------+ |N| | Gateway |-/
> > | |########|A|########| Peer |##############
> > | UA | |T| | G | # Client Protocol
> > | Peer | +---------+ # GET/PUT
> > | C | # |
> > +------+ # | \__/
> > # # v / \
> > |NAT| #======/ UA \
> > # P2PSIP Overlay # /Client\
> > # # |___C__|
> > # Route Data #
> > +------+ +------+ #
> > | | |N| | | #
> > | UA |#|A|##| UA |----- SIP #
> > | Peer | |T| | Peer | | INVITE/200 OK #
> > | D | | E | | #
> > +------+ +------+ | #
> > Peer Protocol # +-------+ +-------+ #
> > # | | | | #
> > ####| Proxy |########| Redir |####
> > | Peer | | Peer |
> > | P | | R |
> > +-------+ +-------+
> > /
> > /
> > \__/ / SIP INVITE/200 OK \__/
> > /\ / /\
> > / \/ / \
> > / UA \ / UA \
> > /______\ /______\
> > SIP UA A SIP UA B
> >
> > Figure: Proxied SIP call from SIP UA to P2PSIP UA through Peer Proxy
> >
> > In the following figure, I'm showing the SIP signaling for a call initiated
> > from outside the P2PSIP Overlay to a Client, with redirect from a Redirect
> > Server.
> >
> > --->PSTN
> > +---------+ /
> > +------+ |N| | Gateway |-/
> > | |########|A|########| Peer |##############
> > | UA | |T| | | # Client Protocol
> > | Peer | +---------+ # GET/PUT
> > | C | # |
> > +------+ # | \__/
> > # # v / \
> > |NAT| #======/ UA \
> > # P2PSIP Overlay # /Client\
> > # # |______|
> > # Route Data # ^
> > +------+ +------+ # |
> > | | |N| | | # |
> > | UA |#|A|##| UA | # |
> > | Peer | |T| | Peer | # |
> > | D | | E | # |
> > +------+ +------+ # SIP |
> > Peer Protocol # +-------+ +-------+ # INVITE/200 OK
> > # | | | | # |
> > ####| Proxy |########| Redir |#### |
> > | Peer | | Peer | |
> > | | | | |
> > +-------+ +-------+ |
> > \ |
> > SIP \ /
> > \__/ INVITE/302 Moved \ \__/ /
> > /\ \ /\ /
> > / \ \/ \/
> > / UA \ / UA \
> > /______\ /______\
> > SIP UA A SIP UA B
> >
> > Figure: Redirect from P2PSIP Overlay
> >
> > A little further into our discussion of the draft...
> >
> >>> - I'm very confused about how both clients and peers can be "endpoints".
> >>> For
> >>> one thing, I'm not sure how "endpoint-to-endpoint trust" works. I
> >>> suspect
> >>> that this is conflating P2P endpoints (peers) with SIP endpoints (either
> >>> a
> >>> UA-peer or a UA-client). If you guys understand this perfectly, please
> >>> keep
> >>> typing...
> >>>
> >> Peers are supersets of clients. Everything a client can do, a peer can
> >> do.
> >
> > I really like this sentence - if others agree, I'd like to see it in the
> > draft.
> >
> I agree.
One caveat to be a bit closer. The statement "all P2PSIP overlay peers
are P2PSIP overlay clients" is true. The statement "all P2PSIP overlay
peers are SIP UA clients" may not be. There could be adaptor nodes, as
described in draft-bryan-sipping-p2p-02. These could serve as P2PSIP
overlay peers, but would have no SIP endpoint functionality -- they
would only serve to adapt traditional SIP UA clients that are not
P2PSIP overlay client protocol aware so they can communicate with the
network.
> > I did have one question - the Client GET/PUT protocol will be unicast to a
> > specific P2PSIP overlay peer, won't it?
> I think so.
I think so too.
> How should the Client choose a
> > specific overlay peer?
>
> A Client can get information about some existing Peers from P2PSIP
> Overlay Bootstrap Server. The Client can keep the information and send
> the PUT/GET request to those Peers.
>
> Over the time, the Client may be able to find other Peers. We should
> make sure there is a mechanism for that. Otherwise, many Clients may be
> stuck with the same set of Peers that are known to the Bootstrap Server.
> One possible solution is to assign a Node ID to the Client as well and
> let the Client talk to the Peer whose Node ID is closest to the Client's
> Node ID. It works because the Client should be able to find a Peer whose
> Node ID is closest to the Client's Node ID from DHT.
Could be many mechanisms here. Configuration of known persistent peer,
broadcast to find peer, etc. One of the many reasons I am so keen on
using pure SIP for the client protocol is that if one bootstraping
peer is overloaded, it can simply 302 (or perhaps 301 if it wants this
requestor to keep using another peer) incoming requests off to a less
loaded peer. In my draft, the bootstrap peer basically does a first
level lookup and always offloads, keeping the load light on any peer
that might be serving as a bootstrap.
David
> Thanks.
>
> Eunsoo
>
> > _______________________________________________
> > p2p-sip mailing list
> > p2p-sip at cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
From hsinnrei at adobe.com Wed Sep 27 17:33:41 2006
From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Wed, 27 Sep 2006 14:33:41 -0700
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
In-Reply-To: <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com>
Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D2219A21C@namail5.corp.adobe.com>
David's comment should be included IMHO in future architecture
documents:
" One of the many reasons I am so keen on using pure SIP for the client
protocol is that if one bootstraping peer is overloaded, it can simply
302 (or perhaps 301 if it wants this requestor to keep using another
peer) incoming requests off to a less loaded peer. In my draft, the
bootstrap peer basically does a first level lookup and always offloads,
keeping the load light on any peer that might be serving as a
bootstrap."
Thanks, Henry
-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan
Sent: Wednesday, September 27, 2006 1:56 PM
To: Eunsoo Shim
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
Comments inline.
On 9/27/06, Eunsoo Shim wrote:
> Hi, Spencer,
>
> All the three diagrams look good.
> My comments are inline.
>
> Spencer Dawkins wrote:
> > Hi, Dean,
> >
> > Just following up on some ascii artwork, and some questions...
> >
> > Thanks,
> >
> > Spencer
> >
> >>> - Figure 1 seems confused on whether the UA/Peers behind the NATs
are
> >>> part
> >>> of the overlay or not - I think I can draw the lines more clearly
(shown
> >>> below), assuming that they ARE part of the overlay.
> >> No doubt. They're meant to be part of the overlay.
> >>
> >>> - Figure 1 is also trying to do more than you can do in ASCII art
(at
> >>> least
> >>> I think so) - the dotted lines either mean (a) logical
connectivity in
> >>> the
> >>> overlay, (b) physical connectivity through the NATs, or (c) a SIP
call.
> >>> I
> >>> doubled the lines for the overlay topology, but left the SIP calls
in
> >>> and
> >>> don't like the result. If people agree, I can do ASCII art for (a)
and
> >>> (c),
> >>> as two figures.
> >> That might work.
> >
> > I ended up with three pictures - one with a reference architecture,
one with
> > a SIP routed INCITE, and one with a SIP redirected INVITE.
> >
> > I also did some cleanup with box corners and using "#" to delimit
the P2PSIP
> > Overlay, and labeled all the boxes unambiguously.
> >
> > Please let me know how to improve this. If it's worth including in
the
> > draft, I'll write some descriptive text, starting with what's in the
draft
> > now.
> >
> > --->PSTN
> > +---------+ /
> > +------+ |N| | Gateway |-/
> > | |########|A|########| Peer |##############
> > | UA | |T| | G | # Client
Protocol
> > | Peer | +---------+ # GET/PUT
> > | C | # |
> > +------+ # | \__/
> > # # v / \
> > |NAT| #======/ UA \
> > # P2PSIP Overlay #
/Client\
> > # #
|___C__|
> > # Route Data #
> > +------+ +------+ #
> > | | |N| | | #
> > | UA |#|A|##| UA | #
> > | Peer | |T| | Peer | #
> > | D | | E | #
> > +------+ +------+ #
> > Peer Protocol # +-------+ +-------+ #
> > # | | | | #
> > ####| Proxy |########| Redir |####
> > | Peer | | Peer |
> > | P | | R |
> > +-------+ +-------+
> >
> >
> > \__/ \__/
> > /\ /\
> > / \ / \
> > / UA \ / UA \
> > /______\ /______\
> > SIP UA A SIP UA B
> >
> > Figure: P2PSIP Overlay Reference Model
> >
> > What I was trying to show in this figure was that the UA Client C is
aware
> > of the P2PSIP overlay, while the SIP UAs A and B are not.
>
> A Client node should send its GET/PUT requests to a Peer (or Peers).
In
> other words, the Client Protocol is spoken between a Client and a
Peer.
> In that sense, I guess it would be better if the line from UA Client C
> is connected to one of Peers. What do you think?
Agree
> > In the following picture, I'm showing normal SIP signaling through
from SIP
> > UA A to UA Peer E, through Proxy Peer C.
> >
> > --->PSTN
> > +---------+ /
> > +------+ |N| | Gateway |-/
> > | |########|A|########| Peer |##############
> > | UA | |T| | G | # Client
Protocol
> > | Peer | +---------+ # GET/PUT
> > | C | # |
> > +------+ # | \__/
> > # # v / \
> > |NAT| #======/ UA \
> > # P2PSIP Overlay #
/Client\
> > # #
|___C__|
> > # Route Data #
> > +------+ +------+ #
> > | | |N| | | #
> > | UA |#|A|##| UA |----- SIP #
> > | Peer | |T| | Peer | | INVITE/200 OK #
> > | D | | E | | #
> > +------+ +------+ | #
> > Peer Protocol # +-------+ +-------+ #
> > # | | | | #
> > ####| Proxy |########| Redir |####
> > | Peer | | Peer |
> > | P | | R |
> > +-------+ +-------+
> > /
> > /
> > \__/ / SIP INVITE/200 OK \__/
> > /\ / /\
> > / \/ / \
> > / UA \ / UA \
> > /______\ /______\
> > SIP UA A SIP UA B
> >
> > Figure: Proxied SIP call from SIP UA to P2PSIP UA through Peer
Proxy
> >
> > In the following figure, I'm showing the SIP signaling for a call
initiated
> > from outside the P2PSIP Overlay to a Client, with redirect from a
Redirect
> > Server.
> >
> > --->PSTN
> > +---------+ /
> > +------+ |N| | Gateway |-/
> > | |########|A|########| Peer |##############
> > | UA | |T| | | # Client
Protocol
> > | Peer | +---------+ # GET/PUT
> > | C | # |
> > +------+ # | \__/
> > # # v / \
> > |NAT| #======/ UA \
> > # P2PSIP Overlay #
/Client\
> > # #
|______|
> > # Route Data # ^
> > +------+ +------+ # |
> > | | |N| | | # |
> > | UA |#|A|##| UA | # |
> > | Peer | |T| | Peer | # |
> > | D | | E | # |
> > +------+ +------+ # SIP |
> > Peer Protocol # +-------+ +-------+ # INVITE/200
OK
> > # | | | | # |
> > ####| Proxy |########| Redir |#### |
> > | Peer | | Peer | |
> > | | | | |
> > +-------+ +-------+ |
> > \ |
> > SIP \ /
> > \__/ INVITE/302 Moved \ \__/ /
> > /\ \ /\ /
> > / \ \/ \/
> > / UA \ / UA \
> > /______\ /______\
> > SIP UA A SIP UA B
> >
> > Figure: Redirect from P2PSIP Overlay
> >
> > A little further into our discussion of the draft...
> >
> >>> - I'm very confused about how both clients and peers can be
"endpoints".
> >>> For
> >>> one thing, I'm not sure how "endpoint-to-endpoint trust" works. I
> >>> suspect
> >>> that this is conflating P2P endpoints (peers) with SIP endpoints
(either
> >>> a
> >>> UA-peer or a UA-client). If you guys understand this perfectly,
please
> >>> keep
> >>> typing...
> >>>
> >> Peers are supersets of clients. Everything a client can do, a peer
can
> >> do.
> >
> > I really like this sentence - if others agree, I'd like to see it in
the
> > draft.
> >
> I agree.
One caveat to be a bit closer. The statement "all P2PSIP overlay peers
are P2PSIP overlay clients" is true. The statement "all P2PSIP overlay
peers are SIP UA clients" may not be. There could be adaptor nodes, as
described in draft-bryan-sipping-p2p-02. These could serve as P2PSIP
overlay peers, but would have no SIP endpoint functionality -- they
would only serve to adapt traditional SIP UA clients that are not
P2PSIP overlay client protocol aware so they can communicate with the
network.
> > I did have one question - the Client GET/PUT protocol will be
unicast to a
> > specific P2PSIP overlay peer, won't it?
> I think so.
I think so too.
> How should the Client choose a
> > specific overlay peer?
>
> A Client can get information about some existing Peers from P2PSIP
> Overlay Bootstrap Server. The Client can keep the information and send
> the PUT/GET request to those Peers.
>
> Over the time, the Client may be able to find other Peers. We should
> make sure there is a mechanism for that. Otherwise, many Clients may
be
> stuck with the same set of Peers that are known to the Bootstrap
Server.
> One possible solution is to assign a Node ID to the Client as well and
> let the Client talk to the Peer whose Node ID is closest to the
Client's
> Node ID. It works because the Client should be able to find a Peer
whose
> Node ID is closest to the Client's Node ID from DHT.
Could be many mechanisms here. Configuration of known persistent peer,
broadcast to find peer, etc. One of the many reasons I am so keen on
using pure SIP for the client protocol is that if one bootstraping
peer is overloaded, it can simply 302 (or perhaps 301 if it wants this
requestor to keep using another peer) incoming requests off to a less
loaded peer. In my draft, the bootstrap peer basically does a first
level lookup and always offloads, keeping the load light on any peer
that might be serving as a bootstrap.
David
> Thanks.
>
> Eunsoo
>
> > _______________________________________________
> > p2p-sip mailing list
> > p2p-sip at cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
_______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
From spencer at mcsr-labs.org Wed Sep 27 17:34:16 2006
From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Wed, 27 Sep 2006 16:34:16 -0500
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com>
<85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com>
<080601c6e26f$32492720$0300a8c0@china.huawei.com>
<451ADD5F.6010206@research.panasonic.com>
<8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com>
Message-ID: <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com>
Thanks, both Eunsoo and David, for quick feedback.
>> > What I was trying to show in this figure was that the UA Client C is
>> > aware
>> > of the P2PSIP overlay, while the SIP UAs A and B are not.
>>
>> A Client node should send its GET/PUT requests to a Peer (or Peers). In
>> other words, the Client Protocol is spoken between a Client and a Peer.
>> In that sense, I guess it would be better if the line from UA Client C
>> is connected to one of Peers. What do you think?
>
> Agree
Cool. Should I just show the Peer as "Peer F", or is there a better term? I
think I'm asking if I should include David's term "adaptor node" in the
diagram.
>> >> Peers are supersets of clients. Everything a client can do, a peer
>> >> can
>> >> do.
>> >
>> > I really like this sentence - if others agree, I'd like to see it in
>> > the
>> > draft.
>> >
>> I agree.
>
> One caveat to be a bit closer. The statement "all P2PSIP overlay peers
> are P2PSIP overlay clients" is true. The statement "all P2PSIP overlay
> peers are SIP UA clients" may not be. There could be adaptor nodes, as
> described in draft-bryan-sipping-p2p-02. These could serve as P2PSIP
> overlay peers, but would have no SIP endpoint functionality -- they
> would only serve to adapt traditional SIP UA clients that are not
> P2PSIP overlay client protocol aware so they can communicate with the
> network.
Thanks for this clarification. It also helps.
>
>> How should the Client choose a
>> > specific overlay peer?
>>
>> A Client can get information about some existing Peers from P2PSIP
>> Overlay Bootstrap Server. The Client can keep the information and send
>> the PUT/GET request to those Peers.
>>
>> Over the time, the Client may be able to find other Peers. We should
>> make sure there is a mechanism for that. Otherwise, many Clients may be
>> stuck with the same set of Peers that are known to the Bootstrap Server.
>> One possible solution is to assign a Node ID to the Client as well and
>> let the Client talk to the Peer whose Node ID is closest to the Client's
>> Node ID. It works because the Client should be able to find a Peer whose
>> Node ID is closest to the Client's Node ID from DHT.
>
> Could be many mechanisms here. Configuration of known persistent peer,
> broadcast to find peer, etc. One of the many reasons I am so keen on
> using pure SIP for the client protocol is that if one bootstraping
> peer is overloaded, it can simply 302 (or perhaps 301 if it wants this
> requestor to keep using another peer) incoming requests off to a less
> loaded peer. In my draft, the bootstrap peer basically does a first
> level lookup and always offloads, keeping the load light on any peer
> that might be serving as a bootstrap.
Again, thanks for the clarification.
Spencer
From bryan at ethernot.org Wed Sep 27 18:45:43 2006
From: bryan at ethernot.org (David A. Bryan)
Date: Wed, 27 Sep 2006 18:45:43 -0400
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
In-Reply-To: <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com>
References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com>
<85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com>
<080601c6e26f$32492720$0300a8c0@china.huawei.com>
<451ADD5F.6010206@research.panasonic.com>
<8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com>
<09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com>
Message-ID: <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com>
I don't believe that adaptor node made it into the terminology draft,
but I'm fine with using it as a label if others are comfortable. (it
just never happened to come up in that discussion).
David
On 9/27/06, Spencer Dawkins wrote:
> Thanks, both Eunsoo and David, for quick feedback.
>
> >> > What I was trying to show in this figure was that the UA Client C is
> >> > aware
> >> > of the P2PSIP overlay, while the SIP UAs A and B are not.
> >>
> >> A Client node should send its GET/PUT requests to a Peer (or Peers). In
> >> other words, the Client Protocol is spoken between a Client and a Peer.
> >> In that sense, I guess it would be better if the line from UA Client C
> >> is connected to one of Peers. What do you think?
> >
> > Agree
>
> Cool. Should I just show the Peer as "Peer F", or is there a better term? I
> think I'm asking if I should include David's term "adaptor node" in the
> diagram.
>
> >> >> Peers are supersets of clients. Everything a client can do, a peer
> >> >> can
> >> >> do.
> >> >
> >> > I really like this sentence - if others agree, I'd like to see it in
> >> > the
> >> > draft.
> >> >
> >> I agree.
> >
> > One caveat to be a bit closer. The statement "all P2PSIP overlay peers
> > are P2PSIP overlay clients" is true. The statement "all P2PSIP overlay
> > peers are SIP UA clients" may not be. There could be adaptor nodes, as
> > described in draft-bryan-sipping-p2p-02. These could serve as P2PSIP
> > overlay peers, but would have no SIP endpoint functionality -- they
> > would only serve to adapt traditional SIP UA clients that are not
> > P2PSIP overlay client protocol aware so they can communicate with the
> > network.
>
> Thanks for this clarification. It also helps.
>
> >
> >> How should the Client choose a
> >> > specific overlay peer?
> >>
> >> A Client can get information about some existing Peers from P2PSIP
> >> Overlay Bootstrap Server. The Client can keep the information and send
> >> the PUT/GET request to those Peers.
> >>
> >> Over the time, the Client may be able to find other Peers. We should
> >> make sure there is a mechanism for that. Otherwise, many Clients may be
> >> stuck with the same set of Peers that are known to the Bootstrap Server.
> >> One possible solution is to assign a Node ID to the Client as well and
> >> let the Client talk to the Peer whose Node ID is closest to the Client's
> >> Node ID. It works because the Client should be able to find a Peer whose
> >> Node ID is closest to the Client's Node ID from DHT.
> >
> > Could be many mechanisms here. Configuration of known persistent peer,
> > broadcast to find peer, etc. One of the many reasons I am so keen on
> > using pure SIP for the client protocol is that if one bootstraping
> > peer is overloaded, it can simply 302 (or perhaps 301 if it wants this
> > requestor to keep using another peer) incoming requests off to a less
> > loaded peer. In my draft, the bootstrap peer basically does a first
> > level lookup and always offloads, keeping the load light on any peer
> > that might be serving as a bootstrap.
>
> Again, thanks for the clarification.
>
> Spencer
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
From hsinnrei at adobe.com Wed Sep 27 19:09:54 2006
From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Wed, 27 Sep 2006 16:09:54 -0700
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01 - MORE
In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D2219A21C@namail5.corp.adobe.com>
Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D2219A26E@namail5.corp.adobe.com>
Ooops!
What I meant to say: What are the alternative options for load balancing
to avoid overloaded peers?
Sorry, I did not mean to support SIP as a peer client protocol. This
choice has yet to be made after we look at the requirements, options,
etc.
Thanks, Henry
-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Henry Sinnreich
Sent: Wednesday, September 27, 2006 2:34 PM
To: David A. Bryan; Eunsoo Shim
Cc: p2p-sip at cs.columbia.edu; Kundan Singh
Subject: Re: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
David's comment should be included IMHO in future architecture
documents:
" One of the many reasons I am so keen on using pure SIP for the client
protocol is that if one bootstraping peer is overloaded, it can simply
302 (or perhaps 301 if it wants this requestor to keep using another
peer) incoming requests off to a less loaded peer. In my draft, the
bootstrap peer basically does a first level lookup and always offloads,
keeping the load light on any peer that might be serving as a
bootstrap."
Thanks, Henry
-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan
Sent: Wednesday, September 27, 2006 1:56 PM
To: Eunsoo Shim
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
Comments inline.
On 9/27/06, Eunsoo Shim wrote:
> Hi, Spencer,
>
> All the three diagrams look good.
> My comments are inline.
>
> Spencer Dawkins wrote:
> > Hi, Dean,
> >
> > Just following up on some ascii artwork, and some questions...
> >
> > Thanks,
> >
> > Spencer
> >
> >>> - Figure 1 seems confused on whether the UA/Peers behind the NATs
are
> >>> part
> >>> of the overlay or not - I think I can draw the lines more clearly
(shown
> >>> below), assuming that they ARE part of the overlay.
> >> No doubt. They're meant to be part of the overlay.
> >>
> >>> - Figure 1 is also trying to do more than you can do in ASCII art
(at
> >>> least
> >>> I think so) - the dotted lines either mean (a) logical
connectivity in
> >>> the
> >>> overlay, (b) physical connectivity through the NATs, or (c) a SIP
call.
> >>> I
> >>> doubled the lines for the overlay topology, but left the SIP calls
in
> >>> and
> >>> don't like the result. If people agree, I can do ASCII art for (a)
and
> >>> (c),
> >>> as two figures.
> >> That might work.
> >
> > I ended up with three pictures - one with a reference architecture,
one with
> > a SIP routed INCITE, and one with a SIP redirected INVITE.
> >
> > I also did some cleanup with box corners and using "#" to delimit
the P2PSIP
> > Overlay, and labeled all the boxes unambiguously.
> >
> > Please let me know how to improve this. If it's worth including in
the
> > draft, I'll write some descriptive text, starting with what's in the
draft
> > now.
> >
> > --->PSTN
> > +---------+ /
> > +------+ |N| | Gateway |-/
> > | |########|A|########| Peer |##############
> > | UA | |T| | G | # Client
Protocol
> > | Peer | +---------+ # GET/PUT
> > | C | # |
> > +------+ # | \__/
> > # # v / \
> > |NAT| #======/ UA \
> > # P2PSIP Overlay #
/Client\
> > # #
|___C__|
> > # Route Data #
> > +------+ +------+ #
> > | | |N| | | #
> > | UA |#|A|##| UA | #
> > | Peer | |T| | Peer | #
> > | D | | E | #
> > +------+ +------+ #
> > Peer Protocol # +-------+ +-------+ #
> > # | | | | #
> > ####| Proxy |########| Redir |####
> > | Peer | | Peer |
> > | P | | R |
> > +-------+ +-------+
> >
> >
> > \__/ \__/
> > /\ /\
> > / \ / \
> > / UA \ / UA \
> > /______\ /______\
> > SIP UA A SIP UA B
> >
> > Figure: P2PSIP Overlay Reference Model
> >
> > What I was trying to show in this figure was that the UA Client C is
aware
> > of the P2PSIP overlay, while the SIP UAs A and B are not.
>
> A Client node should send its GET/PUT requests to a Peer (or Peers).
In
> other words, the Client Protocol is spoken between a Client and a
Peer.
> In that sense, I guess it would be better if the line from UA Client C
> is connected to one of Peers. What do you think?
Agree
> > In the following picture, I'm showing normal SIP signaling through
from SIP
> > UA A to UA Peer E, through Proxy Peer C.
> >
> > --->PSTN
> > +---------+ /
> > +------+ |N| | Gateway |-/
> > | |########|A|########| Peer |##############
> > | UA | |T| | G | # Client
Protocol
> > | Peer | +---------+ # GET/PUT
> > | C | # |
> > +------+ # | \__/
> > # # v / \
> > |NAT| #======/ UA \
> > # P2PSIP Overlay #
/Client\
> > # #
|___C__|
> > # Route Data #
> > +------+ +------+ #
> > | | |N| | | #
> > | UA |#|A|##| UA |----- SIP #
> > | Peer | |T| | Peer | | INVITE/200 OK #
> > | D | | E | | #
> > +------+ +------+ | #
> > Peer Protocol # +-------+ +-------+ #
> > # | | | | #
> > ####| Proxy |########| Redir |####
> > | Peer | | Peer |
> > | P | | R |
> > +-------+ +-------+
> > /
> > /
> > \__/ / SIP INVITE/200 OK \__/
> > /\ / /\
> > / \/ / \
> > / UA \ / UA \
> > /______\ /______\
> > SIP UA A SIP UA B
> >
> > Figure: Proxied SIP call from SIP UA to P2PSIP UA through Peer
Proxy
> >
> > In the following figure, I'm showing the SIP signaling for a call
initiated
> > from outside the P2PSIP Overlay to a Client, with redirect from a
Redirect
> > Server.
> >
> > --->PSTN
> > +---------+ /
> > +------+ |N| | Gateway |-/
> > | |########|A|########| Peer |##############
> > | UA | |T| | | # Client
Protocol
> > | Peer | +---------+ # GET/PUT
> > | C | # |
> > +------+ # | \__/
> > # # v / \
> > |NAT| #======/ UA \
> > # P2PSIP Overlay #
/Client\
> > # #
|______|
> > # Route Data # ^
> > +------+ +------+ # |
> > | | |N| | | # |
> > | UA |#|A|##| UA | # |
> > | Peer | |T| | Peer | # |
> > | D | | E | # |
> > +------+ +------+ # SIP |
> > Peer Protocol # +-------+ +-------+ # INVITE/200
OK
> > # | | | | # |
> > ####| Proxy |########| Redir |#### |
> > | Peer | | Peer | |
> > | | | | |
> > +-------+ +-------+ |
> > \ |
> > SIP \ /
> > \__/ INVITE/302 Moved \ \__/ /
> > /\ \ /\ /
> > / \ \/ \/
> > / UA \ / UA \
> > /______\ /______\
> > SIP UA A SIP UA B
> >
> > Figure: Redirect from P2PSIP Overlay
> >
> > A little further into our discussion of the draft...
> >
> >>> - I'm very confused about how both clients and peers can be
"endpoints".
> >>> For
> >>> one thing, I'm not sure how "endpoint-to-endpoint trust" works. I
> >>> suspect
> >>> that this is conflating P2P endpoints (peers) with SIP endpoints
(either
> >>> a
> >>> UA-peer or a UA-client). If you guys understand this perfectly,
please
> >>> keep
> >>> typing...
> >>>
> >> Peers are supersets of clients. Everything a client can do, a peer
can
> >> do.
> >
> > I really like this sentence - if others agree, I'd like to see it in
the
> > draft.
> >
> I agree.
One caveat to be a bit closer. The statement "all P2PSIP overlay peers
are P2PSIP overlay clients" is true. The statement "all P2PSIP overlay
peers are SIP UA clients" may not be. There could be adaptor nodes, as
described in draft-bryan-sipping-p2p-02. These could serve as P2PSIP
overlay peers, but would have no SIP endpoint functionality -- they
would only serve to adapt traditional SIP UA clients that are not
P2PSIP overlay client protocol aware so they can communicate with the
network.
> > I did have one question - the Client GET/PUT protocol will be
unicast to a
> > specific P2PSIP overlay peer, won't it?
> I think so.
I think so too.
> How should the Client choose a
> > specific overlay peer?
>
> A Client can get information about some existing Peers from P2PSIP
> Overlay Bootstrap Server. The Client can keep the information and send
> the PUT/GET request to those Peers.
>
> Over the time, the Client may be able to find other Peers. We should
> make sure there is a mechanism for that. Otherwise, many Clients may
be
> stuck with the same set of Peers that are known to the Bootstrap
Server.
> One possible solution is to assign a Node ID to the Client as well and
> let the Client talk to the Peer whose Node ID is closest to the
Client's
> Node ID. It works because the Client should be able to find a Peer
whose
> Node ID is closest to the Client's Node ID from DHT.
Could be many mechanisms here. Configuration of known persistent peer,
broadcast to find peer, etc. One of the many reasons I am so keen on
using pure SIP for the client protocol is that if one bootstraping
peer is overloaded, it can simply 302 (or perhaps 301 if it wants this
requestor to keep using another peer) incoming requests off to a less
loaded peer. In my draft, the bootstrap peer basically does a first
level lookup and always offloads, keeping the load light on any peer
that might be serving as a bootstrap.
David
> Thanks.
>
> Eunsoo
>
> > _______________________________________________
> > p2p-sip mailing list
> > p2p-sip at cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
_______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
_______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
From eunsoo at research.panasonic.com Wed Sep 27 23:55:48 2006
From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Wed, 27 Sep 2006 23:55:48 -0400
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
In-Reply-To: <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com>
References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com>
<8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com>
Message-ID: <451B47C4.5070000@research.panasonic.com>
Doesn't the Proxy Peer do a similar function?
We have Proxy Peer in the diagram(s).
Thanks.
Eunsoo
David A. Bryan wrote:
>I don't believe that adaptor node made it into the terminology draft,
>but I'm fine with using it as a label if others are comfortable. (it
>just never happened to come up in that discussion).
>
>David
>
>On 9/27/06, Spencer Dawkins wrote:
>
>
>>Thanks, both Eunsoo and David, for quick feedback.
>>
>>
>>
>>>>>What I was trying to show in this figure was that the UA Client C is
>>>>>aware
>>>>>of the P2PSIP overlay, while the SIP UAs A and B are not.
>>>>>
>>>>>
>>>>A Client node should send its GET/PUT requests to a Peer (or Peers). In
>>>>other words, the Client Protocol is spoken between a Client and a Peer.
>>>>In that sense, I guess it would be better if the line from UA Client C
>>>>is connected to one of Peers. What do you think?
>>>>
>>>>
>>>Agree
>>>
>>>
>>Cool. Should I just show the Peer as "Peer F", or is there a better term? I
>>think I'm asking if I should include David's term "adaptor node" in the
>>diagram.
>>
>>
>>
>>>>>>Peers are supersets of clients. Everything a client can do, a peer
>>>>>>can
>>>>>>do.
>>>>>>
>>>>>>
>>>>>I really like this sentence - if others agree, I'd like to see it in
>>>>>the
>>>>>draft.
>>>>>
>>>>>
>>>>>
>>>>I agree.
>>>>
>>>>
>>>One caveat to be a bit closer. The statement "all P2PSIP overlay peers
>>>are P2PSIP overlay clients" is true. The statement "all P2PSIP overlay
>>>peers are SIP UA clients" may not be. There could be adaptor nodes, as
>>>described in draft-bryan-sipping-p2p-02. These could serve as P2PSIP
>>>overlay peers, but would have no SIP endpoint functionality -- they
>>>would only serve to adapt traditional SIP UA clients that are not
>>>P2PSIP overlay client protocol aware so they can communicate with the
>>>network.
>>>
>>>
>>Thanks for this clarification. It also helps.
>>
>>
>>
>>>>How should the Client choose a
>>>>
>>>>
>>>>>specific overlay peer?
>>>>>
>>>>>
>>>>A Client can get information about some existing Peers from P2PSIP
>>>>Overlay Bootstrap Server. The Client can keep the information and send
>>>>the PUT/GET request to those Peers.
>>>>
>>>>Over the time, the Client may be able to find other Peers. We should
>>>>make sure there is a mechanism for that. Otherwise, many Clients may be
>>>>stuck with the same set of Peers that are known to the Bootstrap Server.
>>>>One possible solution is to assign a Node ID to the Client as well and
>>>>let the Client talk to the Peer whose Node ID is closest to the Client's
>>>>Node ID. It works because the Client should be able to find a Peer whose
>>>>Node ID is closest to the Client's Node ID from DHT.
>>>>
>>>>
>>>Could be many mechanisms here. Configuration of known persistent peer,
>>>broadcast to find peer, etc. One of the many reasons I am so keen on
>>>using pure SIP for the client protocol is that if one bootstraping
>>>peer is overloaded, it can simply 302 (or perhaps 301 if it wants this
>>>requestor to keep using another peer) incoming requests off to a less
>>>loaded peer. In my draft, the bootstrap peer basically does a first
>>>level lookup and always offloads, keeping the load light on any peer
>>>that might be serving as a bootstrap.
>>>
>>>
>>Again, thanks for the clarification.
>>
>>Spencer
>>
>>_______________________________________________
>>p2p-sip mailing list
>>p2p-sip at cs.columbia.edu
>>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>>
>>
>>
>_______________________________________________
>p2p-sip mailing list
>p2p-sip at cs.columbia.edu
>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
>
From tutschku at informatik.uni-wuerzburg.de Thu Sep 28 03:40:17 2006
From: tutschku at informatik.uni-wuerzburg.de (Kurt Tutschku)
Date: Thu, 28 Sep 2006 09:40:17 +0200
Subject: [p2p-sip] CfP: MobileP2P'07 - Deadline Extension
Message-ID: <001401c6e2d1$5806f110$6402a8c0@Musa>
---------------------------------------------------------------------
This Message has to be resend to transmission problem
---------------------------------------------------------------------
Deadline extension: Oct. 13, 2006
---------------------------------------------------------------------
Call-for-Paper
---------------------------------------------------------------------
4th IEEE International Workshop on Mobile Peer-to-Peer Computing (MP2P'07)
http://www-info3.informatik.uni-wuerzburg.de/mp2p2007
White Plains, NY, USA, March 19-23, 2007
In conjunction with the 5th IEEE International Conference on Pervasive
Computing and Communications (PerCom07) http://www.percom.org/
----------------------------------------------------------------------
Peer-to-Peer (P2P) computing is a networking and distributed computing
paradigm which allows the sharing of computing resources and services by
direct, symmetric interaction between computers. The advance in mobile
wireless communication technology and the increasing number of mobile users,
extend the arena of P2P computing to encompass mobile devices and wireless
networks. The special characteristics of mobile environments, such as
highly variable connectivity, disconnection, location-dependency, resource
contraints, and diversity in wireless networks as well as carrier-grade
performance requirements bring new challenges for research in mobile P2P
computing.
Based on the success of its three predecessors, MP2P?07 is intended to serve
as a continuing forum for scientists and engineers in academia and industry
to exchange and discuss their experiences, new ideas, and research results
about all aspects of mobile P2P computing.
It will address the challenges, technologies, and architectures leading to
real-world solutions that provide users with direct access and control of
their critical peer-based information and services, regardless of location
or device. The principal theme of MP2P?07 is the development of protocols,
systems and applications of mobile P2P architectures and the evaluation of
their performance.
Topics of particular interest include, but are not limited to:
- Architecture and platforms for mobile P2P computing
- Measurement studies on mobile P2P systems
- Performance of mobile P2P services
- Resource and service discovery in mobile P2P computing
- Resource exchange mechanisms in mobile P2P application
- Multicast Protocols in mobile networks
- Energy saving P2P protocols for mobile devices
- Mobile P2P in wirelesss sensor networks
- Security in mobile P2P networks
- Mobile P2P over different kinds of bearer services: 2.5/3G (GPRS/UMTS) /
802.11 (WLAN)
- Mobile P2P & operator/provider requirements
- Reliability and carrier-gradeness of mobile P2P services
- Mobile P2P SIP
- Mobile P2P & fixed P2P system interworking
- Issues of combining P2P services with mobility (mobile IP / MANET)
- Peer access and control in mobile environment
- Location dependent mobile P2P services
- Data exchange and rendering techniques for mobile devices
- Secure communication protocols for mobile P2P computing
- Mobile P2P messaging systems
- Peer-to-peer broadband wireless communications
- Applications of mobile P2P
- Middleware for mobile P2P
- Nature-inspired algorithms for mobile P2P computing
- Theoretical issues on mobile information diffusion
- Mobile P2P video games
- Stimulating cooperation in mobile computing
- Multicast Protocols in mobile networks
- Energy saving P2P protocols for mobile devices
- Mobile P2P in wirelesss sensor networks
Paper Submission:
-----------------
Papers must be written in English and should not exceed 5 pages in IEEE
proceedings style. All submissions must describe original research, not
published nor currently under review for another conference or journal.
Authors MUST submit their papers through the PERDAS web site
(http://www.percom.org/perdas) in three steps:
* Creation of a personal account on PERDAS (if the author does not already
have one)
* Registration of the paper (requiring a short abstract of up to 150 words)
* Upload of the paper. Only in pdf format
Submission implies the willingness of at least one of the authors to
register and present the paper.
There is only one registration for the whole PerCom "convention", all
workshops included. The only exception from the full-registration rule is:
an author can register for her/his paper with a student registration if i)
(s)he is a student AND ii) on of her/his co-authors has a full registration
with PerCom.
All submissions will be reviewed and selected based on their originality of
the paper. Accepted papers must be presented at the workshop and will appear
in a combined PerCom 2007 workshop proceedings published by IEEE Computer
Society Press.
Authors that present a system in their paper are highly encouraged to
demonstrate also the system in the demo session of the workshop.
Important Dates:
----------------
Papers due: 5pm EST, October 13, 2006
(NEW)
Notification of acceptance November 25, 2006
Camera-ready papers due to IEEE December 22, 2006
Organizing Committee, Program Co-chairs:
----------------------------------------
Kurt Tutschku, Department of Distributed Systems, University of W?rzburg,
Germany.
John Buford, Panasonic Princeton Laboratory, USA.
Li Li, Communications Research Center Canada, Canada.
Steering Board:
---------------
- Jiannong Cao, Department of Computing, Hong Kong Polytechnic University.
- Y. Charlie Hu, School of Electrical and Computer Engineering, Purdue
University.
- Cecilia Mascolo, Department of Computer Science, University College
London.
- Maria Papadopouli, Department of Computer Science, University of North
Carolina at Chapel Hill.
- Frank-Uwe Andersen, Siemens Communications, Germany.
Publicity Chair:
----------------
Kurt Tutschku, Department of Distributed Systems, University of W?rzburg,
Germany
Program Committee Members:
--------------------------
- Arup Acharya, IBM Watson Research Lab, USA.
- Frank-Uwe Andersen, Siemens Communications, Germany.
- Jiannong Cao, Hong Kong Polytechnic University, Hong Kong.
- Geoff Coulson, Lancaster University, Lancaster, UK.
- Hermann de Meer, Department of Computer Networks & Computer
Communications, University of Passau, Germany.
- Franca Delmastro, CNR-IIT ,Pisa, Italy.
- Krishna Dhara, Avaya Labs Research.
- Babak Esfandiari, Carleton University, Canada.
- Stephen Hailes, Department of Computer Science, University College of
London, UK.
- Felix Hernandez-Campos, Department of Computer Science, University of
North Carolina at Chapel Hill, USA.
- Y. Charlie Hu, School of Electrical and Computer Engineering, Purdue
University, USA.
- Norihiro Ishikawa, NTT Docomo, Japan.
- Valerie Issarny, INRIA, France.
- Wolfgang Kellerer, DoCoMo Communications Laboratories Europe, Germany.
- Kazuhiro Kitagawa, Keio University, Japan.
- Rajeev Koodli, Nokia Research, USA.
- Thomas Kunz, Dept. of Systems and Comp. Engineering, Carleton University,
Canada.
- Li Li, Communications Research Center Canada, , Canada.
- Christoph Lindemann, Depart. of Communication Networks and Distributed
Systems, University of Leipzig, Germany.
- Vishal Misra, Dept. of Computer Science, Columbia University, New York,
USA.
- Maria Papadopouli, Department of Computer Science, University of North
Carolina at Chapel Hill , USA.
- Rudolf Riedi, Department of Statistics, Rice University , USA.
- George Roussos, School of Computer Science and Information Systems -
Birkbeck College, University of London, UK.
- Jochen Schiller, Institute of Computer Science, FU Berlin, Germany.
- Hans-Peter Schwefel, Department of Communication Technology, Aalborg
University, Denmark.
- Shervin Shirmohammadi, School of Information Technology and Engineering
(SITE), University of Ottawa, Canada.
- Apostolos Traganitis, Telecommunications and Networks
Laboratory,University of Crete, Greece.
- Kurt Tutschku, Department of Distributed Systems, University of W?rzburg,
Germany.
- Klaus Wehrle, Distributed Systems Group, RWTH Aachen, Germany.
- Chansu Yu, Department of Electrical and Computer Engineering, Cleveland
State University, USA.
---
Dr. Kurt Tutschku, Assistant Professor
University of Wuerzburg
Department of Distributed Systems
Institute of Computer Science
Am Hubland
97074 Wuerzburg
Germany
Tel.: +49-931-8886641
FAX.: +49-931-8886632
mailto:tutschku at informatik.uni-wuerzburg.de
or
mailto:kurttutschku at hotmail.com
http://www-info3.informatik.uni-wuerzburg.de/staff/tutschku
From spencer at mcsr-labs.org Thu Sep 28 08:41:06 2006
From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 28 Sep 2006 07:41:06 -0500
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com>
<8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com>
<451B47C4.5070000@research.panasonic.com>
Message-ID: <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com>
... I'm still working on precision here ...
I may have misunderstood this point in the original draft, but I thought the
Proxy Peer was a *SIP* Proxy Peer - roughly, providing what I called
"Interaction with CS-SIP" in http://www.p2psip.org/P2PUseCases.php.
But, looking back at draft-willis-p2psip-concepts-01 more closely, I find
6. Proxy: A peer or client that accepts SIP requests, resolves the
next hop or hops using the routing information of the P2PSIP
Overlay, and passes the request on towards the next hop.
If the Proxy Peer is a *P2PSIP* Proxy Peer, that's fine - but what should I
call the node providing "Interaction with CS-SIP"?
Thanks,
Spencer
> Doesn't the Proxy Peer do a similar function?
> We have Proxy Peer in the diagram(s).
> Thanks.
>
> Eunsoo
>
> David A. Bryan wrote:
>
>>I don't believe that adaptor node made it into the terminology draft,
>>but I'm fine with using it as a label if others are comfortable. (it
>>just never happened to come up in that discussion).
>>
>>David
From bryan at ethernot.org Thu Sep 28 09:17:03 2006
From: bryan at ethernot.org (David A. Bryan)
Date: Thu, 28 Sep 2006 09:17:03 -0400
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
In-Reply-To: <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com>
References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com>
<85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com>
<080601c6e26f$32492720$0300a8c0@china.huawei.com>
<451ADD5F.6010206@research.panasonic.com>
<8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com>
<09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com>
<8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com>
<451B47C4.5070000@research.panasonic.com>
<0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com>
Message-ID: <8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com>
I was thinking that an adaptor might be an entity that had more than
just proxy -- we also specify a registrar in that same section. For a
true C/S node to work, it would need to be able to do lookups and
registration.
We need to make some clarifications to the terminology draft.
David
On 9/28/06, Spencer Dawkins wrote:
> ... I'm still working on precision here ...
>
> I may have misunderstood this point in the original draft, but I thought the
> Proxy Peer was a *SIP* Proxy Peer - roughly, providing what I called
> "Interaction with CS-SIP" in http://www.p2psip.org/P2PUseCases.php.
>
> But, looking back at draft-willis-p2psip-concepts-01 more closely, I find
>
> 6. Proxy: A peer or client that accepts SIP requests, resolves the
> next hop or hops using the routing information of the P2PSIP
> Overlay, and passes the request on towards the next hop.
>
> If the Proxy Peer is a *P2PSIP* Proxy Peer, that's fine - but what should I
> call the node providing "Interaction with CS-SIP"?
>
> Thanks,
>
> Spencer
>
>
> > Doesn't the Proxy Peer do a similar function?
> > We have Proxy Peer in the diagram(s).
> > Thanks.
> >
> > Eunsoo
> >
> > David A. Bryan wrote:
> >
> >>I don't believe that adaptor node made it into the terminology draft,
> >>but I'm fine with using it as a label if others are comfortable. (it
> >>just never happened to come up in that discussion).
> >>
> >>David
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
From eunsoo at research.panasonic.com Thu Sep 28 10:25:01 2006
From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 28 Sep 2006 10:25:01 -0400
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
In-Reply-To: <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com>
References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com> <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com> <451B47C4.5070000@research.panasonic.com>
<0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com>
Message-ID: <451BDB3D.4040602@research.panasonic.com>
>From the SIP perspective, Proxy does the same thing about SIP message
routing regardless of whether it uses the P2PSIP Overlay to resolve the
IP address of the next hop or uses the DNS. The next hope could be
another proxy or the destination.
Proxy Peer is nothing but a SIP Proxy that is a Peer and thus can use
the P2PSIP Overlay to find the location of the destination (or the next
hop).
As written in the terminology and concepts draft, there can be a Proxy
Client.
Therefore, Proxy Peer and Proxy Client can always interact with CS-SIP
in my understanding.
Thanks.
Eunsoo
Spencer Dawkins wrote:
> ... I'm still working on precision here ...
>
> I may have misunderstood this point in the original draft, but I thought the
> Proxy Peer was a *SIP* Proxy Peer - roughly, providing what I called
> "Interaction with CS-SIP" in http://www.p2psip.org/P2PUseCases.php.
>
> But, looking back at draft-willis-p2psip-concepts-01 more closely, I find
>
> 6. Proxy: A peer or client that accepts SIP requests, resolves the
> next hop or hops using the routing information of the P2PSIP
> Overlay, and passes the request on towards the next hop.
>
> If the Proxy Peer is a *P2PSIP* Proxy Peer, that's fine - but what should I
> call the node providing "Interaction with CS-SIP"?
>
> Thanks,
>
> Spencer
>
>
>> Doesn't the Proxy Peer do a similar function?
>> We have Proxy Peer in the diagram(s).
>> Thanks.
>>
>> Eunsoo
>>
>> David A. Bryan wrote:
>>
>>> I don't believe that adaptor node made it into the terminology draft,
>>> but I'm fine with using it as a label if others are comfortable. (it
>>> just never happened to come up in that discussion).
>>>
>>> David
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
From eunsoo at research.panasonic.com Thu Sep 28 10:38:13 2006
From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 28 Sep 2006 10:38:13 -0400
Subject: [p2p-sip] My notes on draft-willis-p2psip-concepts-01
In-Reply-To: <8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com>
References: <053b01c6d2b7$ed3f13e0$0500a8c0@china.huawei.com> <85AC9C32-24BE-4E39-8545-C96182959B86@softarmor.com> <080601c6e26f$32492720$0300a8c0@china.huawei.com> <451ADD5F.6010206@research.panasonic.com> <8b2769930609271355q3c7985eeq28406df4bf5041ac@mail.gmail.com> <09db01c6e27c$af4a44e0$0300a8c0@china.huawei.com> <8b2769930609271545i142fe228pe6b2b25107a48394@mail.gmail.com> <451B47C4.5070000@research.panasonic.com> <0abb01c6e2fb$5e12b1f0$0300a8c0@china.huawei.com>
<8b2769930609280617y3a042901sfb8829d2217ebd65@mail.gmail.com>
Message-ID: <451BDE55.5070402@research.panasonic.com>
One can put the Proxy functionality and Registrar functionality into a
single entity.
They can be separate, too.
Figure 3 and 4 in draft-shim-sipping-p2p-arch-00.txt show how Registrar
Peer/Client and Proxy Peer/Client can enable interoperation between a UA
Peer/Client and CS SIP UAs.
According to the terminology style of draft-willis-p2psip-concepts-01,
P2P Proxy in the first draft is Proxy Peer/Client and P2P Registrar is
Registrar Peer/Client.
Thanks.
Eunsoo
David A. Bryan wrote:
> I was thinking that an adaptor might be an entity that had more than
> just proxy -- we also specify a registrar in that same section. For a
> true C/S node to work, it would need to be able to do lookups and
> registration.
>
> We need to make some clarifications to the terminology draft.
>
> David
>
> On 9/28/06, Spencer Dawkins wrote:
>> ... I'm still working on precision here ...
>>
>> I may have misunderstood this point in the original draft, but I thought the
>> Proxy Peer was a *SIP* Proxy Peer - roughly, providing what I called
>> "Interaction with CS-SIP" in http://www.p2psip.org/P2PUseCases.php.
>>
>> But, looking back at draft-willis-p2psip-concepts-01 more closely, I find
>>
>> 6. Proxy: A peer or client that accepts SIP requests, resolves the
>> next hop or hops using the routing information of the P2PSIP
>> Overlay, and passes the request on towards the next hop.
>>
>> If the Proxy Peer is a *P2PSIP* Proxy Peer, that's fine - but what should I
>> call the node providing "Interaction with CS-SIP"?
>>
>> Thanks,
>>
>> Spencer
>>
>>
>>> Doesn't the Proxy Peer do a similar function?
>>> We have Proxy Peer in the diagram(s).
>>> Thanks.
>>>
>>> Eunsoo
>>>
>>> David A. Bryan wrote:
>>>
>>>> I don't believe that adaptor node made it into the terminology draft,
>>>> but I'm fine with using it as a label if others are comfortable. (it
>>>> just never happened to come up in that discussion).
>>>>
>>>> David
>> _______________________________________________
>> p2p-sip mailing list
>> p2p-sip at cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
From bryan at ethernot.org Thu Sep 28 20:00:56 2006
From: bryan at ethernot.org (David A. Bryan)
Date: Thu, 28 Sep 2006 20:00:56 -0400
Subject: [p2p-sip] BOF approval
Message-ID: <8b2769930609281700h305fe63ak42e625b265d857d8@mail.gmail.com>
Since more than one person has asked me in the last day or so, and I
guess were a bit confused because the email Cullen sent out a few days
ago (21st) said "will be approved" but there was nothing else
later...the BOF has been approved.
Just an FYI.
David
From br at brianrosen.net Thu Sep 28 20:37:39 2006
From: br at brianrosen.net (Brian Rosen)
Date: Thu, 28 Sep 2006 20:37:39 -0400
Subject: [p2p-sip] BOF approval
In-Reply-To: <8b2769930609281700h305fe63ak42e625b265d857d8@mail.gmail.com>
Message-ID: <026801c6e35f$7a4ef130$640fa8c0@cis.neustar.com>
And we need agenda items. If you want agenda time, ask now.
Brian
> -----Original Message-----
> From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-
> bounces at cs.columbia.edu] On Behalf Of David A. Bryan
> Sent: Thursday, September 28, 2006 8:01 PM
> To: P2P-SIP
> Subject: [p2p-sip] BOF approval
>
> Since more than one person has asked me in the last day or so, and I
> guess were a bit confused because the email Cullen sent out a few days
> ago (21st) said "will be approved" but there was nothing else
> later...the BOF has been approved.
>
> Just an FYI.
>
> David
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
From eunsoo at research.panasonic.com Thu Sep 28 20:57:09 2006
From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 28 Sep 2006 20:57:09 -0400
Subject: [p2p-sip] BOF approval
In-Reply-To: <026801c6e35f$7a4ef130$640fa8c0@cis.neustar.com>
References: <026801c6e35f$7a4ef130$640fa8c0@cis.neustar.com>
Message-ID: <451C6F65.6020704@research.panasonic.com>
I suggest we just discuss the charter during the BOF.
We could add a presentation of draft-willis-p2psip-concepts-01 just to
make sure we share the terminology used in the charter.
If we can agree on the proposed chater during the BOF, we are achieving
what we have to achieve in the coming IETF meeting.
If we need to discuss other stuffs, we can have a separate meeting as
another ad-hoc.
Thanks.
Eunsoo
Brian Rosen wrote:
>And we need agenda items. If you want agenda time, ask now.
>
>Brian
>
>
>
>>-----Original Message-----
>>From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-
>>bounces at cs.columbia.edu] On Behalf Of David A. Bryan
>>Sent: Thursday, September 28, 2006 8:01 PM
>>To: P2P-SIP
>>Subject: [p2p-sip] BOF approval
>>
>>Since more than one person has asked me in the last day or so, and I
>>guess were a bit confused because the email Cullen sent out a few days
>>ago (21st) said "will be approved" but there was nothing else
>>later...the BOF has been approved.
>>
>>Just an FYI.
>>
>>David
>>_______________________________________________
>>p2p-sip mailing list
>>p2p-sip at cs.columbia.edu
>>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>>
>>
>
>_______________________________________________
>p2p-sip mailing list
>p2p-sip at cs.columbia.edu
>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
>
From spencer at mcsr-labs.org Thu Sep 28 21:17:40 2006
From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 28 Sep 2006 20:17:40 -0500
Subject: [p2p-sip] BOF approval
References: <026801c6e35f$7a4ef130$640fa8c0@cis.neustar.com>
<451C6F65.6020704@research.panasonic.com>
Message-ID: <0fd701c6e365$0ebeb8a0$0300a8c0@china.huawei.com>
> I suggest we just discuss the charter during the BOF.
> We could add a presentation of draft-willis-p2psip-concepts-01 just to
> make sure we share the terminology used in the charter.
> If we can agree on the proposed chater during the BOF, we are achieving
> what we have to achieve in the coming IETF meeting.
I'm thinking that if we can spend some time making sure we agree on
terminology, that would be time well spent.
> If we need to discuss other stuffs, we can have a separate meeting as
> another ad-hoc.
Got a proposed time? If it's the usual 11:30 til 2:00 on Friday afternoon,
that would be OK...
> Thanks.
>
> Eunsoo
From philip_matthews at magma.ca Fri Sep 29 12:22:19 2006
From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 29 Sep 2006 12:22:19 -0400
Subject: [p2p-sip] BOF approval
In-Reply-To: <451C6F65.6020704@research.panasonic.com>
References: <026801c6e35f$7a4ef130$640fa8c0@cis.neustar.com>
<451C6F65.6020704@research.panasonic.com>
Message-ID:
I completely agree with Eunsoo.
We should focus on the charter and any concerns that people have with
it.
As much as I would like to have technical discussions, I don't think
the BOF
is the right place to have them.
Technical discussions should happen at a separate ad-hoc meeting
(if we can arrange one).
- Philip
On 28-Sep-06, at 20:57 , Eunsoo Shim wrote:
> I suggest we just discuss the charter during the BOF.
> We could add a presentation of draft-willis-p2psip-concepts-01 just to
> make sure we share the terminology used in the charter.
> If we can agree on the proposed chater during the BOF, we are
> achieving
> what we have to achieve in the coming IETF meeting.
>
> If we need to discuss other stuffs, we can have a separate meeting as
> another ad-hoc.
> Thanks.
>
> Eunsoo
>
> Brian Rosen wrote:
>
>> And we need agenda items. If you want agenda time, ask now.
>>
>> Brian
>>
>>
>>
>>> -----Original Message-----
>>> From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-
>>> bounces at cs.columbia.edu] On Behalf Of David A. Bryan
>>> Sent: Thursday, September 28, 2006 8:01 PM
>>> To: P2P-SIP
>>> Subject: [p2p-sip] BOF approval
>>>
>>> Since more than one person has asked me in the last day or so, and I
>>> guess were a bit confused because the email Cullen sent out a few
>>> days
>>> ago (21st) said "will be approved" but there was nothing else
>>> later...the BOF has been approved.
>>>
>>> Just an FYI.
>>>
>>> David
>>> _______________________________________________
>>> p2p-sip mailing list
>>> p2p-sip at cs.columbia.edu
>>> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>>>
>>>
>>
>> _______________________________________________
>> p2p-sip mailing list
>> p2p-sip at cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>>
>>
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip