[Nsi-wg] Topology Use-Case

[Henrik Thostrup Jensen]

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.