Re: [EFM] Network timing, ATM, ADSL/VDSL and EFM
Fletcher,
Please let's not mix protocol timing requirements with "network
timing" support. We are not discussing Ethernet timing reqs here.
We are talking about a traceable clock.
ATM did not fail because of its timing requirements. ATM failed
because of complex configurations and higher cost of deployment.
There are lot things we can learn from ATM: the good and the bad.
We, in the IP world, are still struggling with issues that ATM has
solved so elegantly; Issues such as QoS, and TE. In the IP world,
we are still trying to solve problems by throwing more bandwidth
(over engineering) at them.
ADSL/VDSL deployment is still going strong although at a slower
pace due to poor market conditions, vanishing CLECs/DLECs, poor
quality of the copper lines, and reluctance of the ILECs to open their
turf to the competition. I will also add using ATM over ADSL did
not make thing any easier. Sure including timing requirements in
the ADSL/VDSL did preclude any services from being deployed.
Now back to your objection to network timing support. I take it you
don't have any interest in offering voice, video, fax, or emulation
services over EFM. If all you want is asynchronous data services,
then you don't need any timing synchronization. If in the other hand,
you want to offer any of the above services, You will need some
form of timing synchronization.
The support of network timing for synchronization would improve
the quality of Voice Over IP and Video over IP. With Fax Over IP,
timing inaccuracies can cause some portions of the protocol to be
skewed and can result in calls being dropped or lines being missing.
Two of the largest service providers I run into in the past have
required network timing support as a mandatory feature on the CPE
and one of them also demanded a stratum-3 internal clock on the
CPE.
I am trying to understand the issues you are having with the network
timing support over copper and I coming to the conclusion that it will
be hard to implement in an asynchronous half-duplex environment.
I was thinking of something like injecting a timing symbol/marker in
the downstream traffic at some fixed rate. This way it will be out of
the way for services that don't need it and available for services that
require it.
/Ed.
> 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
>