The MPLS WG Archive

[Juha Heinanen <jh@lohi.eng.telia.fi>]

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
 >