Re: constraint distribution protocol

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Sun, 25 October 1998 03:12 UTC

Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA04471 for <qosr-archive@odin.ietf.org>; Sat, 24 Oct 1998 23:12:46 -0400 (EDT)
Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id XAA03136 for qosr-archive@odin.ietf.org; Sat, 24 Oct 1998 23:12:48 -0400 (EDT)
Received: from kanata-gw1.newbridge.com(192.75.23.72), claiming to be "kanata-gw1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdYJAa00920; Sat Oct 24 23:12:24 1998
Received: from distmaster.ca.newbridge.com by kanata-mh1.ca.newbridge.com; Sat, 24 Oct 1998 23:06:15 -0400
Received: by distmaster.ca.newbridge.com (SMI-8.6/SMI-SVR4) id WAA14432; Sat, 24 Oct 1998 22:32:06 -0400
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199810250221.LAA02759@necom830.hpcl.titech.ac.jp>
Subject: Re: constraint distribution protocol
To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
Date: Sun, 25 Oct 98 11:21:04 JST
Cc: qosr@newbridge.com
In-Reply-To: <17986.908951476@cs.ucl.ac.uk>; from "Jon Crowcroft" at Oct 21, 98 7:31 am
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-qosr@newbridge.com
Precedence: bulk
X-Info: [Un]Subscribe to qosr-request@newbridge.com

Jon;

> thinking about higher level call admission and qos routing scalablity
> - it seems to me that several of the neat algorithms around might
> scale adequeately for qos routing provided the scope of the links and
> metrics they considered for alternate paths were constrained. but then
> they sould be in any case for lots of reasons (policy, higher level
> call admission, fault tolerance etc)....

I'm afraid that you miss an important point.

Cost may be advertised. End users may have policy. But...

What you call policy on qos routing is bundled sales and, in most
contries, against anti trust laws.

> the problem is that  a lot of these reasons traverse inter-domain
> boundariies so we cannot just split the problem in the "usual" way
> between intra-domain qos routing an inter-domain - we need a seperate
> scheme for distributing constraints for qos routin that is independant
> of routing protocols - i am making the same argument elsewhere for a
> protocol for distributing current traffic conditions to areas of the
> network that don't currently share flows with the reporting region, 
> and in fact the properties of these two protocols might be quite
> similar - basically, they are like link state in advertisement, but
> must summarise based on region,

We do need link state advertisement or its equivalent for QoS routing.

But, then, there is no point to have multiple link state protocols
with syntactical differences only.

> and have source, sink and transit
> filtering like BGP.....

Do you think BGP-style policy management scales?

							Masataka Ohta