Folks,
I have just seen that the mail archive does not go back before March 5 and this message is not available in the archive, so I hope people who may have missed it, can see it now. My apology to those who have already read it and answered (almost only Reload authors). Well, the proposal to have an editor with quality time, and being neutral dare I say has not been yet discussed. The neutral editor with quality time should be an agenda item with a hum. Henry ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Henry Sinnreich Sent: Saturday, March 01, 2008 4:13 AM To: P2PSIP Mailing List Subject: [P2PSIP] Extending the (inclusive) merge for P2PSIP As mentioned, here is how to extend the inclusive merge for P2PSIP with the best proposals from various authors. I hope this can make it to the agenda of the P2PSIP WG meeting. 1. Merge proposals. 1 2. What's wrong with the Core Protocol in Reload-03. 1 3. Discussion of design decisions. 1 4. Why an editor is required. 1 1. Merge proposals * Replace section 4. Base Protocol with P2PP since P2PP has all the desirable properties: Works for structured and unstructured overlays, has a rigorous I-D, freely available code, large scale deployment and several independent implementations. Hopefully SIPit testing and the SIP Forum can be engaged for interoperability testing and debugging as well. By contrast, the present section 4. Base Protocol is seriously flawed as shown here below. * Subsection for the client protocol: The proposals for the client protocol, one of which (draft-pascual-p2psip-clients) is based on P2PP anyway, and should be merged here as well. * Security (I like these sections very much): Should the various sections on certificate security and secure transport be consolidated into one section on Security? Where does the security for the HIP part belong? If HIP is secured, when/if is TLS and DTL still useful? * Combine the two proposals for using HIP, the high level HIP-Bone and the detailed, step be step p2p-sip-id-loc should be merged into one single HIP (optional for P2PSIP) section. * There may be more and I apologize for keeping this here to a short list only. * Remove he tutorial section and replace it with references. 2. What's wrong with section 4. Core Protocol in Reload-03 * The basic assumption on which the whole section 4. Base Protocol and the related section 3. Overview is written is based on symmetric routing from the source to the root and back using the same path. This is a flawed approach: a. Churn can break the return path. For a example a 95% probability for success in the presence of churn over 10 hops each will result in a total probability of success of 099^10=0.59, that is 59%. The media path cannot work well if the two end points cannot see each other and there is no solution given here for the media path. Perhaps another media relay or using HIP? This is a missing item. In any case the media path MUST NOT follow the symmetric search path since the delay will be unacceptable over so many hops and unknown geographic locations that can be anywhere on the Internet. b. The correct approach for non-transitivity in the DHT is to use more than one source node for the search in the underlying DHT with smart timeouts for "node recovery" as described in "Non-Transitive Connectivity and DHTs", http://srhea.net/papers/ntr-worlds05.pdf and http://srhea.net/papers/bamboo-usenix-talk.ppt . c. The above shows how the DHT can do the required work and why the whole routing (forwarding) layer with its routing tables, routing state, retransmissions, flow control, etc. at the application level in Reload-09 is redundant. This kills the rationale IMHO also for the methods described in section 7. Method Definitions. d. As mentioned, technical terms such as connection, long hop and nearby neighbors (leaf set) are treated in a cavalier way and this must be fixed in the sense of using Internet and P2P terminology common in the technical literature. A glossary with references would help. e. Though the use different DHTs is claimed (but not the use of unstructured overlays), what is shown is only a nailed-down-like use of Chord, much less general and modular as in P2PP. 3. Discussion of design decisions There are several design decisions that should be discussed on the list such as the use of SIP GRUU. What is the usage scenario of using GRUU in P2PSIP and in what cases is it useful? We already have defined how to connect P2PSIP networks with the DNS world. 4. Why an editor is required The emerging P2PSIP protocol document will be on of the most complex in the IETF, probably exceeding the size of RFC 3261. Such a document requires a dedicated editor having adequate quality time, besides the authors and contributors of the various original protocol proposals. Thanks, Henry
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
