RE:about QoS
"rick king" <rickyy@bbs.huizhou.gd.cn> Tue, 13 October 1998 14:55 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 KAA25595 for <qosr-archive@odin.ietf.org>; Tue, 13 Oct 1998 10:55:52 -0400 (EDT)
Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id KAA21926 for qosr-archive@odin.ietf.org; Tue, 13 Oct 1998 10:55:52 -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 smtpdKDAa19767; Tue Oct 13 10:55:36 1998
Received: from distmaster.ca.newbridge.com by kanata-mh1.ca.newbridge.com; Tue, 13 Oct 1998 10:23:32 -0400
Received: by distmaster.ca.newbridge.com (SMI-8.6/SMI-SVR4) id JAA24993; Tue, 13 Oct 1998 09:44:35 -0400
Message-ID: <001601bdf6ae$50454020$060a060a@dream.ritt.org.cn>
Reply-To: rick king <rickyy@bbs.huizhou.gd.cn>
From: rick king <rickyy@bbs.huizhou.gd.cn>
To: mpls <mpls@external.cisco.com>
Cc: qosr <qosr@newbridge.com>
Subject: RE:about QoS
Date: Tue, 13 Oct 1998 21:35:15 +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
>>>The reasons can be: >>>IPv4 has TOS bit. But most of the current implementations ignore >>>that bit. ( I think it is same ( to some extent ) ur proposal. >>yes,I know the TOS bit.I think the reason that current implementations >>ignore TOS bits is: >>1)The classic IP software like telnet,ftp,web brower don't need QoS, so >>these days router doesn't support the TOS bits. >>2)If you want to support ToS,then you need to bill the consumer by the TOS >>he applying.Many people maybe don't like this before.But now as IP phone >>appear,I think someone will like to pay for it. >> >> >>>1. If u have only bit then u can't support different classes of QoS. >>you are right,I only take it as example. >>>2. RSVP and MPLS are not just not ment for QoS but Multicast QoS >>>service. >>>( I mean they provide mechanisms to support such stuff) >>So it's still a kind of QoS..:) >>>3. Treating all the classes the same, other than the best effort >>>traffic is not a good n/w design. >>> 4. Why do u think RSVP implementation is diffcult. I think some body >>>a good implementation. I remember that somebody mentioned about their >>> implementation in this mailing list. ( I agree that deployment in the >>>current interner is diffcult..) >>As I know RSVP need some routing protocol to support it,maybe MPLS is a >good >>choice. I am expect them too.. >>> 5. If you want to support IP telephony kind of applications >>> we need RSVP. >>maybe,but there is diffserv now..*_^ >>> >>>Correct me If I am wrong. >>> >>>Thanks >>>-Raghu. >>> >>> >> >> >>--QAA22137.907921468/noya.bupt.edu.cn-- >> > > >--EAC20108.908270041/indiana.edu-- >
- RE:about QoS rick king
- RE:about QoS Raghu V.V.J Vadapalli