Re: Reg: Quality of Service routing
Antoni Przygienda <prz@dnrc.bell-labs.com> Tue, 22 December 1998 01:15 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 UAA14780 for <qosr-archive@odin.ietf.org>; Mon, 21 Dec 1998 20:15:37 -0500 (EST)
Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id PAA08219 for qosr-archive@odin.ietf.org; Mon, 21 Dec 1998 15:59:47 -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 smtpdIRBa14031; Mon Dec 21 15:20:50 1998
Received: from qmaster.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP; Mon, 21 Dec 1998 15:06:24 -0500
Received: (from majordom@localhost) by qmaster.ca.newbridge.com. (8.8.8/8.8.8) id OAA23433 for qosr-outgoing; Mon, 21 Dec 1998 14:51:14 -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 VAA08505 for <qosr@qmaster>; Sun, 20 Dec 1998 21:30:23 -0500 (EST)
Received: from kanata-mh1.ca.newbridge.com by distmaster.ca.newbridge.com (SMI-8.6/SMI-SVR4) id VAA06883; Sun, 20 Dec 1998 21:30:20 -0500
Received: from [138.120.118.49] by kanata-mh1.ca.newbridge.com with ESMTP; Sun, 20 Dec 1998 21:30:03 -0500
Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id VAA24788 for qosr@newbridge.com; Sun, 20 Dec 1998 21:20:06 -0500 (EST)
Received: from dirty.research.bell-labs.com(204.178.16.6) via SMTP by ns.newbridge.com, id smtpdAAAa24770; Sun Dec 20 21:20:02 1998
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Sun Dec 20 21:19:33 EST 1998
Received: from dnrc.bell-labs.com (root@prz-home [135.180.152.138]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id VAA28931; Sun, 20 Dec 1998 21:19:30 -0500 (EST)
Message-Id: <367DAE12.F66AB40C@dnrc.bell-labs.com>
Date: Sun, 20 Dec 1998 21:10:26 -0500
From: Antoni Przygienda <prz@dnrc.bell-labs.com>
Organization: Bell Labs, Lucent Technologies
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.0.33 i586)
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
References: <Pine.GSO.4.02.9812210819550.26497-100000@fireball>
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
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. > Let me bring the economical and philosophical component into this discussion that I tried not to touch so far but probably needs being spelled out: 1. Any amount of bandwidth can be thrown at the problem. 100 Gb/s on transmission media and beyond are not a dream but as CPU, bus & memory technologies taught us, matter of years at most. 2. CPU problems, memory bandwidths, complicated lookups, per-flow-queining in ASICs and other "traditional-router" problems that QMA brings up can be solved based on the fact that "pigs with enough thrust fly just fine" (Ross) and made ATM such a hard sell. Thrust being here on one hand IP being open and amazingly scalable (with hacks of course ;-) technology, on the other hand the expected (and for some companies already real) significant revenues from networking and on the third hand progress in ASIC technology. 3. Any amount of a free (or perceived as free) resource on this planet has or is being depleted if it has any value. why is a question that has seemingly simple answers but can run very deep. I highly recommend http://pespmc1.vub.ac.be/Default.html Therefore I believe that we'll always face congestion in today's model of the Internet, no matter how much bandwidth you are willing to throw at the problem. Which leads to the core of what I try to say: QoS routing is just one possible mechanism how to provide certain guarantees about certain resources to the user. What the resources are and what other mechanisms could be used (network engineering or over-engineering, shaping, CAC and others exist) depends on the pricing model which is basically a function you try to optimize on. Since pricing in the Internet today is basically flat at the end-user level, there is little or no incentive to provide guarantees and therefore deploy something along the lines of QoS routing. Given a different pricing (and an according billing, that's of course the tough part ;-), different mechanisms could be necessary and being deployed. The picture is particularly twisted IMHO since lots of things you'd want to do are not necessarily what is possible (or being perceived as possible) from the technological perspective and therefore widely different perceptions of what reality of data networking on the scale of the planet should be clash in entertaining fireworks onto each other in recent years. I hope that unifies or at least spells out lots of implicit assumptions that I sensed in the different mails sent to this thread ... thank you --- tony
- Re: Reg: Quality of Service routing Roch Guerin
- Re: Reg: Quality of Service routing Masilamany Raguparan
- Re: Reg: Quality of Service routing Parag M Panse
- Re: (IPng 6937) Re: Reg: Quality of Service routi… Matt Crawford
- Re: Reg: Quality of Service routing Antoni Przygienda
- Re: Reg: Quality of Service routing Barry Dykes
- Reg: Quality of Service routing Raghu V.V.J Vadapalli
- Re: Reg: Quality of Service routing Bala Rajagopalan
- Re: (IPng 6939) Re: Reg: Quality of Service routi… Lloyd Wood
- Re: Reg: Quality of Service routing Daniel Awduche
- Re: Reg: Quality of Service routing Raghu V.V.J Vadapalli
- Re: Reg: Quality of Service routing Qingming Ma
- Re: Reg: Quality of Service routing Richard Carlson
- Re: Reg: Quality of Service routing Antoni Przygienda
- Re: Reg: Quality of Service routing Bob O'Hara