RE:about QoS
"Raghu V.V.J Vadapalli" <iprsvp@yahoo.com> Tue, 13 October 1998 17:06 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 NAA00161 for <qosr-archive@odin.ietf.org>; Tue, 13 Oct 1998 13:06:26 -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 NAA13655 for <qosr-archive@odin.ietf.org>; Tue, 13 Oct 1998 13:14:47 -0400 (EDT)
Received: from distmaster.ca.newbridge.com by kanata-mh1.ca.newbridge.com; Tue, 13 Oct 1998 12:50:13 -0400
Received: by distmaster.ca.newbridge.com (SMI-8.6/SMI-SVR4) id MAA27646; Tue, 13 Oct 1998 12:21:45 -0400
Message-ID: <19981013162107.20372.rocketmail@send102.yahoomail.com>
Date: Tue, 13 Oct 1998 09:21:07 -0700
From: "Raghu V.V.J Vadapalli" <iprsvp@yahoo.com>
Subject: RE:about QoS
To: rick king <rickyy@bbs.huizhou.gd.cn>, mpls <mpls@external.cisco.com>
Cc: qosr <qosr@newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-qosr@newbridge.com
Precedence: bulk
X-Info: [Un]Subscribe to qosr-request@newbridge.com
Hi rick, >>>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. >> Yes I agree. That's past. >>1. If u have only bit then u can't support different classes of QoS. > >>you are right,I only take it as example. I am not able to get u properly. We want to support different classes of QoS. Do u agree with that. > >>>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..:) What I mean by multicast QoS is RSVP support requests merging. Which is a lot. >>>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 Yes u do need a routing protocol for RSVP implementation. There is one internet draft on QoS extensions to OSPF. ( QOSPF by gurein..) That can support RSVP . I agree that MPLS can be used for supporting rsvp. But about the present networks which are based IP routing protocols. I think u arrived at bit proposal by the congention bit in the ATM header. Do u!!! I don't think that is a good choice. > >>choice. I am expect them too.. Thanks -Raghu. > == ------------------------------------------------------------ _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com
- RE:about QoS rick king
- RE:about QoS Raghu V.V.J Vadapalli