> > 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 <beec...@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