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