First, I apologize for not being able to contribute to the mailing list recently. Due to the nature of my work at Skype Labs, I was not able to contribute to the IETF at the time. The nature of my work at Skype has now changed and I now hope to be able to return to contributing on a regular basis.
On the issue of the WGLC for the RELOAD base draft, I am concerned that the issue of how routing is done has not been adequately addressed by this draft. I had hoped that draft-jiang-p2psip-relay would make more progress in addressing these issues together with work on the base draft, but that progress has been slow. I don't think we can move forward on the base draft until we address how to resolve these issues and are sure we have an appropriate way forward from the combination of the base draft and that (or any other) extension drafts that emerge to address these issues. Looking at the problem space, there are three types of deployments we need to address 1) overlays where the majority of peers are behind NATs 2) overlays where no peers are behind NAT/firewalls (provider provisioned) 3) overlays where there is an effort to select peers that are not behind NATs, but connectivity is not assured Currently the draft uses SRR, which addresses all of these cases. However, it imposes a significant penalty on cases where SRR isn't needed because there are no NATs in the way, i.e. raw IP addresses could be used. The analysis of these problems presented so far has tended to look at the query-response pattern, but there are actually many applications in a P2P overlay that are not search---where a node's location is known in advance. In that case, there is a clearer argument for having an IP address to directly contact the target node, and being able to use the Node-ID as a backup. Even in a "classic" p2psip-style lookup followed by an AppAttach, SRR-only routing results in at least 4 log(N) traversals through the overlay, whereas if DRR/RP is available, only one is required. With that said, I stand by my earlier comments on the importance of not introducing additional complexity into the base protocol. But we can't stick our heads in the sand, either. I propose we should ensure that the base draft address scenarios (1) and (2) above in efficient ways. In other words, retain SRR, but specify a way of encoding IP & Node ID together in a Destination so that messages can be sent that way. Import flags so that direct routing can be used and address the state issue on intermediate peers. Scenario (3), where it may not be possible to know in advance whether direct or overlay routing is needed, is more complicated and needs to be outside the scope of the base draft. However, we do need to make sure that there is nothing fundamentally flawed in the base protocol that prevents adaptive or variable routing being done as an extension. As has often been discussed in this group, SRR has the advantage that it always works. That means RELOAD needs to support it, but if we expect RELOAD to be adopted in the real world, we need to make sure it allows the optimizations that can (and should) be done across the full range of deployment possibilities. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
