On Wed, 21 Dec 2011, Jerry Sobieski wrote:
Attached is rather detailed discussion of the performance of Path Finding on the SC topology.
It is actually possible to optimize the worst case chain mode for scenario #2 from 10 reservation calls to 7 by putting a bit of intelligence into netherlight: After the first reservation failure from starlight/kreolight, netherlight switches away from "silly brute force" method to "backtracking" method for pathfinding. Instead of connecting NL-SL first, it will ask krlight to reserve the dest stp to the port reserved for the uvalight source stp. Other stuff: We didn't really agree on an metrics... In distributed systems one usually count message hops. For best case this can be achived by multiplying with 2 to get the answers for a messages based protocol, and multyplying with 4 in our current "lets answer twice" protocol. For worst case, it becomes slightly more ticky, but something like reservations*3-reservationSuccess messages might do it for messages, and multiply with 6 for the current protocol (people wanting to "optimize" stuff should start here :-)). Worst and best case scenario are presented, but average and deviation are more usefull IMHO. This however involves quite a bit more math :-). IMHO, chaining reservations also solve what is perhaps a more overlooked side of topology, i.e., resource availablity. Topology description tend be fairly static while resource availability is not. Even if one knows all the topology, one would have to know which links and ports are available and all their schedules. Delegating this the NSA/NRM means that we can abstract this away. Also, +1 grouping/sets of STPs in some way. Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.