[EFM] Network timing, ATM, ADSL/VDSL and EFM
As for ADSL/VDSL, it is not that they are failed protocols. The
problem with them is that they are being used for a purpose for which
they were not designed. They were designed over a decade ago by
telcos for Video-on-Demand (VoD) and they are used for IP access. I
guess from one view, the problem was the telco's business case failed,
not the protocols. There is a lesson here.
As for ATM, as someone who was there during the development process, I
can assure you that the purpose of the ATM standards was to replace
both IP and Ethernet by providing the private line, QoS or similar
services some SPs are now talking about in regards to EFM. If ATM
worked as expected, we would not be working on this Ethernet standard.
There is a lesson here.
The proper role of ATM and ADSL/VDSL in this discussion is not as
models for what to include, but as models of how we have failed in the
past. If we want the features of ATM and ADSL/VDSL we have the
following choices:
1) Use these protocols. ATM, ADSL/VDSL are mature and widely
available. If one wants their feature set, use them instead of EFM.
2) ATM and ADSL/VDSL can be used as models of what to avoid.
Example: "We could add a timing requirement to EFM copper, but we
tried that with ATM and it failed."
3) As a touchstone for testing your ideas. Example: "Well, ATM had
rigid timing requirements which made it inefficient for data
transfer, but because of xxx, we are not repeating the same
mistake."
There are many reasons ATM failed. But one of the greatest mistakes
made during the development of ATM was in the selection of the cell
size. In order to meet the 125usec cell processing timing
requirements, the cell size was made so small (53 bytes with a 48byte
payload), that it was inefficient for data transfer. Hence the cell
tax and packet shredding. I remember vividly the sinking feeling I
got in my stomach the day in 1992 that the first preliminary
measurements of IP over ATM performance came in from some grad student
at Berkeley. At that point, it was clear we were toast.
It is not at all clear to me that it is possible to have efficient
packet communications (such as IP) and timing. Ethernet does not have
timing and is efficient for packet communications. There are
those of us who believe the reasons for the phenomenal success of
Ethernet is that it is efficient for packet communications. From
our perspective, by adding timing, you are destroying the advantages
of Ethernet.
I am not willing to fight against timing in the EFM fiber forum
because I don't know enough about fiber communications to have an
informed opinion and I secretly suspect that much of the fiber work
will never be deployed. If IEEE 802.3ah fiber is a bad standard, I am
hoping it will be replaced in time by a better standard.
EFM copper doesn't have the same time-to-market luxury as EFM fiber.
If we don't get EFM copper right on the first try, the legacy PSTN
copper network will die. Further, EFM copper will run over a legacy
PSTN network that *already* has all the timed circuit capabilities.
There is little advantage to adding their emulation when a customer
can just buy a DS*, OC* or ATM circuit via the same network.
Emulating what is already available brings little advantage at great
cost.
So far, the most promising Ethernet over copper work that I have seen
is Etherloop which I understand has an asynchronous, master/slave
architecture. I am concerned that adding timing to Etherloop will
destroy its advantages in regards to lack of interference, reach, speed
and tolerance of bad line quality.
sincere regards,
fletcher