> 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. >
The protocol in reload-03 achieves all of the requirements and is the result of all of the reload-03 authors (yes, all) spending a lot of time focusing on how to improve its performance. If you believe it is flawed, please specify how it is flawed. > > > * 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. > No separate client protocol is required. What features of a client protocol do you believe are not met by the base protocol? > > > * 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. > With all due respect to HIP and the HIP/P2PSIP authors, HIP is still an experimental protocol, and I believe it is still a very open issue how these two aspects of the protocol will interact. We can try to support the features HIP-based overlays will need, but specifying the HIP-specific details in the base draft would be premature. > > * Remove he tutorial section and replace it with references. You didn't respond to my previous comment that we need to have this as a standalone document for protocol engineers to read. > > > 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: > In my previous response, I pointed you to a thread from November with detailed discussion of the pros/cons of different routing modes. > > > 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. > Most people believe that media should never be routed across the overlay regardless of the routing mode. TURN is assumed for deployments where a direct connection can't be established, like regular SIP. > > > 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 . > That's entirely compatible with what is in reload-03. A DHT can specify how to manage routing at that level. It would have to be part of the DHT specification, since it's specific to the DHT's overlay structure. I'm not sure whether it should be part of the base DHT or an extension, due to the somewhat greater complexity. > > > 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. > I'm not sure what you're saying here. How can a peer protocol exist without messages? > > > 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. > My response to your previous message discussed why we chose the terminology we did. Please suggest specific terms and what you would like to see instead. > > > 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. > unstructured overlays are referred to repeatedly and frequently in reload-03 > > > > 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. > Absolutely. Lots of design decisions need discussion. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
