Re: Bottlenecks and link upgrades

[Etienne-Victor Depasquale <edepa () ieee org>]

> There is rarely a one sized fits all answer when it comes to these
> things.

Absolutely true: every application has characteristic QoS parameters.

Unfortunately, it seems that 5-minute averages of data rates through links
are the one-size-fits-all answer ... which doesn't fit all.

Etienne

On Thu, Aug 13, 2020 at 5:37 PM Tom Beecher <beecher () beecher cc> wrote:

> Wouldn't it be better to measure the basic performance like packet drop
> > rates and queue sizes ?
>
> Those values should be a standard part of monitoring and data collection,
> but if they happen to MATTER or not in a given situation very much depends.
>
> The traffic profile traversing the link may be such that the observed drop
> % and buffer depths is acceptable for that traffic, and there is no need
> for further tuning or changes. In other scenarios it may not be, in which
> case either network or application adjustments are warranted.
>
> There is rarely a one sized fits all answer when it comes to these things.
>
>
> On Thu, Aug 13, 2020 at 6:25 AM Olav Kvittem via NANOG <nanog () nanog org>
> wrote:
>
> > On 12.08.2020 09:31, Hank Nussbacher wrote:
> >
> > At what point do commercial ISPs upgrade links in their backbone as well
> > as peering and transit links that are congested?  At 80% capacity?  90%?
> > 95%?
> >
> >
> > Hi,
> >
> >
> > Wouldn't it be better to measure the basic performance like packet drop
> > rates and queue sizes ?
> >
> > These days live video is needed and these parameters are essential to the
> > quality.
> >
> > Queues are building up in milliseconds and people are averaging over
> > minutes to estimate quality.
> >
> >
> > If you are measuring queue delay with high frequent one-way-delay
> > measurements
> >
> > you would then be able to advice better on what the consequences of a
> > highly loaded link are.
> >
> >
> > We are running a research project on end-to-end quality and the enclosed
> > image is yesterdays report on
> >
> > queuesize(h_ddelay) in ms. It shows stats on delays between some peers.
> >
> > I would have looked at the trends on the involved links to see if upgrade
> > is necessary -
> >
> > 421 ms  might be too much ig it happens often.
> >
> >
> > Best regards
> >
> >
> >   Olav Kvittem
> >
> >
> >
> > Thanks,
> > Hank
> >
> >
> > Caveat: The views expressed above are solely my own and do not express
> > the views or opinions of my employer

-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale