Subject: Re: QoS in Shared Media

From: Fred Baker <[email-masked]>
Date: Fri, 04 May 2001 10:47:58 -0700

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: "HANSEN CHAN" <[email-masked]>
Date: Fri, 04 May 2001 14:02:19 -0400

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?

Cheers,
Hansen

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 4 May 2001 22:00:40 +0300 (EEST)

> technology. Does that mean they will have a hard time to achieve QoS

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: "Jay Wang" <[email-masked]>
Date: Fri, 4 May 2001 18:07:23 -0700

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.

- jay

-----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

-- juha

---

From: "Jay Wang" <[email-masked]>
Date: Fri, 4 May 2001 18:14:46 -0700

>Well, RPR gives you bandwidth endurance at the link level, a shared

bandwidth *assurance* that is ...., the spelling checker thing ..

- jay

-----Original Message-----

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 5 May 2001 08:52:17 +0300 (EEST)

> appropriate, Diffserv, Intserv, or else. One does not preclude the other,

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

---

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

-- juha

-----Original Message-----

-- juha

---

From: Pankaj K Jha <[email-masked]>
Date: Mon, 07 May 2001 16:46:00 -0700

Jay:

It's the other way around: let's say you have four nodes A, B, C, D. If [B, C]
require more bandwidth for a certain traffic flow (after making reservations
through RSVP, etc.) they should be able to get it. In case of Ethernet
connecting A, B, C, and D (in sequence, not on the same LAN - we're looking at
ring-type scenario so we can compare Ethernet vs. DPT performance), the Ethernet
MAC doesn't look at Diff-serv bits and passes packets to the system. The system
allows/rejects flows through a node (for transit as well as transmit traffic)
according to rules and permissions. Ethernet doesn't come in the way of doing
these.

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.

It must be noted that a shared LAN-like behavior will give just that - a
LAN-like performance. Diff-serv, etc. are not for all nodes on the same side of
a LAN - these are when you go from network to network. So you cannot use DPT and
make the ring like a pure shared LAN and then try to apply diff-serv to give
different treatment to different customers on the nodes on the *same* LAN.

In a ring network, nodes are not hanging off a wire like Ethernet nodes do on a
LAN. Instead, nodes are connected in sequence - packets enter a node and go to
next node (depending on traffic engineering at the node) and so on. I do feel a
better MAC will do the job here better than Ethernet, but this MAC has to be
carefully designed. A MAC cannot first bypass all L3/L2 assignments and then
tell the system to do the rest. By the time the MAC is done with transit and
node transmit packets, the packet treatments have already been done and the
packet is already out on the Tx port (especially the transit packet).

Maybe I'm missing something here?

-Pankaj

---

From: David Charlap <[email-masked]>
Date: Mon, 07 May 2001 19:51:23 -0400

Jay Wang wrote:
> sophisticated traffic management matching diffserv PHBs. ...
> 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.

If every node is connected via a layer-2 switch that is policing and
shaping traffic, then the nodes are not sharing media.

If the media is actually shared - connected via repeaters and not
bridges - then QoS can only work when everybody plays nice together.

-- David

---

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

>on a metro ring along with average over-provisioned clients, DPT will not
do the

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 18:00:19 -0700

>bridges - then QoS can only work when everybody plays nice together.

Yes, indeed.  

thanks,

- jay

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 8 May 2001 09:03:03 +0300 (EEST)

jay,

dpt is layer 2 technology and i was talking about diffserv support at
layer 2, which dpt doesn't properly have.  ethernet, on the other hand,
does support diffserv also at layer 2, which allows you to build a layer
2 switched network of any topology and still have proper support for
diffserv.  

according to your definition even atm supports diffserv since one can
always use cbr vcs between routers and then let the routers do the
proper queueing.  for several reasons this is not a good idea.

-- juha

---

From: Bora Akyol <[email-masked]>
Date: Tue, 8 May 2001 07:00:46 -0700 (PDT)

> proper queueing.  for several reasons this is not a good idea.

Juha

Would you care to explain your comment above. I would prefer to do the
queueing in the routers rather than let L2 QoS mechanisms manage the
queueing.

Bora

---

From: Pankaj K Jha <[email-masked]>
Date: Tue, 08 May 2001 07:15:48 -0700

Hi Jay:

DPT (or similar technologies) give a "virtual" shared media, and its MAC does
play a significant role in packet forwarding. I've looked at DPT simulation
results, and also looked carefully into its bandwidth allocation. Another
problem with DPT bandwidth management is that a node sends usage notification
upstream through a control message. This prevents statistical multiplexing or
bursting of packets, as actual packet usage changes from packet to packet (by
the time upstream node has taken note of available bandwidth at the downstream
node, the downstream node situation may have changed). Even though there is a
MAX_USAGE field defined, this is not used for the kind of operation you want.

You cannot do PHB if MAC is not helping, that is, if the MAC has already gone
ahead and put transit packets into output transit buffer. The DPT MAC
completely bypasses other schemes by forcing traffic into one of two classes -
high or low. Multiple classes can be used when the MAC either allows it, or
doesn't come in the way of doing it. Maybe you can do PHB if you can somehow
bypass MAC's 2-priority classification and control the whole thing yourself.

On BW issue, typically in metro networks there is usually one or more node that
provides access to Internet, is a file server, or performs similar functions.
Bandwidth requirements at these nodes are quite different from those of other
nodes. You wouldn't want to create multiple rings each time you have nodes that
are data hot points (you can do it easily in LAN environments where you can
segment the network easily using L2/L3 devices. Rings are harder to come by and
need more equipment and installed cabling).

Please let me know if you find a way of doing it with DPT, I'd like to find
out.

-Pankaj

---

From: "Jay Wang" <[email-masked]>
Date: Tue, 8 May 2001 09:41:27 -0700

Hi Juha,

>layer 2, 

I see. Sorry for the misunderstanding.

>which dpt doesn't properly have.  ethernet, on the other hand,

I that case, would you mind elaborating your concerns?

thanks,

- jay

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 9 May 2001 20:19:37 +0300 (EEST)

> I that case, would you mind elaborating your concerns?

the idea behind diffserv is that each traffic is allocated a certain
amount of aggregate resources (buffer space and bandwidth) at each
diffserv (l2 or l3) node.  traffic between a pair of edge routers
belonging to a given class thus shares the resources at each node with
all other traffic in that class.  a cbr vc or other kind of "leased
line" between the routers would reserve the resources for that pair
instead of the whole aggregate.

-- juha