Cell Relay Archive

[Eldon Mellaney <eldon.mellaney@crc.doc.ca>]

manfredi@arl.bna.boeing.com wrote:
> Yes, and maybe more, depending on your particular network.
> 
> In _general_, setup delay (in my opinion) should be the delay from
> the time the source has data to send to the time it is given the
> go-ahead (in ATM terms, I'd say the time between issuing SETUP and
> receiving CONNECT).
> Of course, this is scenario-dependent, but that does not mean it's a
> meaningless parameter.

Agreed. You must treat the network, in some respect, as a black box in
that the call setup delay (to establish a VCC, if my understanding of
the terminology is correct) is the difference between the time the SETUP
message is sent to the network (UNI) and the time the CONNECT message is
received back at the traffic source.

As such, this delay is not neglible. However, calling such a value a
parameter may imply that it would be used as a parameter to be specified
at call setup. Would this be the case? The argument here seems to be
this is not possible because it cannot be accurately quantified. 

> > I'd be happy to entertain any other ideas on how one could define
> > "setup time".
> 
> Define it for different sceanrios, even if they are relatively
> simple. As an ATM network designer with a time-critical application,
> such as a control system application, this information would be
> critically important to me. I'd know what my network looks like, I'd
> know what sort of worst-case number of hops I would possibly run
> into, and I would want to know what is the probability curve that
> represents connect time.

Such a curve would be a good start: What is the likelihood that call
setup in the network will take more than x ms?

> If I have a mesh of 10 switches, as an example, and the mesh is
> lightly loaded (paths are always available between a pair of hosts),
> what is my VC setup time, best, mean, and max? Is it 10 to 100 msec
> or is it 1 to 2 weeks? This is not difficult to appreciate.
> 
> Bert
> manfredi@arl.bna.boeing.com
> 

Note that since every switch employs proprietary components (software
and hardware), including the algorithm for CAC, it will not be possible
to treat each switch in the network identically. This is true even if
the switches are identical, i.e., same switch, from the same vendor, and
same version, as the degree to which each of these switches are loaded
will also affect the time required at each switch to handle a given call
setup message (this brings up the issues of priority given to signalling
by a switch and scheduling).


Eldon.

-- 
Eldon J. Mellaney		
Network Technologies, Communications Research Centre, Ottawa, Canada
http://www.crc.ca