Dean Willis' Notes from IETF 64 P2P SIP AdHoc Meeting


Hosted by Eyeball networks
Vancouver, BC, Canada
Friday November 11, 2005, 1300-1630
Chaired by David Bryan
Slides Presented
Notes recorded by Dean Willis

Meeting called to order and agenda review led by David Bryan. IETF "Note Well" IPR policy declared.

Topic: P2P work at Columbia

Led by Henning Schulzrinne
Slides Presented

Reports on ongoing analysis and modeling work at Columbia University.

Noted that one under-considered aspect is that good debugging and DHT visualization tools are invaluable.

Topic: P2P Work at William and Mary

Led by David Bryan
Slides Presented

Reports on ongoing work at William and Mary.

Topic: P2P Work at Nimcat/Avaya

Led by Philip Matthews
Slides Presented

Reports on P2P PBX features in existing product, using simple proprietary flooding system that distributes full knowledge of each phone to all other phones in the system.

Second stage of presentation discusses "observations on P2P systems". Comparisons between aspects of P2P for real-time vs P2P for file sharing appear to be particularly relevant for the topic.

Discussion followed:

Noted that while authorization is not so critical in the consumer space, authentication "Who is calling me?" is still quite important.

Noted that other real time communication modalities -- video, text, etc. are relevant to RTR2P, not just voice.

Question: Why do we think the lookup frequency for RTP2P is less than that for file sharing? Answer: Many of the FS systems provide "approximate" lookups and search functions because the sought material is less specific than user identities.

Topic: P2P Networking for Consumer Electronics

Led by: Eunsoo Shim
Slides Presented

Focus is on integrating consumer electronics, like entertainment systems and appliances, using P2P networking. Considering scenarios involving ad-hoc, residential, enterprise or service provider, and global deployments.

Noted that confidentiality is not considered critical in CE applications.

Question: Which applications do you think are appropriate for this growth? Answer: More interested in general in content sharing and streaming than in voice p2P.

Question: Are you more interested in wireless or wired devices for CE? Answer: There is a mix, ranging from cable modems and fixed appliances on cables to broad and narrowband wireless.

Sub-Topic: Security Implications for CE P2P

Not all devices will have capacity to do all the security things we're talking about, and there may be other inequalities between peers. Proposed that the "P2P Identity" include an 8-16 bit "type of peer" that allows others to compensate appropriately. Goal is to allow underpowered devices to participate in a limited way.

Question : Do users really want "anonymous identity"? Answer: This greatly depends on the specific service being offered.

Question: This whole security "cloud" is dependent on roles. Is an identity at the DHT layer a host, a person, a user-ID, or what? Ans: We will need to clarify this.

Topic: Survey of Existing Overlay Techniques

Led by John Buford (chairs a P2P research group)
Slides Presented

Presents a tutorial on overlays and definitions. Cites many useful reference papers.

Question: Would like to clarify what you mean by "one hop". Does it mean every node stores information about every other? Ans. The basic idea is that if the nodes had full routing tables, they wouldn't have to do lookups at the DHT level.

Question: What is the OpenDHT exercise referenced here? Ans. It involves multiple put and get operations.

Topic: SIP based vs DHT based approaches

Led by Eunsoo Shim
Slides Presented

Question: What is your definition of DHT? The slides here refer to O(log n), but previous speaker talked bout O(1). Answer: We're really talking about a structured lookup with planned as opposed to random content.

Comment: Would like to add that DHT is a mechanism for bringing some intelligence to the search mechanism.

Comment: I think fundamental distinction is that in one model, the data resides where it resides, but in others, the system tells you where to put particular pieces of data.

Comment: Confused by design choice. If you had a generic DHT mechanism, the SIP approach listed wouldn't work. It has to understand SIP. Why is this desirable? (editors note: the slide under discussion on SIP DHT uses DHT to decide proxy routing of SIP messages based on material in SIP requests.) Question to be discussed later. (follow on slide discusses DHT search that will return next-hop routing info, rather than proxying request along DHT path).

Comment: You presented two "extreme" approaches: one where DHT serves only as a as proxy lookup function, and one that is completely SIP aware. There are also possibilities for hybrid systems where the structure maintenance is done in some structure-specific protocol, but where the application interaction itself is handled using SIP messages. Response: yes, there are two questions: how to get the information, and how to use it.

Comment: I'm more interested in the impact of the application on the DHT structure than on how to transport the bits around. What are the attributes of a DHT structure that we would like? Response: That's to be discussed in some future material.

Comment: We have been experimenting with a hybrid approach and I see the opportunity there. But the interesting aspect to me is the use-case scenarios and the impact on the resulting DHT.

Comment: Thanks for differentiating the two extreme approaches. Did you do any analysis of hybrid models for "most effective" isolation between application and search function.

Comment: I see three points about putting the two layers together. We have some evidence that this is possible with Chord, but have no such datapoints for other DHTs./ There is a question as to whether a generic DHT could be used here. Also, SIP is always used for establishing a call. Would we have a need to do a DHT lookup for not-a-call, such as for finding a relay server or something. We'd either have to overload SIP to do these things, or design our search functions at a non-SIP level. I'm confident these can be solved in non-integrated model.

Comment: The starting point for differentiation is whether or not the design shows a SIP layer. I would like it to be able to have nodes that are exclusively DHT nodes and do not participate in SIP.

Comment: We need to think more about what we are trying to do before we try to do it. The primary service we're trying to talk about here is key-value determination. I would be happy if I didn't hear the word DHT for the next few hours, and we focused on "translation" instead.

Comment: in one approach, I use a DHT/structure to do a name resolution to figure out where to send a SIP message. In the other, I send off a SIP message, and the DHT/structure figures out where to send it.

Poll: How many people are interested in the second above case: Only a few. The majority seems far more interested in the first case.

Discussion after break clarified the former points on two axes:

  1. Finding the target for a UA vs. forwarding a SIP request in a proxy farm
  2. Updating the DHT/structure via SIP or via some other protocol

Comment: NAT Traversal is the most important thing.

Topic: Interconnect SIP networks using P2P SIP

Led by: Marc Bailly
Slides Presented

Poll: Are people interested in this work?

Question: What are the benefits of using this instead of DNS? Answer: It is less centralized, that DNS.

Comment: There are certain scenarios where you may have a P2P network that is disconnected or mostly disconnected from the DNS that may need to self organize that could benefit from this approach.Comment: In enterprise networks, hierarchy seems to be a natural organization tool. It also requires the ability to operate when disconnected from the Internet. So, I think hierarchical approach is useful, but I have to think more about this DNS vs DHT thing.

Comment: We need to think about namespace. DNS has a fixed naming topology. Would the DHT inherit this, or have a different flatter space?

Question: Do you see connections in the media plane happening P2P, or only signaling?

Comment: It's possible to run embedded DNS servers in a disconnected network.

Comment: DNS is not for tracking names -- counter "Yes it is!"

Topic: Scope Discussion

Led by David Bryan
Slides Presented

Question:Are we talking about scope for an IETF group, or an IRTF group? Answer: This discussion is about IETF working groups.

WRT slide "In Scope": Poll: Are there things on this slide that don't belong here?

Comment We can reduce this to the deliverables, 3,4, and 5 on this slide.

Comment: Support the previous.

Comment: There is the P2P layer or lookup function and related stuff, then there is the relationship between that layer and SIP. This seems a little fuzzy to me. Response> I didn't intend to suggest that we standardize a specific DHT here, but the focus is on enabling real-time communications using SIP. Counter: We could probably have one group looking at P2P for RT comm, and another for for tieing this to SIP. Question to clarify: If this working group is planning to go and give a deliverable, what should you be able to do when you're done? Can you make calls? Retry: Without interworking with SIP, how can you talk to anybody?

Comment: I think the goal here is to realize real-time communication using SIP with P2P target resolution, not build a generic P2P system. We're talking about "the minimum subset of pieces needed to hook this up".

Comment: This is way beyond fuzzy and into warm and fluffy. Are we talking about distributed registrar, distributed nat traversals, or what? I can get no clue from this what the basic problem is.

Comment: I don't think we have a common understanding of the functional architecture of this system. At one level, we could do something that is essentially a mapping, taking an identifier in one shape or form into another, -- say, a key, to a proxy server hostname? In this case, the SIP involvement is incidental -- all we've done is replace the resolver library. The other model involves having most of the nodes in the system be SIP proxy servers that use the distributed data structure to deliver services.

Comment: We need to get more specifics on what this does with respect to SIP 2.0 -- we don't want to be defining a new SIP here.

Comment: These bullets look like a starting point. I'd suggest putting the requirements first, and rephrasing the first point entirely.

Comment: This is a "technology oriented slide" in that it presupposes a bunch of technology decisions. We should deal with just the first two bullets for a while, before doing things like talking about overlay and mapping.

Discussion move to "out of scope"slides.

Comment: Replacing the root of DNS is out of scope.

Noted that once we can talk to a regular SIP network, we can talk to an emergency SIP network, at least with some limitations.

Discussion moved to the "Don't Think We Have Consensus" slide.

Comment: Where does geoloc discovery fit in here? We don't do this today at the SIP level, we need to do it somewhere, and the mechanisms we have today might not work here. Response: Actually, we could carry a geoloc body in P2PSIP as well as client-server SIP. We should perhaps add a bullet saying "Things below the application layer are out of scope".

Comment: Anonymous is "out of scope"

Comment: The SIP drafts on anonymous ID have not solved the problem of anonymizing the media. The only promising approaches to that seem to lead toward distributed P2P mechanisms. Consequently, anonymized communications MIGHT be in the "very interesting for P2P" spectrum.

Comment: It is important to consider "anonymized" from the context of "hard to turn off without turning off the underlying network fabric".

Comment: Comparison of P2P and Cli-Serve is potentially useful, or at least usefully illustrated in use cases.

Comment: DHTs are not a rootless naming system. If you get enough users to be interesting, they need to be rooted.

Comment: Perhaps we should focus more on figuring out what problem we are trying to solve, maybe even publish the use cases draft.

Comment: Are we talking about a simple mapping service, like just SIP URIs, or are we talking about things like finding STUN and TURN and VM servers and so on? Response: These probably need to be solved.

Comment: Documenting "Why P2P" is not possible in the IETF, because it is a business problem. Perhaps we should discuss this at VON.

Comment: It's hard to write the use case for a new technology, because people will often use technologies in ways you haven't imagined. We would do well to just say "Skype is our use case".

Comment: There is a related general problem of finding proximate services that has broad utility and may be interesting as a separate exercise.

Poll: Who thinks use cases would be useful (about 90% of room positive).

Topic: Next Steps

Comment: We should spend the rest of this session on next steps.

Question: Does the use case document mean that we don't need to do "These are the requirements for my application" drafts? Answer: Probably not.

Comment: But we do have an existing requirements document. Perhaps we can add those requirements into that document instead of just doing new requirements.

Comment: We should look at clarifying our general purpose text via email, then think about dos/don't's, and go for a BoF at the next IETF.

Comment: Yes, BoF.

Comment: I can imagine us ready for a BoF at the next IETF. But we're not ready now. We don't have nailed down what we want to do, or why. We need to make this much more crisp, especially showing "why this approach has merit". I would like to talk about the naming and security stuff, because this is where we are getting challenges from outside.

Comment: I support a BoF, and would like to point out that having a functional architecture of where we want to go drives the specific goals.

Comment: I would like the use cases not to just "reference back to peer to peer", they should discuss the actual functional characteristics in detail.

Comment: I do a LOT of BoFs, and review them for the IAB. I believe you could be ready for a BoF by March. The successful charter looks like "Here is our problem, and here are the abstracts of the documents we want to write."

Comment: I think it is optimistic to think that we'll be ready for BoF. This group will draw a lot of attention and questions.

Comment; That's why we're here talking.

Topic: Security Issues

Led by Cullen Jennings
Slides Presented

Comment on Names Slide: Your public key can be a name. Even if it is self-generated. Are you willing to live with a random name? Response: I think a name has human significance -- it cannot be randomly generated.

Comment: A second path can be used to assert your name. This lets us couple to another mechanism (such as email delivery). Of course, this might not work in an ad-hoc disconnected scenario.

Comment: DNS is not a fully-centralized system. Can we explain what we think the advantages relative to DNS are?

Comment: yes, if we accept a scenario where a network organizes while disconnected from the DNS root.

Comment: There is a difference between centralized registration and centralized operation. One does not imply the other.

Comment: We need to get away from the binary notion of security and see if we can get to something probabilistic. Remember, people got names in societies without birth certificates, and this mostly worked. If enough people are willing to assert that you are X, then you are probably X.

Comment: We probably can't have one single security profile or technique that is appropriate to all use cases.

Comment: It is the people who are deliberately non-cooperative who are the pains. It only takes a few spammers to mess up email.

Comment: There are scenarios in a some 1,000,000 node DHTs where any given user can be eliminated by as little as 8 "bad nodes". And bad guys can make a lot of bad zombies.

Comment: We should consider the properties of DHTs or other underlying structures when picking one or more to work with.

Topic: P2P Conversational Services

Led by Marco Tomsu
Slides Presented

Comment: In order to have a a conversation, the only service I need is "Internet". I do not need any control from the service provider -- the model presented here is a dis-service.

Comment: As I understand it, the security issues on Slide 8 represent major unsolved security issues in DHTs. It is probably not wise to base the "service provider" requirements you raise into consideration for solving with DHT models while these remain unsolved problems in the research community.

Close of meeting: 17:07 local time.

Back to the IETF Work Section
Back to the IETF 64 Ad Hoc Meeting Page

Page maintained by David A. Bryan.