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

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

-----Original Message-----
From: owner-stds-802-3-efm@majordomo.ieee.org [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Vladimir Senkov
Sent: Friday, September 28, 2001 12:11 PM
To: 'mattsquire@xxxxxxx'; Zi@xxxxxxx
Cc: stds-802-3-efm@ieee.org
Subject: RE: [EFM] Network timing, ATM, ADSL/VDSL and EFM

Absolutely. Also, EFM offers bigger pipes too. With pipes big enough voice and video over frame begin to work. I'm not sure how well video over copper EFM is going to work, but video over fiber EFM will probably work better than video over say OC3 ATM works today.

-----Original Message-----
From: Matt Squire [mailto:mattsquire@xxxxxxx]
Sent: Friday, September 28, 2001 2:39 PM
To: Zi@xxxxxxx
Cc: stds-802-3-efm@ieee.org
Subject: RE: [EFM] Network timing, ATM, ADSL/VDSL and EFM

There are numerous examples of providing both voice and video over
Ethernet networks. The examples require prioritation and QoS at layers
2 and/or 3. But its more than possible, its already working.

The QoS is not free, and the jitter and wander over variable size packet
networks are generally higher, but the end result is cheaper and the
quality of the service can be engineered to be acceptable.

> -----Original Message-----
> From: Zi Wang [mailto:zi@xxxxxxxxxxxx]
> Sent: Friday, September 28, 2001 1:48 PM
> 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
>