回复: about QoS

"rick king" <rickyy@bbs.huizhou.gd.cn> Sun, 11 October 1998 15:39 UTC

Received: from wwwnni.us.newbridge.com (wwwnni.us.newbridge.com [204.177.219.11]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA03288 for <qosr-archive@odin.ietf.org>; Sun, 11 Oct 1998 11:39:59 -0400 (EDT)
Received: from kanata-mh1.ca.newbridge.com (herndon-gw1 [204.177.219.66]) by wwwnni.us.newbridge.com (8.9.0/8.9.0) with ESMTP id LAA08069 for <qosr-archive@odin.ietf.org>; Sun, 11 Oct 1998 11:48:17 -0400 (EDT)
Received: from distmaster.ca.newbridge.com by kanata-mh1.ca.newbridge.com; Sun, 11 Oct 1998 11:32:26 -0400
Received: by distmaster.ca.newbridge.com (SMI-8.6/SMI-SVR4) id LAA12338; Sun, 11 Oct 1998 11:01:26 -0400
Message-ID: <003501bdf528$2ef447e0$060a060a@dream.ritt.org.cn>
Reply-To: "rick king" <rickyy@bbs.huizhou.gd.cn>
From: "rick king" <rickyy@bbs.huizhou.gd.cn>
To: "Kevin DeLange" <kdelange@lighthousecomm.com>
Cc: "mpls" <mpls@netlab.indiana.edu>, "qosr" <qosr@newbridge.com>
Subject: =?gb2312?B?u9i4tDogYWJvdXQgUW9T?=
Date: Sun, 11 Oct 1998 23:02:31 +0800
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 7bit
Sender: owner-qosr@newbridge.com
Precedence: bulk
X-Info: [Un]Subscribe to qosr-request@newbridge.com

>Rick,
>
>If the only reason you want to implement QoS is to insure that there are
only
>two classes of traffic moving over the Internet, then your proposal makes
>sense.  However, there are numerous reasons why you need a more robust
mechanism
>to segment traffic.
yes,you can have more than one bit to segment traffic,like TOS in IP header.
But why does nowadays Internet doesn't support TOS?
BTW: today I read draft-heinanen-diff-tos-octet-01.txt,and I find the ideas
in it is almost like mine. he use one bit to indicate Drop Preference
(DP),one bit to indicate delay.
>Critical applications, and their underlying protocols, do
>not always need the same traffic priorities.  It's not on/off, it's more
like
>how much do you want to turn it on.  More importantly, you have to consider
the
>difference between constant bit rate versus variable bit rate applications.
If
>you want to deliver voice over a packet switched network, you need some
>guarantees that the voice traffic will be provided a steady stream of
priority
>traffic.
 At the same time you may need to guarantee that mission critical data
>applications be given priority over other less sensitive traffic.  And if
>multicast ever becomes a reality over the Internet, it will become even
more
>critical to offer a robust mechanism to allow for more effective bandwidth
>utilization.
>
>Kevin

the following is from draft-heinanen-diff-tos-octet-01.txt,I wonder if there
are this kind of router in use at present.
...
   In a typical router implementation, each TOS has its own queue, which
   it serves with a policy that meets the characteristics of the TOS.
   The DPs, on the other hand, map to queue thresholds so that an
   incoming packet with a DP value i may be discarded if the length of
   the corresponding queue has exceeded a threshold value th(i) of that
   queue.

   The TOS of a packet is set by the application or, if the application
   is unaware of differential Internet services, by the operating system
   or a router.  In the latter two cases, the TOS may be determined from
   the TCP/UDP port numbers of the packet.

   The DP of a packet can also be set by the application, the OS, or a
   router, but the criteria based on which the DP is assigned can vary
   widely.  For example, a packet may be assigned a higher DP if it is
   consider to be "outside" of a given user profile.  For more
   information on policies to set the DP, see [Clark] and [Kilkki].