RE: QoS in Shared Media

["Naidu, Venkata" <Venkata.Naidu@Marconi.com>]

Juha, et. al.,

   Please look at (some relevance)   
   http://www.marconi.com/media/qos100.pdf


--Venkata Naidu


-> Juha, et. al.,
-> 
-> In case people on the lists are curious, RPR is a work in 
-> progress, and
-> there is some interesting material available at the IEEE web 
-> site, presented
-> there a few weeks ago.
-> 
-> One such presentation I would highly recommend is available at:
-> 
-> http://www.ieee802.org/17/documents/presentations/jul2001/am_
-> voqmdl_02.pdf
-> 
-> cheers!
-> 
-> Kshitij Kumar,
-> Lantern Communications, Canada.
-> 
-> -----Original Message-----
-> From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi]
-> Sent: Monday, July 30, 2001 11:53 AM
-> To: Jay Wang
-> Cc: HANSEN CHAN; Fred Baker; Naidu, Venkata; 'mpls@uu.net';
-> te-wg@ops.ietf.org
-> Subject: RE: QoS in Shared Media
-> 
-> 
-> jay,
-> 
-> i'm reading old emails and found your dpr/rpr/diffserv 
-> comment below to
-> which i have not had time to reply.  unfortunately i have to disagree
-> with you regarding dpt/rpr supporting diffserv.  the problem is their
-> node based fairness concept.
-> 
-> lets say that i have a 100 mbps rpr ring of four nodes 
-> a-b-c-d-a, there
-> may be 25 mbps of yellow and red af1 packets from both a to 
-> d and b to d
-> plus 70 mbps of green af1 packets from c to a.  in c, yellow and red
-> packets from a and b to d should not get 1/2 (50 mbps) of 
-> the bandwidth
-> causing 20 mbps of green af1 packets originating from c to 
-> be dropped.
-> 
-> -- juha
-> ------------------------------------------------
-> Jay Wang writes:
->  > 
->  > Dunno what is the problem. To support diffserv, the underneath
->  > transport (MAC layer and lower), does not have to have a
->  > sophisticated traffic management matching diffserv PHBs. The fact
->  > that cisco's DPT (or others RPR version for that matter), a MAC
->  > layer technology, that supports only two transmit 
-> queueing priorities,
->  > hence is not a disqualifier for supporting diffserv on 
-> the higher level,
->  > where you suggested otherwise. In a share-media environment, from
->  > diffserv's perspective, what we need from below is a link layer
->  > that may ensure a quantifiable and stable guaranteed 
-> throughput for the
->  > target nodes, regardless of the other sharing nodes. This 
-> is what is
->  > missing in the original IEEE-802-style LAN. The DPT, on 
-> the other hand,
->  > assures total_ring-BandWidth/node_num for each node. 
-> Given that, the
->  > business of diffserv traffic management, e.g., BA classification,
->  > policing, color-based RED dropping, PHB scheduling, and 
-> so on and so
-> forth,
->  > can be conducted as they should have been at the connected nodes.
->  > 
->  > - jay
->  > 
->  > 
->  > -----Original Message-----
->  > From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi]
->  > Sent: Friday, May 04, 2001 10:52 PM
->  > To: Jay Wang
->  > Cc: HANSEN CHAN; Fred Baker; Naidu, Venkata; 'mpls@uu.net';
->  > te-wg@ops.ietf.org
->  > Subject: RE: QoS in Shared Media
->  > 
->  > 
->  > Jay Wang writes:
->  > 
->  >  > Well, RPR gives you bandwidth endurance at the link 
-> level, a shared
->  >  > media in this case. On higher level, you may conduct 
-> your QoS as
->  >  > appropriate, Diffserv, Intserv, or else. One does not 
-> preclude the
-> other,
->  >  > IMO.
->  > 
->  > how about if someone would like to give different 
-> bandwidth assurance to
->  > more than one independent traffic class?  also, within a diffserv
->  > traffic class, droping of packets is based on the drop 
-> presedence of the
->  > packet, not based on behind which nodes the packets arrived.
->  > 
->  > as i said before, node based fairness can only be applied 
-> to the highest
->  > dp packets within each class.  dpt (and also rpr if it 
-> adopts dpt) thus
->  > supports diffserv only in a very limited sense.  as far 
-> as i remember,
->  > it is the only ieee mac standard, where the specification 
-> tells how many
->  > queues the switch has.
->  > 
->  > -- juha
->  > 
->  > 
->  > -----Original Message-----
->  > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On 
-> Behalf Of Juha
->  > Heinanen
->  > Sent: Friday, May 04, 2001 12:01 PM
->  > To: HANSEN CHAN
->  > Cc: Fred Baker; Naidu, Venkata; 'mpls@uu.net'; 
-> 'te-wg@ops.ietf.org'
->  > Subject: Re: QoS in Shared Media
->  > 
->  > HANSEN CHAN writes:
->  > 
->  >  > How about the work in IEEE 802.17 RPR? I believe it will be a
->  > shared-media
->  >  > technology. Does that mean they will have a hard time 
-> to achieve QoS
->  >  > guarantees?
->  > 
->  > last time that i checked, the rpr proposal (based on 
-> cisco dpt) had two
->  > classes of service (strict priority and best effort). 
-> that is clearly
->  > not adequate for diffserv.  node based fairness applied 
-> to the best
->  > effort class.  in diffserv, node based fairness makes 
-> sense only for the
->  > highest dp packets in each traffic class.
->  > 
->  > -- juha
->  > 
->