Subject: RE: QoS in Shared Media

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: Fred Baker <[email-masked]>
Date: Fri, 04 May 2001 11:51:18 -0700

>   delay and delay variation control parameters like ATM?"

Ah, yes, MPLS as ATM-done-over... It's a common thread these days.

I don't think the RSVP developers were trying to imitate ATM; they were 
addressing specific requirements imposed by the applications they were 
looking at, and figured that other control paradigms could be put together 
if needed. And by the way, they were not trying to address the routing 
issue, which would have been necessary to define routes for traffic that 
ensured specific end to end delays. They are trying to control variance in 
delay, not end to end delay, and they disputed the concept that microsecond 
variance controls were necessary to an application whose codecs defined 
tens-to-hundreds-of-millisecond jitter buffers.

If you want to go into he history of Integrated Services, or of RSVP, 
further, I would suggest that we take the discussion private, or move it to 
the issll list, as it is off-topic here.

---

From: "Atiquzzaman, Mohammed" <[email-masked]>
Date: Fri, 4 May 2001 11:48:30 -0500

You might want to look at the 802.1D standard for MAC bridges which provides
user priority in MAC frames?

Regards
Mohammed Atiquzzaman           Tel:   (405) 325 8077
School of Computer Science     Fax:   (520) 962 8422, 
University of Oklahoma                (405) 325 4044
200 Felgar St., Room EL-154    Email: [email-masked]
Norman, OK 73019-6151                 [email-masked]
www.cs.ou.edu/~atiq

> -----Original Message-----
> From: Naidu, Venkata [mailto:[email-masked]]
> Sent: Friday, May 04, 2001 9:59 AM
> To: [email-masked]'
> Cc: [email-masked]'
> Subject: QoS in Shared Media
> 
> 
> 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