On Mar 3, 2008, at 5:26 PM, jiangxingfeng 36340 wrote: > Hi, Bruce: > > I have more comments on Reload-3. > > 1. After reading P2PP-01 and RELOAD-3, the first impression is that > most of the mechanisms in the merged proposal are from the > RELOAD-3. Only the diagonstic usage is from the P2PP. Although the > two proposals have the nearly same design objectives, the proposed > mechanism are still a little bit different. We are very interested > in why you made this decisions, such as, why all authors think hop- > by-hop reliability modes is not better than the via-list? >
reload-03 added hop-by-hop reliability from p2pp. Search for ACK in the text. I view hop-by-hop reliability and via-lists as orthogonal. > 2. Via list and destination list comprise of peer ID which could > ensure the reachability in theory. But each peer ID may be of size > 128 bits or larger. So the method may make the packet fragmented > with high probability. Although Reload-3 provide a built-in frag/ > reass mechanism, but i really don't like it. Because IP > fragmentation algorithm is a attack target of the TCP/IP stack. > I agree that the fragmentation solution needs more work. Again, there's a state tradeoff. If you don't use the via-list, you have to store more state on the peers. The vast majority of messages, however, won't have a destination list containing more than one ID, and won't traverse that many hops on the way to their destination. > 3. In reload-3, with respect to how to use the destination list, it > says " If the entry is this peer, it removes this entry from the > list and looks at the next entry and if the entry is not this peer, > it sends the message to the first peer on the destination list." As > we know, due to churn, some peer in the list may leave the overlay > when the response is forwarded. In this case, the RELOAD-3 sends > the message to the first peer. so my question is: why the > destination peer does not send the response to the first peer > initially? Although JOIN message could not be routed around the > overlay to the JP, it could take semi-recursive or recursive method. > Direct response doesn't work when a NAT is in the way, unfortunately. Hybrid routing approaches that fall back to symmetric response if the other techniques don't work are possible, but add a lot more complexity. > > 5. In the section 1.1.3, it says "This layer is also responsible > for setting up > connections to other peers through NATs and firewalls using ICE, > and > it can elect to forward traffic using relays for NAT and firewall > traversal.". I am interested in the concept relay here, could > you give me more explanations? In SEP-01(http://tools.ietf.org/wg/ > p2psip/draft-jiang-p2psip-sep-01.txt), there is a similar concept: > relaying peer. > If a direct connection can't be established, the protocol could use a TURN relay or could rely on source-routing to relay through another peer (this would be how to implement the relaying peer concept used in SEP). We spent some time discussing both of these options. Right now, I think the implicit assumption is that TURN will be used, but relaying using the peer protocol directly is another possibility. We talked about this a little bit in working on -03, but it's one of the things that just ran out of time. (to me, one of the hardest questions is what you do if you can't establish a direct connection with your replica set. If you have to relay, you're introducing additional points of failure.) Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
