Re: [EFM] Network timing, ATM, ADSL/VDSL and EFM
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