[e2e] how far it queues?

[SERBAN Rares]

Hi Alex,

You try to speak for a general case of QoS. In my
opinion we speak about QoS just for specific cases:
network topology, applications used in the network,
administrative policies, etc. Each network
administator knows the "weakness points" of the
network and applies QoS methods to "cache" those
points.
The answer for you is: QoS in a particular network
depends of the skills and the experience of the
network administrator.And to not forget at least the
marketing department who does presure on network
administrator to preserve the present and the future
agreements.;)

Cheers,

R.

--- "Alexandre L. Grojsgold" <algold at rnp.br> wrote:
> 
> 
> Hi all,
> 
> I´ve got a few answers to my first posting, that can
> be summed up to:
> 
> - QoS benefits are questionable;
> 
> - it is only noticeable and/or useful when
> congestion arises.
> 
> 
> I did not really mean to launch a discussion on QoS
> - I know the subject is highly controversial, and
>largely discussed before.
> 
> 
> So, lets put QoS apart for a while, lets assume that
> no way exists to actively manage router queues, and
>that the only way that packets can be forwarded is by
>sending them in a first come first served basis. And
>that no effort is done to differently serve
individual > flows.
> 
> 
> Lets assume also that we run a "standard"  backbone
> network, made out ou routers of a popular brand and
>of hi capacity deterministic links. And that looking
>at traffic statistics we see that instataneous mean
>traffic (the traffic reported by the router itself
>over a 5 minutes period) never exceeds 80% of the
>maximum bandwidth, event at most busy hours.
> 
> 
> Looks like a healthy network, doesn´t it? Quite
> probably web browsing users will feel happy, and
have >no reason to blame the core of the network.
> 
> 
> Then come people with some voice and video
> applications and tell us that they have some special
>needs to run their stuff:
> 
> - the packet transmission delay shall not exceed
> much the time that light takes to cover the distance
>between the sender and the receiver;
> 
> - the jitter must be low, i.e., the delay must not
> vary much, nor very fast.
> 
> - very few packet discards.
> 
> 
> Ok, given these needs, what can one expect from the
> above mentioned happy and healthy net? Will it fit
>the needs? Most of the time? Half the time? Hardly?
> 
> I know that many of you will tell me "it depends"
> but definetly this is not an acceptable answer.
> 
> Well, to be honest, in this area the questions are
> not acceptable neither.
> Most of those quality demanding applications will
> decline from quantifying their needs: how much of
>packet loss, jitter and delay will they live with?
> 
> 
> But, event if they were to express precise needs ...
> would a network operator be able to anticipate
>success of failure ?
> 
> It would be much easier to think abut this problem
> if we had a deeper insight on what goes on with
>router queues.
> 
> Again, I am supposing an *uncongested*  and sane
> network, where only fifo queueing is used.
> 
> 
> 
> According to what many people say, even on such a
> network short traffic jams can occur, and that are
>accomodated on queues.
> 
> But ... how often? And how big does a queue grow
> when it happens?
> 
> 
> 
> -Alexandre.
> 
> 
> 


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com