RE: [EFM] Network timing, ATM, ADSL/VDSL and EFM
Zi
At 1GE an Ethernet frame starts to look like a cell in a point to point
network, add 802.1P and 802.1Q and the p2p starts to look like a
deterministic delivery mechanism.
The 'frame tax' with MAC and IP is actually higher than the cell tax, but as
you say, who cares if the service works.
Bob Barrett
> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Zi Wang
> Sent: 28 September 2001 18:48
> To: stds-802-3-efm@ieee.org
> Subject: RE: [EFM] Network timing, ATM, ADSL/VDSL and EFM
>
>
>
> The problem with EFM is that it is difficult to provide voice and video
> service using EFM. ATM, on the contrary, has proven track record on this.
> The small cell size of ATM, makes it possible to translate voice and video
> in a timely fashion. The bandwidth tax on ATM is insignificant if you can
> get 138MPBS from 155MPBS, who cares the 16MPBS tax. You are
> billionaire and
> you do not bother to pay some tax.
>
> If EFM is only for data, it is a better choice than ATM. But if EFM is to
> provide data, voice, and video, I doubt. Any people have idea
> what the cost
> to provide video, voice, and data by EFM compared to ATM ?
>
>
> Zi Wang
>
> -----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 28, 2001 7:59 AM
> To: stds-802-3-efm@ieee.org
> Subject: [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
>
>