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




Matt,

Part of the work that I have been doing in a lab for the last two years to 
characterize Ethernet transmission functionalities.  One of the surprising 
things was how stable Ethernet inherently is.  Non-routing, switched GbE 
Ethernet will often have a worst case data latency variance of a few 
microseconds.  The end to end latency is more a factor of speed of light 
latency than system latency.  This is several factors better than what is 
normally expected of standard IP infrastructure.  Other than something to 
handle "circuit" overloading, Ethernet does not normally need QOS.

Thank you,
Roy Bynum

At 02:38 PM 9/28/01 -0400, Matt Squire wrote:


>Not being a billionaire, I tend to pay attention to taxes.
>
>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.
>
>- Matt
>
> > -----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
> >