more on "optimal" routes

Martha Steenstrup <msteenst@bbn.com> Fri, 15 May 1992 17:10 UTC

Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02426; 15 May 92 13:10 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id ac01984; 15 May 92 13:16 EDT
Received: from PIZZA.BBN.COM by NRI.Reston.VA.US id ab01980; 15 May 92 13:16 EDT
Received: from pizza by PIZZA.BBN.COM id aa01177; 15 May 92 11:54 EDT
To: B.Kumar@cs.ucl.ac.uk
cc: idpr-wg@bbn.com
Subject: more on "optimal" routes
Date: Fri, 15 May 92 12:52:53 -0400
From: Martha Steenstrup <msteenst@bbn.com>
Message-ID: <9205151316.ab01980@NRI.Reston.VA.US>

Hello Brijesh,

I think you have somewhat different expectation of how IDPR route
generation should work.  I suggest you take a look at the IDPR
protocol specification in order to gain a better understanding of the
IDPR perspective.  Below, I have addressed some of your concerns.

IDPR can do global optimization (minimization of delay or cost and
maximization of bandwidth).  However, I do not expect that users
of IDPR will require this.  Rather, I expect that user requirements
will be more like "supply a low cost route"  or "supply a route
with at least X amount of bandwidth".  In the first case, the
route server may return the lowest cost route it knows about, which
is not necessarily the lowest cost route in the Internet.  In the
second case, the route server will return the first route it
finds with at least X amount of bandwidth.

If users do want global minimums (or maximums), then the
administrators of domains containing such users will have to make sure
that the route servers retain routing information from all domains,
and perform global minimization (or maximization) procedures to find
routes.

I fail to see why you are convinced that IDRP is guaranteed to supply
global minimums (or maximums) in all cases.  In order for IDRP to
supply such routes, the distribution of the path vectors must either
be completely unrestricted or, if restricted, must be such that the
only routes that any border gateway does not hear about are those
routes that it cannot use anyway, because of access restrictions of
the transit domains.  I don't think that one can guarantee that IDRP
will always be used in this way.  Hence, the routes that a border
gateway running IDRP selects may be local minimums (or maximums), that
is, minimum (or maximum) within the set of routes it has learned
about, but not necessarily minimum (or maximum) in the set of routes
theoretically available to it.

Brijesh, route computation is entirely up to the administrator of a
domain.  The domain administrator can choose route generation
procedures that use as much or as little of the distributed routing
information as they wish.  Granted, the more information a route
generation algorithm uses, the more likely it is to generate routes
that will satisfy the user service requirements and transit service
restrictions.  Nevertheless, the route generation procedure is
entirely up to the domain administrator.  The Breslau and Estrin
document you quote is a fine document, but it is not the IDPR protocol
specification.  Here, we should be evaluating the IDPR protocols as
they appear in the IETF internet draft documents.

Yes, with different charging policies, the route server may have to
make assumptions about message sizes, session duration, etc. in order
to construct monetary-cost based routes.  It is up to the individual
domain administrators how they want to handle this.  Remember, I said
that the monetary-cost information is primarily meant as a place
holder for now.  We need to know more about real charging policies and
their eventual use before we can make good recommendations about how
to handle them.

IDPR can send routing information to specific destinations over policy
routes. In this way, it can restrict distribution of routing
information, rather than flooding to all domains.

m