Re: [EFM] Network timing, ATM, ADSL/VDSL and EFM
Fletcher,
My experience with ATM only started in 1991. It was my impression that it
was more "IP Geek" type of people that were working on ATM to make an IP
like services be able to compete with the existing TDM services. There was
a "need" to support multiple signal types over the same physical
"circuit". To that multiple signal types was added the ability to do
multiple service types. To the multiple service types came the multiple
qualities of services. The engineers that were working on this kept
running into issues and kept adding more complexity to "patch" the
problems, thus the complexity. In the process they created a technology
that can do things that other technologies can not do. The problem is that
the ability to do those extra things comes at a cost; higher equipment
capital costs, higher personnel costs, higher provisioning and support
systems costs. In some cases the extra cost is not considered worth the
extra functionality. I believe on of the primary motivations behind the
original efforts with MPLS to develop a technology that could provide the
site tranist "virtual circuits" without the high cost of ATM.
Much, if not all of the issues that promoted the development of ATM do not
exist with EFM. In the first place, there is only one signal type that is
being supported here, Ethernet. Secondly, all of the "value added
services" such as IP or content would use EFM as a basic physical
infrastructure, not as the primary service enabler. Other than using SNMP
for "management" what relationship does Ethernet actually have to IP and
other application type services? IP was initially designed to not care
what the basic physical infrastructure was.
The issue of "network timing" is one of utilization. If a service provider
could get enough customers, they could fill the TDM services infrastructure
to 100% utilization. The "timing" of the network allows for a method of
directly multiplexing multiple customer signals with very high security
into the same physical infrastructure. Believe it or not, it is also less
expensive per megabit than other types of multiplexing customer
signals. In order to approach the same potential utilization, other
technologies become very complex and expensive, aka, ATM. As long as 802.3
rules are in place, I will never be able to give you the details of the
economic analysis that was done relative to this issue.
The lesson here is to keep things as simple as possible and still achieve
the functionality that is needed. In some cases, where EFM is used as
basic physical infrastructure for non-Ethernet signal services, then
"timing" and synchronization will be an issue. Where EFM is used as basic
physical infrastructure for "content" services such as "WEB" and video
unicast, then timing will likely not be an issue.
The real question is can the ability to support timing with one of the
alternative methods of providing EFM OAM make it possible to support
"timing" without penalty to those services that do not need it? If EFM OAM
does not have the ability to support "timing" just because some services
don't need it, then there will services and markets where EFM fails to live
up to its current potential. It doesn't matter that your types of services
don't need "timing". Others are saying that theirs do.
Thank you,
Roy Bynum
At 08:50 PM 9/30/01 -0400, Fletcher E Kittredge wrote:
>On Fri, 28 Sep 2001 18:39:48 -0700 "Ed Belkeir" wrote:
> > Please let's not mix protocol timing requirements with "network
> > timing" support. We are not discussing Ethernet timing reqs here.
> > We are talking about a traceable clock.
>
>Thank you, I'll try not to get them confused.
>
> > ATM did not fail because of its timing requirements. ATM failed
> > because of complex configurations and higher cost of deployment.
>
>This is like saying ATM failed because ATM failed. Complex
>configurations and higher cost of deployment is a result, not a cause.
>
> > There are lot things we can learn from ATM: the good and the bad.
> > We, in the IP world, are still struggling with issues that ATM has
> > solved so elegantly; Issues such as QoS, and TE. In the IP world,
> > we are still trying to solve problems by throwing more bandwidth
> > (over engineering) at them.
>
>You stated a great truth here:
>
>1) There are those who over-engineer the nodes (switches, routers)
> to save scarce bandwidth on the vertices,
>2) There are those who over-engineer the vertices in order to reduce
> the load on the nodes.
>
>A stereotype would be that circuit-switched folk fall in group one and
>real IP geeks (such as me) fall in group two. ATM comes from group
>one. When pipes are expensive, ATM is a thing of beauty and the best
>of protocols. When pipes are cheap, ATM seems a thing of: "complex
>configurations and higher cost of deployment." The world view of the
>designers of ATM did not encompass a world of fat, cheap pipes.
>
>I would point out that both group one and group two share the same
>design goals and do a good job meeting those goals starting from a
>different set of assumptions.
>
> > Now back to your objection to network timing support. I take it you
> > don't have any interest in offering voice, video, fax, or emulation
> > services over EFM. If all you want is asynchronous data services,
> > then you don't need any timing synchronization. If in the other hand,
> > you want to offer any of the above services, You will need some
> > form of timing synchronization.
>
>Taking another's words, drawing your own inference and attributing the
>inference to another is a construct of language not suitable for
>reaching consensus. It is suitable for politicial discourse where the
>goal is to score points against an opponent. I hope you don't see me
>as an opponent. I certainly don't regard you that way, rather as a
>fellow seeker after truth.
>
>With that in mind, just because I don't believe your way of
>engineering a network is the to provide these services is best,
>doesn't mean I don't value these services as highly as you. It is
>only that I don't accept your inference that the only by adding
>network timing is it provide video, fax, voice, etc. Is that so bad?
>Please note that uncongested networks do not have jitter, dropped
>packets, etc.
>
> > The support of network timing for synchronization would improve
> > the quality of Voice Over IP and Video over IP. With Fax Over IP,
> > timing inaccuracies can cause some portions of the protocol to be
> > skewed and can result in calls being dropped or lines being missing.
>
>With all respect I say: prove it. Remember, I don't share your
>assumption set. "Stands to reason" arguments don't work with me. You
>might want to try holy water, silver bullets or a wooden stake instead:)
>
> > Two of the largest service providers I run into in the past have
> > required network timing support as a mandatory feature on the CPE
> > and one of them also demanded a stratum-3 internal clock on the
> > CPE.
>
>You will recall from before that I have seen/experienced so many bad
>network designs that saying "some big guy asked for this so it must be
>good" doesn't count as a plus in my book. It is a neutral with a
>slight tendency towards negative.
>
> > I am trying to understand the issues you are having with the network
> > timing support over copper and I coming to the conclusion that it will
> > be hard to implement in an asynchronous half-duplex environment.
> > I was thinking of something like injecting a timing symbol/marker in
> > the downstream traffic at some fixed rate. This way it will be out of
> > the way for services that don't need it and available for services that
> > require it.
>
>My goals are a good IEEE 802.3ah copper standard in the shortest time
>possible, but no sooner. My personal definition of good is:
>
>1) Compatability with current Ethernet standards.
>2) Long reach and tolerance of poor line quality, so to allow as large
> a market share as possible,
>3) Tolerance of poor line quality and minimal cross-talk so as to
> minimize truck-rolls,
>4) low latency and highest bandwidth possible,
>5) reliability,
>6) low cost.
>
>My concern about network timing is:
>
>1) It is a rat-hole on which it will be difficult to reach concensus
> and probably violates the charter of the group. Charter violation
> and the fact that network timing runs directly against the historic
> non-timed, asynchronous architecture of Ethernet, I think that even
> if the group reached consensus, the larger IEEE 802.3 community might not
> accept our draft. In that case, I think copper IEEE 802.3 will not
> be available in time to be widely deployed.
>
>2) It may lower the tolerance of poor line quality and increase the
> amount of cross-talk,
>
>3) It may result in lower bandwidth,
>
>4) It will increase the cost of equipment. For reasons why, please
> see your excellent description of ATM's "complex configurations and
> higher cost of deployment."
>
>Other than these, I have no problems with network timing. If we can
>do it without running into these problems, then I will be very
>impressed and pleased. I would owe you a suitable libation.
>
>good luck,
>fletcher