Re: [EFM] What Ethernet are we talking about?
On Tue, 4 Sep 2001 18:24:53 -0300 carlosal@xxxxxxxxxxxxxxxxxx wrote:
> Warning: this is a long message, that talks a lot about some historical
> reasons why some of the issues are being brought by us at the mailing list.
> If you're patient, please read and be welcome to the discussion again :-).
> I apologize for being somewhat out of topic, but I believe it's worth the
> time spent.
Carlos;
This is great. I very much appreciate your taking the time to
write in detail. It makes it much easier to have informed discussions
when we have this level of detail.
Brazil is a world leader in high technology, particularly in
communications. We know that you all are farther along than many of
us in the US. Unfortunately for me, I don't speak/read Portuguese,
which is frustrating when I want to learn from Brazilian advances. Up
North, we get tantalizing hints in the english-speaking press about
the advances in Brazil, but few details. So we know in general what
CTBC and other Brazilian carriers are up to, but don't get enough
detail to learn from your work! I hope you don't mind me querying you
off line in more detail about your experiences.
I started working with IP in 1982 while at university
(American college.) My first introduction was BSD 4.1c TCP/IP using
the "ARPA" family of protocols over Ethernet. I have used and
developed IP over Ethernet networks every day of my life since then.
In 1984 (after spending three months unsuccessfully looking for
suitable work in Central America), I joined Bolt Bernak and Newman
(BBN). At that time, BBN had developed and was running the ARPAnet
backbone using the IPv4 protocols still in use today. I stayed at BBN
for nine years. During that time, I was a part-time graduate student
at Harvard and the OSI and ATM standards were under development. BBN
was one of the first ATM switch developers, but I didn't work on that
project. I was working with Professor HT Kung's group at Harvard who
were also working on initial ATM switch development. In 1992, the
first results of IP over ATM came out showing that IP over ATM was a
bad match. In 1993, it suddenly became apparent that the Internet was
going to be big.
I left BBN in 1993 and six months later became the founder of
a successful ISP in rural northeastern US which I am CEO of today.
In the early years, it was frustrating because it seemed by technical
background was not an advantage in running an ISP. However, it did
lead us into getting into cable modem technology early on, and
avoiding ATM based xDSL technology.
Currently, we have about 25,000 subscribers of which over 50%
are high speed. So CTBC Telecom is many, many times our size. My
experience over the last twenty years has taught me that size is not
an important metric. I have seen big companies do stupid, stupid
things. In the US, the big companies die at a rapid rate.
At our number of high speed subscribers, we have had many of
the experiences you mention. Many of our conclusions match yours.
1) We agree that IP over Ethernet scales well, we also expect to scale
it to 10^5 and 10^6 range (we have a lot farther to go than you to
reach those levels!).
2) We think that ESLAMs (Ethernet Subscriber Line Access Multiplexer)
at a CO (Central Office) are the best solution for us.
3) We very much want to sell our Ethernet services to all comers. We
don't need a regulator to tell us to! One of the places where I
feel legacy carriers are foolish is that they don't realize the
strong economic interest they have in selling to all carriers. We
believe that this difference alone will allow us to over-build and
destroy legacy carriers.
4) We are as committed to privacy and reliability as any legacy carrier,
probably more. I am not sure what "safety" means in this context.
If it means building a network that allows applicable laws to be
enforced, we are committed to that as well. As a side point, at
least in the US, data shows that companies like us do a better job
of doing security, reliability than legacy carriers. When it
comes to safety as I defined it above, where the legacy carriers
run IP networks, we do a better job of safety. For legacy traffic
such as the PSTN and CATV, legacy carriers do at least as good a
job as us.
Where we might differ are:
1) We are primarily interested in IP traffic. Our expectation is that we
will be selling IP over this network, and Ethernet level services
only to customers (other ISPs included). Therefore, our main
interest is making sure that EFM is efficient for IP. We think
this means keeping 802.3ah as close to traditional Ethernet
as possible.
2) All IP traffic is aggregated. The only difference in network
architecture is where the traffic is aggregated. In your model, it
sounds as if traffic is aggregated at the 'CO'. For this reason,
we have a strong end-to-end focus.
3) We view 802.3ah as a 'CO' to customer premise equipment (CPE) protocol.
We view Ethernet bridging, filtering, metering, monitoring, VLANs,
etc. as ESLAM functions. We expect any ESLAM we buy to have these
functions, but not the CPE. We would like the CPE to be as simple,
secure and cheap as possible.
4) We would also like to sell different levels of service, but
differentiate by data rate not speed. No data rate would encounter
congestion except internal to the customer's premise or between the
CPE and the CO. We avoid 'QoS' problems by simply not having
bottlenecks.
> Many of the points above lead us to a strong 'point-to-point' vision of the
> access network. That's not because of our circuit-switch legacy. It's
> because of customer demand, and the fact that we (the carriers) tend to be
> associated with a public service, where reliability, privacy and safety are
> important concerns to address.
With all due respect, I would suggest that we and you see the same
requirements, and it is your legacy as a circuit-switch company that
leads you to interpret the answer to these requirements is to go
point-to-point. I freely admit that my packet-switch history makes me
believe in the "simple devices/fast pipes, end-to-end" model is the
way to achieve these goals.
> This is the opposite of the vision that
> other newer service providers have. It may work for new companies, focusing
> on some specific niches. However, I believe that as such new SP gets more
> mature, they will start to feel the same kind of pressure that we have.
> When some customer down the farthest part of your network fills a claim
> against you at the regulation agency, you're in trouble - you have to
> dedicate resources to answer questions that may seem to be completely
> unrelated to your contractual duties with this customer (after all, he's
> always right, or so they say). Because of the public nature of the basic
> telecommunications service, we learned to always play on the safe side.
> That was a hard lesson to learn, and we must keep practicing it.
Carlos, you might not believe in our method of doing business, but you
have no right to impute motivations from our design decisions. Our
commitment to quality is as high or much higher than yours.
As a customer of legacy carriers for 18 years, and as a successful
competitor for eight, I note that the opinions above express a
blindness about quality common to legacy carriers.
For historical reasons, we are regulated as a monopoly by the Public
Utilities Commission (PUC.) We are not a monopoly but in fact are in a
highly competitive business. We have never had a complaint filed
against us. Why would any one go through the work to file a complaint
against us when they could just pick up the phone, call one of our
competitors and be paid money by the competitor to switch from us to
the competitor?
If you are a carrier, and anyone has gone to the major effort of
filing a complaint against you, then your quality sucks. Monopoly
carriers, across the board, have poor quality. That is why regulation
is necessary. Using the fact that a company is regulated instead of
competitive as an argument for its commitment to quality is laughable.
If that company really had a commitment to quality, it would not be
regulated...
The customer is in fact always right, contract or no.
regards,
fletcher