Hi, Saumitra: I don't think direct routing and relay peer require different level of solutions. As we discussed in Minneapolis, we can use a configuration file to indicate to all nodes in the p2psip systems that you can use direct response routing. But you know, in any system, you can not control whether a node is behind NAT, even it is still in a closed system. For example, in Chinese campus, NAT device is often deployed at the entry to the CERNET. Further, for computers in the lab, they often connect to the campus network through the NAT.
So even in a closed system, network administrators can't think all nodes in the closed network are in the same address realm, even they would like to by set options in the configuration files. In this case, it will make direct response fail frequently so that the introduction of the direct response routing mode seems not bring enough benefits. So as proposed in draft-jiang-p2psip-relay-01, a simple test to detect whether the transport address is publicable in the p2psip system is very important to direct response, and relay peer as well. This way, a general solution can make direct response and relay peer work. Note: draft-jiang-p2psip-relay-01 is not meant to propose a solution to test whether a transport address is publicable. Instead, it shows that there are some existing mechanisms can do that, such as uPNP-IGD, NAT-PMP, etc. The focus of the draft is proposing how to extend RELOAD-base to support direct response and relay peer routing. Any comments are welcome. Regards Jiang XingFeng > Hi Roni, > > Thanks. I was asking that this support be added to the base draft. I think > the relay issue and the direct routing issue can be separated as they require > different levels of solutions. _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
