RE: [EFM] Network timing, ATM, ADSL/VDSL and EFM
FWIW, I've always used the rule of thumb that for N bits-worth of QoS
complexity you build into a network node, you get to use another 1/2^^(N+1)
fraction of the potential capacity, or something like that, for small values
of N. Of course this is a very rough rule and applies only to class-based
queueing nodes, not individual flows. It also doesn't take account of the
complexity of any mechanisms to police traffic as it enters the network.
Note also that this is layer-independent. So, for example:
Bits of QoS Usable cap. Example
0 50% Switched FullDup Ethernet
1 75% 3Com's PACE(tm)
3 94% 802.1D traffic classes
6 99% IETF's Diffserv
But the point is that it is a game of rapidly dimishing returns: people
shouldn't knock the idea of merely "throwing bandwidth at the problem" - in
many economic situations that is exactly the *right* thing to do.
Andrew Smith
-----Original Message-----
From: owner-stds-802-3-efm@majordomo.ieee.org
[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Matt Squire
Sent: Friday, September 28, 2001 3:11 PM
To: Roy Bynum
Cc: stds-802-3-efm@ieee.org
Subject: Re: [EFM] Network timing, ATM, ADSL/VDSL and EFM
I agree as long as I can make a few assumptions...
1) the links aren't heavily loaded, and
2) there aren't a large number of hops (ie Internet scale # of hops)
Once the links start getting loaded, your performance becomes less
predictive, packets get dropped, wait longer, etc., and QoS structures
(queueing, policing, shaping, etc) become important.
As you get into larger networks, there are more merge/congestion points,
and you require some way to control the merged traffic streams else the
jitter can grow unacceptable even at lower congestion levels.
But big fat pipes certainly solve a lot of problems...
- Matt
Roy Bynum wrote:
>
> 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
> >