[Nml-wg] Metrics for pathfinding

[Aaron Brown]

Hey Freek,

On Jun 6, 2013, at 11:45 AM, Freek Dijkstra <Freek.Dijkstra at 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 at 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20130606/e47f11ca/attachment.html>