Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [EFM] OAM developing Geoff's observation.


I think your concept of "QoS link" is not a useful one: the customer is,
instead, likely paying you for a traffic contract for data passing in one or
other direction across some service boundary. This boundary is usually
implicitly at the point where the customer's data leaves the last piece of
equipment that they control although it is not always a clear demarcation.
You probably sell them some sort of token bucket profile with some mumble
words about what might happen to data that they attempt to send that exceeds
this profile. With this type of contract in place, the customer has no right
to complain to you if someone on the other side of the world drops or delays
their data. It would be a crazy contract otherwise (unless all the parameter
values were "don't care" i.e. a best effort service).

Regarding the places where QoS mechanisms are useful, I beg to differ with
you: QoS mechanisms (here, I think we both take that to mean "mechanisms to
favour one piece of data over another at a place where there is resource
contention") are of value at *any* point along the path where there is
contention for available resources. If my "high QoS" data is allowed
preference over your "low QoS" data on the links and in the switch queues
between me and the bottleneck in the "middle" then, when our mixed data
reaches the slowest bottleneck, it will contain a mix of our data that is
more appropriate to the amount we are each paying. In other words, you can't
use such a simple model of a fast-slow-fast network, often know in the
literature as a "dumb-bell model" (with no pun intended of course): you have
to look at a more realistic model that has several stages of resource
contention along the path.

Another thing to note is that these things are often not symmetrical: rather
than "fast-slow-fast", what influences the traffic most is
"fast-slow-dontcare" for a given direction.

Andrew Smith
(still not representing any type of Bell :-))

-----Original Message-----
[]On Behalf Of Fletcher E
Sent: Friday, September 21, 2001 8:08 AM
To: Geoff Thompson
Cc: Roy Bynum;;
Subject: Re: [EFM] OAM developing Geoff's observation.

If a customer is paying me, the local Service Provider (SP), for a
Quality of Service (QoS) link which they are then using to access the
public Internet, that customer could very well complain if the middle
(Internet cloud) doesn't have sufficient bandwidth to keep their local
link full to the QoS defined limits.  The point I was trying to make
is that QoS is not of much value if the bandwidth in the middle is not
always more than the bandwidth at the ends.  Realistically, all a SP
can guarantee is the bandwidth under the SP's control.