Hi Freek, everyone, On 06/06/2013 05:45 PM, Freek Dijkstra wrote:
The problem with capacity is that it is highly non-trivial for the main technology in use today, Ethernet. Two notes: * Maximum achievable bandwidth of a channel (VLAN) depends on frame size and interframe gap, and header size. (Most technologies define bandwidth of the payload; to avoid these issues, Ethernet defines the bandwidth of the underlying medium) * Ethernet does not work with a achievable bandwidth, but instead defines Committed Information Rate (CIR), Excess Information Rate (EIR), Committed Burst Size (CBS), and Excess Burst Size (EBS).
While I understand that this is a complex issue, we do need a single definition of bandwidth for NSI to properly function end-to-end. Otherwise, we end up with end-users having to 'fudge' their requests to make sure that it fits with any possible underlying technology. So in this context, payload capacity is the only metric that makes sense. I will bring up this issue in the NSI-WG as well, the current draft of the NSI v2.0 spec does not give any precise definition of 'bandwidth'.
Maybe we have to pick, and make some "experimental" parameter: * Do you want a parameter that describes the capacity of the data flow including or excluding the header? * For Ethernet, do you want a parameter that defines the CIR or PIR (=CIR+EIR), or do you prefer two (or four) parameters?
As my goal here is to do reliable pathfinding, I think we should have a single, technology agnostic metric that will tell me whether a link can theoretically support my request, or not. NSI has no notion of CIR/EIR/PIR, so presumably their use of 'bandwidth' matches closes to the CIR parameter for Ethernet. Regards, Paul Boven. -- Paul Boven <boven@jive.nl> +31 (0)521-596547 Unix/Linux/Networking specialist Joint Institute for VLBI in Europe - www.jive.nl VLBI - It's a fringe science