Subject: RE: [Sipping] SIP P2P draft

From: "Johnston, Alan" <[email-masked]>
Date: Fri, 28 Jan 2005 00:52:10 +0000

There's some good ideas in here.

In my research and discussions with DHT implementers, running a DHT
directly on top of SIP does not seem like a good idea - these guys have
implemented many, many optimizations including load balancing, data
striping, and search optimization techniques that we'd have to try to
replicate in our SIP-only implementation.  If latency is at all an issue
(as it clearly is for a discovery mechanism for real time
communication), then using reduced size finger tables and small
successor node tables is not a good design strategy.

I believe that the NAT traversal/TURN discovery mechanism is one
separate function that can be implemented with DHT.  Another is a
registrar function.  A third is a redirect function.

There are also a number of generic protocols being developed in the DHT
community that we may be able to leverage - some are DNS-like with few
writes but many reads, others store only pointers to information and
deal with "flash events" in which a particular piece of data is suddenly
of interest to a large group, others actually manage the transport of
chunks of data.

I agree with Robert that we need to discuss the requirements and survey
the existing work to try to leverage this expertise as much as possible
before jumping into mechanisms.

Thanks,
Alan Johnston
sip:[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jonathan Rosenberg
> Sent: Thursday, January 27, 2005 6:00 PM
> To: Robert Sparks
> Cc: Cullen Jennings; sipping
> Subject: Re: [Sipping] SIP P2P draft
> 
> 
> I also appreciate this work, and think it is worth continuing 
> discussion 
> on documentation on the subject.
> 
> Robert lists potential requirements below. However, I don't 
> see them as 
> requirements per se; mostly they seemed like questions around how a 
> particular problem is addressed when building a p2p network.
> 
> The real requirements question is whether our aim is to build 
> p2p just 
> for sip, or to build a generic p2p protocol (i.e., an 
> implementation of 
> chord and bootstrapping techniques) that provide a generic 
> p2p service. 
> In particular, one might imagine a protocol that effectively 
> exposes an 
> API on participating hosts which, given a resource name, a hashing 
> mechanism, and a p2p system ID (i.e., which p2p network), it 
> returns the 
> IP address of the place where that resource can be found. 
> Such a generic 
> protocol would support joins, leaves, and so on. From my 
> brief reading 
> on p2p literature it seems like this decomposition is common.
> 
> In essence, is the goal to build a generic, standardized p2p toolkit 
> ontop of which we can build lots of p2p applications, or is 
> it just to 
> make sip p2p and do it in a sip specific way?
> 
> I will note that, even once you have developed such a 
> toolkit, serious 
> questions remain about how it could be used by SIP for the 
> purposes of 
> building a p2p network. The primary issue is security, of course. SIP 
> specifies its behaviors logically speaking; a proxy is just a 
> role, and 
> it runs on a host at a specific IP address. Same with registrars, 
> presence servers, etc. If you envision that the p2p protocol 
> effectively 
>   provides an alternative to DNS - a way to find my proxy, or find my 
> presence server - then we could make SIP p2p by just 
> replacing rfc3263 
> with that mechanism.
> 
> But it wouldn't work, of course. The reason is entirely security. SIP 
> assumes a trust relationship that has proxies and presence servers as 
> privileged systems - ones that users implicitly trust. p2p 
> breaks that. 
> Thus, the challenge is entirely how to adapt sip to trust 
> models whereby 
> the provider is an untrusted element by the user. Such an 
> "extension" to 
> address doing that might even be useful in systems where the 
> server is 
> still centrally located via DNS - for example a sip proxy run by a 
> coffee shop I happen to step into. Why should I trust them?
> 
> A fair question to ask is whether certain features we want 
> (like dialing 
> 911 or protecting presence data from prying eyes) can ever 
> reasonably be 
> accomplished in the differing trust models provided by p2p systems.
> 
> One of the big technical issues is NAT traversal. I think that is 
> actually not so hard. We have all of the tools already - ICE in 
> particular is a p2p traversal technique. ICE relies on STUN and TURN. 
> Currently, it assumes that the STUN and TURN servers are centralized. 
> But, they need not be. Instead, we could have them as peer 
> components, 
> and we use the p2p network to locate those too. There, 
> finding them is 
> interesting. The requirement is that you can be a TURN or 
> STUN server if 
> you are on the public Internet. Thus, its not really a search for a 
> single resource by name, but rather a search for any resource with a 
> particular property. Not sure how that could be done in chord, worth 
> considering some more.
> 
> Once you place the TURN and STUN server functions in peer 
> nodes, ICE can 
> be used as is for the media traversal. You need to apply it to SIP 
> registrations and signaling as well. The first step is to use the 
> methodology for registered contacts; you'd register sevreal of them. 
> Thus, when the caller gets the 302 from the registrar, it sends an 
> INVITE to all contacts and picks the one with the highest 
> priority that 
> succeeded.
> 
> Thus, the problem reduces to dealing with the case where the proxy 
> itself doesn't have a public IP. I'd argue that this is probably a 
> problem that needs to be solved in the generic chord protocol 
> I mention 
> above; what to do when a node has a private ID? The answer is TURN, I 
> think; certain servers known to be on the public nework (i.e., 
> supernodes) are always-available TURN servers. A new node joining the 
> network finds these, and can determine whether it is on the public 
> network by an ICE-style connectivity check with known TURN servers 
> (though as folks know I dislike checking for whether you are behing a 
> nat, but I don't see how to avoid it here). If that check succeeds on 
> multiple servers (and fails on none), it adds itself to the 
> TURN server 
> list. Nodes not on the public Internet would then allocate an IP/port 
> from a TURN server that it finds. That IP/port would be used as its 
> identifier in the chord algorithm. My guess is that there are 
> security 
> and naming implicatoins there, need to think about it.
> 
> Anyway, these are just some initial thoughts.
> 
> Thanks,
> Jonathan R.
> 
> 
> 
> 
> Robert Sparks wrote:
> 
> > David, Cullen -
> > 
> > Thanks for putting all the effort you have into this draft 
> so far. I'm 
> > very excited about the potential a more p2p oriented use of 
> SIP has, 
> > and will be contributing to the discussions this draft is bound to 
> > kick off.
> > 
> > I especially appreciate the "early ideas" disclaimer you 
> put in this 
> > announcement (and wish the draft had done so more explicitly).
> > 
> > One of the things were going to discover is that this whole problem 
> > space is especially prone to discussion by jumping to 
> mechanism. This 
> > draft has quite a bit of under-motivated mechanism in it, and I ask 
> > anyone that's interested in this topic to dive into "why 
> we're doing 
> > this" before diving into arguments about "what's in this header".
> > 
> > This is an effort where the desire to skip a requirements document 
> > step will be fatal. When we look at those requirements, I suspect 
> > we'll decide that a lot of the mechanism that went into the 
> > proof-of-concept work isn't quite right and that mechanism 
> will change 
> > in drastic ways (I'm betting that if we get to the end-game, we'll 
> > find ourselves leveraging SIP-Events for example).
> > 
> > Here is a subset of the requirements discussions we're 
> going to need 
> > to
> > have
> > before a serious shot a mechanism should be attempted:
> > 
> >   - Foremost: What does this really buy us that we don't 
> already have?
> > You've provided
> >     a start, but we need to capture this in much more 
> detail before any 
> > of this conversation
> >     is really going to make any sense.
> > 
> >   - What does identity mean in such a network? How will 
> assertions of
> > identity
> >     be made, and what aspects of participation will rely on those 
> > assertions
> >     (Can you join anonymously, or only with a trusted identity 
> > assertion? Once you're
> >      in, can you store state on a peer anonymously? What 
> does it mean to 
> > have more
> >     than one identity service involved? How do you deal 
> with assertions 
> > of an identity
> >     from more than one authority?)
> > 
> >  - Is there one p2p network using SIP or many? (i.e. is there more 
> > than
> > one thing
> >    in the universe with node-id 1). If one (and I think there are 
> > compelling reasons
> >    for just one), how do allow for subsetting the 
> namespace? (In the 
> > draft, you name
> >    overlay networks, but don't talk about how that 
> namespace is managed).
> > 
> >  - How do you address extensibility and versioning? Once 
> one of these 
> > is
> > in the
> >    wild, we're going to need good tools to affect its behavior.
> > 
> >  - How does this leverage or replace DNS? Where does the role for
> > finding things
> >    really live? I expect this to be one of the more 
> spirited discussions 
> > and will
> >    have quite a bit of impact on mechanism.
> > 
> >  - What's required of a node that's storing stuff for other peers? 
> > What
> > are the requirements
> >     on the system for reacting to things like, say, a node that 
> > unwittingly finds itself responsible
> >     for a _very_ popular resource.
> > 
> >  - What are the kinds of state this network will hold? 
> You're already
> > talking about presence
> >    over this network - I've seen early discussions about having a 
> > voicemail-like application
> >    live in this space. I suspect we'll be talking about storing our 
> > buddy-lists off on other peers
> >    before long.
> > 
> >  - What are the privacy and security requirements we're 
> going to place
> > on such a network?
> >     (Do we ask peers to store state they cannot inspect? 
> You call out 
> > the Sybil attack - are
> >     we required to be resilient against it? How about just 
> individual 
> > nodes that are intentionally
> >     introducing bad state.)
> > 
> > - What are our requirements for dealing w/ firewall,nat, or other
> > network inequities?
> >    If we follow the suggestion in Henning's reports of 
> having things 
> > behind nats
> >    work through a relay that's on the ring and in a public 
> space, what 
> > control do we
> >    give clients over what relay they use? What control do 
> we give those 
> > peers that
> >    could be these relays over who they relay for?
> > 
> > This isn't a meant to be a comprehensive list of issues, 
> but I hope it
> > starts to point out
> > the need for and scope of the requirements discussion that 
> will be our 
> > first step.
> > 
> > Thanks again for kicking this off. I look forward to finding out how
> > much interest there
> > is in this concept and working with those that find the 
> potential as 
> > exciting as I do.
> > 
> > RjS
> > 
> > 
> > On Jan 21, 2005, at 1:51 AM, Cullen Jennings wrote:
> > 
> >>
> >> David Bryan and I have submitted an draft of some early 
> ideas on P2P 
> >> with SIP. Until it shows up in the repository, you can find it at
> >>
> >> http://p2psip.org/
> >>
> >> Cullen
> >>
> >>
> >>
> >> _______________________________________________
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> >> This list 
> is for NEW development of the application of SIP Use 
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments of core SIP
> > 
> > 
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [email-masked]                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 31 Jan 2005 18:17:47 -0800

On 1/27/05 7:52 PM, "Johnston, Alan" <[email-masked]> wrote:

> directly on top of SIP does not seem like a good idea

Likely true -  David's current implementation actually does not use SIP.
However when we mapped it, SIP had many interesting properties already in
place. 

>  these guys have 
> replicate in our SIP-only implementation.

Agree - however, much of the current work on optimization would make things
worse for the distributed registrar David I were considering. I imagine
there are optimization that help it. I've tried to read everything I can
about this. The interesting thing is that almost all the current work is
optimized around file sharing where the payload size is very different. Some
of the work is clearly more of "seemed like a good idea" type optimization
than ones that clearly help.

> If latency is at all an issue
> communication), 

I question the assumption that any O(log(n)) lookup scheme will exceed
reasonable post dial delays but yes it's one thing to consider

> then using reduced size finger tables and small

Uh, there will be O(10^9) people on the planet in my lifetime. I'm willing
to bet a beer that it will turn out reducing the finger table sizes below
the size possible with 160 bits SHA-1 hash will turn out to be optimal. This
stuff is all very counter intuitive to I'm only going for a beer not a nice
bottle of wine :-) 

> separate function that can be implemented with DHT.
I've thought about this a bit. I'm not keen on sending the RTP packets for
one session through many different relays because it will maximize dealy and
jitter but I do like the idea off using some sort of hared resource network
to find a relay that is close to the natural E2E path so that the relay does
not increase latency too much. I've also thought about sending each RTP
packets through a different path consisting of multiple relays for
anonymization purposes.

> Another is a 
I had somewhat group the registrar and redirect into one - what are you
thinking about as having them as different? Sounds interesting

> of interest to a large group, others actually manage the transport of

Yes - all very interesting.
> before jumping into mechanisms.

Completely agree, I just think we need some running code before we will
figure out the requirements that are hard to solve.