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--
>