RE: [EFM] OAM developing Geoff's observation.
Andrew,
As the original Host Master for MCI (the transmission carrier for the
original NSFNet), and a leader in deploying national and international
scale IP infrastructures, I have a major background in IP. I am well
aware of what is the "talked" about and "marketed" by the IP
community. Given what I know about the inherent characteristics of IP
infrastructures versus Ethernet infrastructures, I have serious
reservations about what will turn out to be economically viable for some of
those IP "things". What we are supposed to be working on here is Ethernet,
not IP.
Thank you,
Roy Bynum
At 06:42 PM 9/21/01 -0700, Andrew Smith wrote:
>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@xxxxxxxxxxxxxx]
>Sent: Friday, September 21, 2001 5:32 PM
>To: ah_smith@xxxxxxxxxxx; 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.