Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [EFM] Network timing, ATM, ADSL/VDSL and EFM


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:
> []On Behalf Of Zi Wang
> Sent: 28 September 2001 18:48
> To:
> 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:
> []On Behalf Of Fletcher E
> Kittredge
> Sent: Friday, September 28, 2001 7:59 AM
> To:
> 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