RE: [EFM] OAM developing Geoff's observation.
Roy,
As I've said before, I suggest you go read the literature and talk to some
the people who attend NANOG and IETF meetings before making such statements.
There is a huge body of work on "private line" types of services using IP
and other packet switching technologies and there is much available
equipment with which to implement them: you would do well not to ignore this
fact, as you seem to continue to be doing.
The relevance of this to EFM is that there is a great need *not* to add much
to existing Ethernet standards in some misguided attempt to make them look
more like T1 or ATM. Most people seem to think that the simplicity of
Ethernet is the major enabling feature for first-mile technologies.
Andrew Smith
-----Original Message-----
From: Roy Bynum [mailto:rabynum@mindspring.com]
Sent: Friday, September 21, 2001 5:32 PM
To: ah_smith@pacbell.net; Fletcher E Kittredge
Cc: stds-802-3-efm@ieee.org
Subject: RE: [EFM] OAM developing Geoff's observation.
Andrew,
What you are talking about only applies to "Best Effort" services with
"tiered" bandwidths and "rate shaping". The paradigm that these
characteristics arise from are derived from "Internet" ISP type
services. All of these characteristics are never associated with a
"Private Line" type of service, which is a high margin service that will
easily justify deployment of new edge EFM infrastructure. All of these
characteristics are not inherent in Ethernet, and I do not see that they
would have any relevance to EFM. I think that if the ISPs are willing to
open their minds to another paradigm of inherent characteristics they will
be pleasantly surprised at how stable and reliable Ethernet is and EFM can
be, even without things like QOS at the PHY layer.
Thank you,
Roy Bynum
At 05:29 PM 9/21/01 -0700, Andrew Smith wrote:
>Fletcher,
>
>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-----
>From: owner-stds-802-3-efm@majordomo.ieee.org
>[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Fletcher E
>Kittredge
>Sent: Friday, September 21, 2001 8:08 AM
>To: Geoff Thompson
>Cc: Roy Bynum; bob.barrett@fourthtrack.com; stds-802-3-efm@ieee.org
>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.