On Jun 6, 2013, at 11:45 AM, Freek Dijkstra <Freek.Dijkstra@surfsara.nl> wrote:

On 06-06-2013 16:51, Paul Boven wrote:

[...]
At first glance, I would suggest adding attributes such as length,
weight (preference) and bandwidth - as NML is extensible, should such
extensions be coordinated by the NML-WG, or extensions that NSI
themselves could create? Given the basic nature of these attributes, it
would probably be best to have them centrally registered, to prevent
multiple, incompatible versions (Length in m or km? Bandwidth in b/s or
Mb/s?) from occurring.

I would like to see delay (in ms), (maximum) capacity of Links, and
(maximum) capacity and MTU of ports.

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).

For this reason, the proposal to make generic definitions was rejected
at OGF35, and it was suggested to define technology-specific definition
for each technology.

I agree that the above issues are irrelevant for a "rough estimate" as
you need. My fear is that we introduce a "rough estimate", an
application may later use it to check if it is possible to fit a data
flow within a pipe (thus is the bandwidth of the data flow is smaller
than the capacity of the pipe). GMPLS is doing this.

For reference, see http://tools.ietf.org/html/rfc6003#section-4.1 for
how GMPLS defined the bandwidth. I personally think it is way too complex.

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?

Similar to your bandwidth example above, 'delay' has a highly screwing meaning depending on the link (e.g. if an end-to-end link covers 3 physical links and 2 switches, what is its delay? does that include any latency added by the switches? is it average, minimum, or maximum delay?). For bandwidth, in general, I think if folks are really expecting that 9Gbps really means they can send 9000000000 bits of traffic on the link with no issues, they're going to be in for a rude awakening anyway, and it won't much matter with that 9Gbps includes headers or not.

I think if we can come up with some reasonable defaults that roughly account for what most people are expecting, that's probably fine. If folks find that definition of delay, or bandwidth, or whatever, is not to their liking, they can create a new parameter. The other big thing to think about is how people are going to populate this field. It doesn't matter if the documentation says "this must include headers", or "this must not include headers", because people will likely put in what they think should be in there, and there's not really a good way to say "that's not what i right" unless you have very in-depth knowledge of their network.

Cheers,

Aaron

Freek
_______________________________________________
nml-wg mailing list
nml-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nml-wg

ESnet/Internet2 Focused Technical Workshop
Network Issues for Life Sciences Research
July 17 - 18, 2013, Berkeley CA
http://events.internet2.edu/2013/ftw-life-sciences/