Subject: QoS in Shared Media

From: "Naidu, Venkata" <[email-masked]>
Date: Fri, 4 May 2001 10:58:44 -0400

Hi All

  I have a doubt regarding "QoS in Shared Media".  I don't 
  know how much this is applicable to this discussion list :-)

  But anyway, I am hearing about 40/10(OC768) Gig Ethernet 
  evolution. If not at the core, these technologies may be
  at the enterprise/access networks(?).

  Moreover, The QoS issue is especially interesting over
  wireless access networks as they are likely to be bottlenecks 
  (compared to wireline links) and they are often shared
  media (e.g., wire less LANs). Providing service 
  differentiation on shared media  is  difficult  due  to
  the risk of collisions between packets of different priority.

  * So, first, Is MPLS useful/applicable to these technologies?

  * If so, how the present singling protocols (RSVP/CR-LDP) or
    diffserv TE extended protocols will take care of this?
    As far as I know, classical RSVP is designed for such goals
    and ofcourse, present IP routing protocols also runs
    on such shared media, P2P and NBMA environments.

  * In a simple environment Ethernet -> ATM/NBMA -> Ethernet
    How resource reservation takes place and is there something
    more the present signaling/routing protocols need to do
    for QoS guaranties.
 
  I didn't find anything useful in TE-WG drafts!
  Is that I am missing something?

Thanks & Regards
--Venkata Naidu

---

From: Badri Devalla <[email-masked]>
Date: Fri, 4 May 2001 13:19:24 -0500

|| -----Original Message-----
|| From: Fred Baker [mailto:[email-masked]]
|| Sent: Friday, May 04, 2001 12:48 PM
|| To: Naidu, Venkata
|| Cc: [email-masked]'; [email-masked]'
|| Subject: Re: QoS in Shared Media
|| 
|| 
|| At 10:58 AM 5/4/2001 -0400, Naidu, Venkata wrote:
|| >I have a doubt regarding "QoS in Shared Media".
|| 
|| many have doubts in this area.
|| 
|| Fundamentally, if I can talk with a switch, I am in control 
|| of my end of 
|| the line and it is in control of its end, and we can make 
|| promises about 
|| what we will each do in our direction. On shared media, 
|| anything resembling 
|| QoS assertions or guarantees requires making promises on 
|| behalf of other 
|| systems one does not control. The nearest solutions I see to 
|| that have been 
|| in 802.5 and FDDI LANs, and I wouldn't describe those as having been 
|| "wildly successful."
|| 

Just a nit-pick.
I agree with your thoughts on inability to guarantee QoS without control in
multi-access shared media.
However, 802.5 and FDDI LANs are multiple access and can be run in modes
where you can provide guaranteed deadlines (and not shared media). I am
referring to Synchronous Bandwith allocation and Timed token protocol. You
cannot do this is shared Ethernet.
Token ring and FDDI are like Baby Boomers - they had their time ;) 

badri

---

From: "Naidu, Venkata" <[email-masked]>
Date: Fri, 4 May 2001 14:33:04 -0400

Hi

  Thanks for all those who replied and gave good pointers.

  Fred/David, Some one pointed me to ISSLL WG with this regard
  (I thought this WG is also off along with INTSERV & RSVP)

  Esp about RFCs 2814/2815/2816 - SBM (Subnet Bandwidth Manager)
  Integrated Services Over Shared and Switched IEEE 802 LAN 
  Technologies. I didn't go through these drafts completely 
  but, aren't they doing in the direction we are looking for...

  my question is, why not RSVP for MPLS not considering these 
  work. Recently David was asking "why RSVP doesn't have strict
  delay and delay variation control parameters like ATM?"
  I found some of the RFCs in ISSLL (2379, 2380, 2381 & 2382)
  have answer for that - Inserv has the answer for QoS in any media!
  Are these something different when compared to RSVP for LSPs?

  I am searching for what I missed?! :-)

-Venkata Naidu  

-> -----Original Message-----
-> From: Fred Baker [mailto:[email-masked]]
-> Sent: Friday, May 04, 2001 1:48 PM
-> To: Naidu, Venkata
-> Cc: [email-masked]'; [email-masked]'
-> Subject: Re: QoS in Shared Media
-> 
-> 
-> At 10:58 AM 5/4/2001 -0400, Naidu, Venkata wrote:
-> >I have a doubt regarding "QoS in Shared Media".
-> 
-> many have doubts in this area.
-> 
-> Fundamentally, if I can talk with a switch, I am in control 
-> of my end of 
-> the line and it is in control of its end, and we can make 
-> promises about 
-> what we will each do in our direction. On shared media, 
-> anything resembling 
-> QoS assertions or guarantees requires making promises on 
-> behalf of other 
-> systems one does not control. The nearest solutions I see to 
-> that have been 
-> in 802.5 and FDDI LANs, and I wouldn't describe those as having been 
-> "wildly successful."
->

---

From: "Jay Wang" <[email-masked]>
Date: Mon, 7 May 2001 17:36:14 -0700

Pankaj,

-----Original Message-----
From: Pankaj K Jha [mailto:[email-masked]]
Sent: Monday, May 07, 2001 4:46 PM
To: Jay Wang
Cc: Juha Heinanen; HANSEN CHAN; Fred Baker; Naidu, Venkata;
[email-masked]'; [email-masked]
Subject: Re: QoS in Shared Media

>DPT, on the other hand, will go ahead and divide available bandwidth
equally to
>all four nodes - ignoring whatever you may do with Diff-serv. DPT works
best
>when all nodes have equal bandwidth requirements, and it doesn't work when
you
>have dissimilar bandwidth needs. Dissimilar bandwidth needs are quite
common in
>metro networks where hub-and-spoke configurations are norm. If you have
>bandwidth paying customers such as financial institutions and corporate
clients
>on a metro ring along with average over-provisioned clients, DPT will not
do the
>job at all, in my view.

I believe DPT allows you to artificially specify a cap on the bandwidth, by
configuring the MAX_USAGE parameter, on a per-node basis. But even if all
the
nodes evenly divide the ring bandwidth, this does not mean that on each
node,
I can not provide differentiated treatment (in terms of forwarding and
bandwidth
allocation) among diffserv PHBs at the nodes.  Also if the nodes have very
different
BW needs, then they don't have to be placed on the same ring, a traffic
engineering
issue for the carrier.

- jay

---

From: "Jay Wang" <[email-masked]>
Date: Mon, 7 May 2001 16:09:35 -0700

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