Subject: RE: QoS in Shared Media

From: Kshitij Kumar <[email-masked]>
Date: Wed, 1 Aug 2001 10:16:27 -0400

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:[email-masked]]
Sent: Monday, July 30, 2001 11:53 AM
To: Jay Wang
Cc: HANSEN CHAN; Fred Baker; Naidu, Venkata; [email-masked]';
[email-masked]
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:[email-masked]]
 > Sent: Friday, May 04, 2001 10:52 PM
 > To: Jay Wang
 > Cc: HANSEN CHAN; Fred Baker; Naidu, Venkata; [email-masked]';
 > [email-masked]
 > 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: [email-masked] [mailto:[email-masked]]On Behalf Of Juha
 > Heinanen
 > Sent: Friday, May 04, 2001 12:01 PM
 > To: HANSEN CHAN
 > Cc: Fred Baker; Naidu, Venkata; [email-masked]'; [email-masked]'
 > 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
 >

---

From: "Naidu, Venkata" <[email-masked]>
Date: Tue, 14 Aug 2001 09:56:27 -0400

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:[email-masked]]
-> Sent: Monday, July 30, 2001 11:53 AM
-> To: Jay Wang
-> Cc: HANSEN CHAN; Fred Baker; Naidu, Venkata; [email-masked]';
-> [email-masked]
-> 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:[email-masked]]
->  > Sent: Friday, May 04, 2001 10:52 PM
->  > To: Jay Wang
->  > Cc: HANSEN CHAN; Fred Baker; Naidu, Venkata; [email-masked]';
->  > [email-masked]
->  > 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: [email-masked] [mailto:[email-masked]]On 
-> Behalf Of Juha
->  > Heinanen
->  > Sent: Friday, May 04, 2001 12:01 PM
->  > To: HANSEN CHAN
->  > Cc: Fred Baker; Naidu, Venkata; [email-masked]'; 
-> [email-masked]'
->  > 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
->  > 
->