Re: Reg: Quality of Service routing

Parag M Panse <parag@utdallas.edu> Mon, 21 December 1998 20:27 UTC

Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10619 for <qosr-archive@odin.ietf.org>; Mon, 21 Dec 1998 15:27:49 -0500 (EST)
Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id PAA25942 for qosr-archive@odin.ietf.org; Mon, 21 Dec 1998 15:27:50 -0500 (EST)
Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdBQBa14031; Mon Dec 21 15:20:19 1998
Received: from qmaster.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP; Mon, 21 Dec 1998 15:06:23 -0500
Received: (from majordom@localhost) by qmaster.ca.newbridge.com. (8.8.8/8.8.8) id OAA23442 for qosr-outgoing; Mon, 21 Dec 1998 14:51:23 -0500 (EST)
Received: from distmaster.ca.newbridge.com (distmaster.ca.newbridge.com [138.120.118.27]) by qmaster.ca.newbridge.com. (8.8.8/8.8.8) with SMTP id BAA10718 for <qosr@qmaster>; Mon, 21 Dec 1998 01:22:16 -0500 (EST)
Received: from kanata-mh1.ca.newbridge.com by distmaster.ca.newbridge.com (SMI-8.6/SMI-SVR4) id BAA08606; Mon, 21 Dec 1998 01:21:54 -0500
Received: from [138.120.118.49] by kanata-mh1.ca.newbridge.com with ESMTP; Mon, 21 Dec 1998 01:21:38 -0500
Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id BAA14380 for qosr@newbridge.com; Mon, 21 Dec 1998 01:21:32 -0500 (EST)
Received: from poteidaia.utdallas.edu(129.110.10.1) via SMTP by ns.newbridge.com, id smtpdAAAa14369; Mon Dec 21 01:21:22 1998
Received: from apache.utdallas.edu (parag@apache.utdallas.edu [129.110.16.9]) by poteidaia.utdallas.edu (8.9.1/8.9.1/null-3.5) with ESMTP id AAA03174; Mon, 21 Dec 1998 00:11:12 -0600 (CST)
Received: from localhost (parag@localhost) by apache.utdallas.edu (8.9.1/8.9.1) with SMTP id AAA09705; Mon, 21 Dec 1998 00:11:11 -0600 (CST)
X-Authentication-Warning: apache.utdallas.edu: parag owned process doing -bs
Date: Mon, 21 Dec 1998 00:11:11 -0600 (CST)
From: Parag M Panse <parag@utdallas.edu>
To: Masilamany Raguparan <ragu@krdl.org.sg>
cc: "Raghu V.V.J Vadapalli" <iprsvp@yahoo.com>, routing quality <qosr@newbridge.com>, Internet Protocol <ipng@sunroof.eng.sun.com>, MultiProtocol Label Switching <mpls@external.cisco.com>
Subject: Re: Reg: Quality of Service routing
In-Reply-To: <Pine.GSO.4.02.9812210819550.26497-100000@fireball>
Message-Id: <Pine.GSO.3.96.981221000646.9592A-100000@apache.utdallas.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-qosr@newbridge.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

On Mon, 21 Dec 1998, Masilamany Raguparan wrote:

> Raghu,
> 
> | Do we need QoS routing if we have enough infinite (I mean 
> | large ) bandwidth. 
> | 
> | >From my poor knowledge:
> | 
> | We need QoS routing b'cos we have limited BW and we want 
> | to give priority to QoS flows. If some one comes with 
> | a Tx system which supports 100s Gb/s,(say 128 channel WDM system)
> | Do we need to support the "special"  status for the QoS flows. 
> 
> Nature of the traffic can be very bursty and suck up your 100s of Gb/s
> bandwidth easily at any given time slot. Therefore, having just large bit
> pipes does not solve the QoS problem. 
> 
> Your delay = propagation time + queuing time + processing time equation
> certainly works, if you have enough capacity left on the link at the time
> of your request.

An implicit assumption that seems to be made here is regarding 'number of
data sources'. 

While designing a system that guarantees certain values of BW and 
end-2-end delay, given the present Internet model no  assumption can be 
made about the number of users or the number of sources geneating data.
Since no upper bound can be placed on the value of this parameter, even
though links with 100Gbps (or higher) , faster CPUs and faster memories
are given eventually the 'number of users' will always catch up and so
the "queueing delay" factor mentioned in the above equation for delay can
be never be eliminated. In fact as the number of users grow, the factor
will become more dominant. So it would be incorrect to say that delay ~
propagation time. 


> 
> Ragu.
> 

Regards...

-Parag