Re: [EFM] OAM loop back / echo server function
All;
I am not sure this is germane to this group. Feedback please on
whether or not we should move this off line.
On Wed, 05 Sep 2001 09:54:51 -0500 Roy Bynum wrote:
> I have been designing, building, and supporting very high performance
> IP networks for several years, for both internal and services usages.
Yeah, me too for many years. I have been both on the network
engineering side and the
IMP/PSN/gateway/router/switch/whatever-we-are-going-to-call-it-this-time-around
side of the design exercise.
> The characteristic of latency variance caused by the combination of
> store and forward queues and differential packet sizes always degrades
> the performance of applications on networks that have a high
> utilization.
I want to stress that from my point of view, the solution is to not
have networks with "high utilization". Over the last 20 years, I have
come to believe the cost of mechanisms and procedures to wring that
last 20% to 30% of utilization out of a network out-weigh the benefit.
So I would respond to this design problem by lowering the node size
(interfaces per ESLAM), increasing bandwidth per link, etc. "Fast
pipes, simple routers" is our motto. If a link peaks at 50% of
capacity, what I want to hear from the network engineer is that six
months ago, she scheduled the upgrade of said link, and the scheduled
date is next week.
So, if you are using your store and forward queues much, from my
perspective you have already lost the battle.
Packet fragmentation is a hard problem, for sure. It gives me the
willies to try to imagine doing line speed fragmentation/reassembly at
the rate of 10 gigabits/sec. However, I am not sure that adding QoS,
as I understand it, is the best solution to line speed packet
fragmentation.
> It requires the additional complexity of some form of
> QOS to compensate for that induced latency variance by the IP "stack".
> I have yet to see anybody make something more complex and less
> expensive at the same time.
I just don't believe the "requires" part of this statement. I
wholehearted agree with the strong correlation between more complex
and more expensive.
> 802.3 does not have any store and forward queues. Most Ethernet data
> switches only have one store and forward queue, at the 802.1
> level. Ethernet does not need to have complex QOS functions in order to
> support very time and performance critical applications such as broadcast
> quality interactive video conferencing. Voice over the data network is
> just the beginning of the types of high margin services that might be
> supported over EFM. The key to all of this is to not make it any more
> complex than it needs to be and it will then be more cost effective for
> service providers to deploy the technology at a profit.
Wow, I couldn't agree more with your statement. We are in violent
agreement that EFM does not need to have complex QoS functions and
that we should not make it any more complex than necessary.
I am really worried that I mis-interpreted some of your earlier
postings. If that is the case, my apologies.
regards,
fletcher