Re: [EFM] Network timing, ATM, ADSL/VDSL and EFM
Fletcher,
just privately, NOT for IEEE exploder.
Have you ever analyzed a second opinion on Etherloop, except what
Patrick is presented in IEEE? This technology was discussed 3.5 years ago
in T1E1.4 and there was almost no people who supported it, just because
there is a very strong concern that it doesn't work as good as Elastic
advertises it. See, people usually don't through into the waste basket
something that is really good. Nortel paid for Etherloop development, but
doesn't offer it to the customers. My simulations also show very bad
results.
Although, the technology looks attractive. Do you have some information
proving it's characteristics or some personal experience with Etherloop?
Vladimir.
Fletcher E Kittredge wrote:
> 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