The IP over ATM Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1996-Apr> msg00116



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

QOS Routing

  • From: onvural@vnet.ibm.com
  • Date: Wed, 10 Apr 96 12:56:21 EDT

*** Resending note of 04/10/96 11:21
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 From:
 Subject:
Subject: Re: QOS Routing
Noel
>Basically, too much overhead goes on sending information
>about current loads
>to people who have no use for it. In addition, in a
>network of any size, if
>you're using a distributed path calculation, you're going to be having
>problems with stabilization.
>You have to do a cost/benefit analysis, which is "will the overhead of
>flooding this information be larger than the benefits of
>having it on hand,
>as opposed to the alternative of getting load info on
>demand, as a piggyback
>on reservation". My intuition says that answer is probably "no".

Assuming that sending an update to every node in the network
every time a new resource reservation is made or
an existing one cleared is optimal (towards minimizing
call rejection probability), we did a simulation study
of various proposals (to appear in ISDN and Computer Networks).
There is no much need to send an update until the link
starts filling up. As various links in the network gets congested,
it is possible to send an update only when a call is rejected
(i.e., can not be supported). While this reduces the update flows
in the network considerably, it does not effect the throughput
significantly. Depending on the network objectives, there are
other schemes to use as well.
In summary, with a careful design, it is possible to reduce the
overhead associated with distributing update information while
achieving quite reasonable "optimality" in the network.
Raif