Conference azur::mcc

    Often in management systems, the visual characteristics of the LDO
    offer information about what is going on in the pipe.  Widths of the
    line may change as may the 'texture' of the line.  Hopefully, more
    than just color change will go into the implimentation of LDO's, over
    time.  
    
    bill

Bill,

Noted!

Fred

    We are reserving the width of the line as an indicator of bandwidth. We
    had many such requests. We are reserving colors of LDOs to be
    consistent with icons as notifications. Other things we can
    consider for the future are fill pattern, changing color, and using
    combinations of dots, dashes, etc. for different lines the way
    we did when we took drafting back in high school and college.
    
    I am deferring to Fred Messinger on the graphics display stuff. 
    
    wally

>    We are reserving the width of the line as an indicator of bandwidth. We
>    had many such requests. We are reserving colors of LDOs to be
>    consistent with icons as notifications. Other things we can
>    consider for the future are fill pattern, changing color, and using
>    combinations of dots, dashes, etc. for different lines the way
>    we did when we took drafting back in high school and college.
>    
>    I am deferring to Fred Messinger on the graphics display stuff. 
    
The width of the lines as an indicator of bandwidth won't cut the mustard
as a long term solution (maybe not even short term for many). Lines speeds
in many networks vary greatly and therefore many widths would be needed. 
Aside from being difficult to gauge, as the width increases this takes away
from map space and generally looks very poor. I have used this method for
simple map drawings in the past and the results were unacceptable when maps
begin to get complex. Although for some it could work given they don't have
more than 2 or 3 speeds with relatively simple maps.

brad...

>>>The width of the lines as an indicator of bandwidth won't cut the mustard
>>>as a long term solution (maybe not even short term for many). Lines speeds
    
    Brad,
    
    Any input as to what would be an acceptable long and short term
    solution?
    
    Fred

>    Any input as to what would be an acceptable long and short term
>    solution?
    
Hi Fred,

What you folks have already suggested looked to be about the only viable
options to graphically represent speed I can think of. For the short term
there is nothing for us graphically. We use a database today, which MCC
already provides by a mechanism of storing line speed for its other uses. 
But we've got too many widths we'd need to accommodate so the support which
is there today (width) may work for some users but not us.

Using dots, dashes and/or hatch patterns with the lines would probably be a big
help. So long as the lines stay relatively thin and neat. Maybe a combination
of both width and pattern would fill the bill. To be honest, I'm not sure
how *busy* I'd let the map get with different line speeds. What's important
to us is knowing the status of the net. If all these line variations get in
the way of the basic job of seeing the net as it really is, I'd go back to
using text to get the line speed. It's got to be clean and distinctly
different from a notification. A large customer would probably need 7-10
different lines (thin) to represent speeds with the various alarm levels
being uniquely identified. Also, your customers may have other ideas why
they may want to differentiate lines other than speed.

good luck,
brad...

    Actually, line width could also represent utilization, or %
    utilization.  The point is that wires must have many adjustable
    attributes - as should all entity icons for that matter.  When tuning a
    network, bringing up backup circuits, and such - or when displaying a
    map as the output of a simulation routine, it's nice to have
    visualizaion of attributes to see what effect adjustments have.
    
    bill

Bill, Brad

It's possible to place guages and/or text next to lines.
The guages could look like little meters and reflect 
things such as %utilization.  The text could be attribute
data or user-definable strings.


Just a thought:
Using color to reflect changes and states is neat, but I don't
think we want to leave the monochrome world behind (yet!).  If
we have a scheme that works in both worlds, but just looks much
better in the chroma world, great.

Just another thought that assumes a totally chroma world:
(I haven't thought this one out, so bear with me.)

It's also possible to reflect a state or condition using color in the
navigation window and, at the same time, reflect the same condition
using a mechanism other than color in the map window.  BTW in  V1.1,
if we drew something in the map window, it showed up scaled in the 
navigation window.  However, and here's a solution waiting for a problem, 
we can hide objects or make them reappear in either window at any time.

Thoughts?

Fred

    
    With regards to reserving the width of the line as an indicator of
    bandwidth, what would happen on networks where bandwidth is dynamically
    allocated?  Would the map have a "swelling" or "breathing" effect as
    bandwidth changes?  I say that humorously since I assume the LDO width
    would be based on the speed/bw set for the LDO (and not dynamically
    determined).
    
    Rather than reserving features like these for specific uses, you might
    want to provide the flexibility of choosing different widths, choosing 
    dots, dashes, and choosing fill patterns based on what the user wants.
    Of course, you'll want to provide a standard (and reasonable) default
    that would satisfy the general user base.  The downside of providing
    so many flexibility features is that by the time DECmcc is installed,
    fully configured, and operational the network will have changed
    considerably and you'll have to start all over...:-)
    
     

    In the 'new world order' of bandwidth, fancy LDO's will be real useful.
    It does not have to be the static 'reference' attribute that sets the
    LDO characteristics - it can be measured thruput - or triggered from
    an event from the T1 mux or 'phone company' that tells the management
    system that the bandwidth has just been jacked up.  Lines that are
    reserved for backup or overload purposes may be displayed in shadow
    until they are brought into use.  
    
    Too many options are indeed a problem - but it is the concept of
    profiling that is going to make MCC useful in different environments.
    We talk about the need for new ways of showing adjustable bandwidth -
    and it's clear that we can work towards that goal.  What I'm concerned
    about is today's technology, such as routers, bridges, smart-hubs, and
    LAN probes - each having their own unique requirements for management
    that go beyond set/show/alarm/history functions.  Setting up a turnkey
    management environment for a particular technology must be done with
    MCC - then as several are done - the stength of MCC comes out.  The LDO
    will be useful for many 'profiles' - and is a critically needed entity.
    
    bill

Giving alarms the ability to blink (at settable rates) and/or change
color would give the user much more flexibility. For instance, if colors
are used for speed (or utilization etc..) then the alarms could have an
option to blink at different rates to indicate severity of alarms with a
color change also being optional. Pulling in multiple methods to alarm
would give users more flexibility in what they want to see statically
and dynamically.

I also agree that support for mono color is still important. In todays
world many have struggled with keeping maps up to date and available at
a corporate level. Many a rathole has been explored because maps are
in constant need of updates and support of such efforts globally have
always broken down. Hardware/software platform arguements then crop up
with the need to buy then train users. As we move into a windowing
environment and the abilities to print and create .ps files of maps we
can now merge the maps of the network and the management of the network.
As MCC is deployed globally users will create maps (and keep them up to date!)
of their management domains. Therefore we have a common utility which by
all likelyhood is up to date and printable files can be distributed.
Distributed MCC enhances this one step further. But color printers are not
commonplace as yet and thus the need for a mono view would be essential for
such a task.

brad...

    Well, This has been a good discussion that I will kick start again.
    I think variable blink rates stink as far as indicating severity of
    an alarm. Who is going to use a stop watch to find out which severity
    an alarm is. One mans opinion. 
    
    I have had a lot of experience with the width of line to indicate
    bandwidth. When there is a wide range of granularity for width
    it becomes messy. Also, there is a difference between bandwidth
    and capacity. If you assume that at any particular level in an
    Enterprise only 3-4 gross levels of "capacity" are used then you
    can use only 3 or 4 fixed line widths and it works. 
    
    For example, 100 Megabit, 10 Megabit, and 1.5 Megabit at the backbone
    level will work. Line speeds of 19.2 kilobit and 9.6 kilobit are noise
    at the backbone level when the backbone include 100 Megabit service.
    On the other hand, a poor Enterprise's backbone may consist of 9.6
    kilobit, 2.4 kilobit, and 1.2 kilobit circuits. It wasn't too many
    years ago that this was the norm. In the middle are Enterprise's
    with backbones of 1.5 megabit, 56 kilobit, and 19.2 kilobit circuits.
    
    Note that the backbone maps in each of these cases only needed 3
    line widths based upon granularity that were roughly orders of
    magnitude (either base 2 or base 10). 
    
    Now, detail maps may want to show terminal connectivity etc. that
    use the lower "capacity" circuits and for those maps the same
    basic 3-4 line widths work but with different assumptions of
    what they represent. 
    
    As long as you see a complex network as sets of hiearchally constructed
    maps it all works. Any representation breaks down when we try to map
    the complexity of real networks on a single map at a single level.
    Most designers intuitively simplify the problem into a backbone
    model with detail or inset maps for areas of special interest and
    the rules that apply for the backbone can be changed for the insets.
    
    Why shouldn't we assume the same for our iconic maps. If a map gets
    too cluttered, then reconstruct it into several maps each of which
    is simpler and tailored for its purpose. We don't show all of EZnet
    on one single map. We show the backbone in one map. We show each
    building on its seperate map. We don't show terminal access lines
    on the backbone and we don't show backbone connections on building
    maps.
    
    Now for the dynamic capacity! In "dial your own capacity" environments
    there is a maximum and minimum capacity with fixed increments in
    between. I believe that we should indicate the circuit's maximum
    capacity with a line width and show its current capacity with a gauge
    or a meter. If you only use a few granularities of width, then
    the maximum is a good approximation of the capability of the circuit.
    
    I vote with Fred about not trying to dynamically change line width
    to represent utilization. It is a hard composition problem for
    auto-composition to determine how much spacing to leave when the
    spacing can be eaten up dynamically and then returned. Yes, it
    has sizzle but not enough to pay for the processing power and
    composition problems it creates.
    
    wally