cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1950
Views
19
Helpful
9
Replies

Link utilization impact on responsiveness

from88
Level 4
Level 4

Hello,

 

I'm reading a book, and here it says:That as the link utilization grows (even from 10% to 50%) the responsiveness time grows. I always thought that if the link is ~90proc utilized, then the drops can occur. Can someone explain from physics field, why the utilization till ~50% increases the latency. If we would have a 10gb link and it will be utilized 50% the user will feel bigger latency than the link utilized ~20% ? Why ?

 

 

Picture attached.

1 Accepted Solution

Accepted Solutions

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

"so the conclusion is the queue limit has higher chances to be reached as the link utilization exapands , am i right ?"

Correct, and if there more packets queued, there's more chance for queuing latency.

View solution in original post

9 Replies 9

Joseph W. Doherty
Hall of Fame
Hall of Fame

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

The interrelationship between link loading and latency (and drops), and its impact to traffic, is much, much more complex than what that text is explaining.

Without touching on the many, many variables involved, I suspect what the text is alluding to is latency that exponentially begins to increase as utilization approaches 100% due to queuing delays.  Simple queuing theory would, with utilization below 50%, (rarely) should there be more than one element queued.  Once, however, utilization rises above 75%, elements queued will start to skyrocket.  This is what the first graph is showing.

In simple queuing, we normally allow for an infinite queue, but we certainly can decrease possible latency by limiting the possible queue depth.  Of course, in real networks, a high drop rate generally is adverse to most traffic too.  I.e. even though you can avoid high latency, high drops might actually be even more adverse.

If you search the Internet, you can find simple queuing calculators which will, given a certain load percentage, show you what the average queue depth will be at that load percentage.

In any case, again, real world link loading, and it's impact to traffic, is very complex.  Depending on the needs of the traffic, even 30% utilization might be too high while conversely 100% utilization doesn't always mean you need more bandwidth.

thanks... but if we using just simple FIFO queuing, i still cant understand why latency on link utilized 50% is higher than on link utilized ~20%..

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Because at 50% utilization you're more likely to queue than you do at 20% utilization.  The more that's queued, the more the average wait time (i.e. latency) increases.

BTW, this is also assuming FIFO queuing.

thanks for answer.

 

But sorry for another dumb question, if the utilization doesn't reach the 60% why the queuing is needed at all ? All traffic should egress without any delay, as far as i know, the queuing (qos)  is needed when the link is utilized.

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Because even at much, much lower utilizations, queuing is still possible.  What differs is the probability of queuing and the probability of how deep the queue might be.

Also, in real-world networks, usually utilization is a measure of capacity used over some time period.  It may very badly portray what's happening down at the millisecond level.  For example, 20% utilization, over 5 minutes, would result from 100% transmission rate over 1 minute, or 200% transmission rate over 30 seconds.  The latter would create a queue.

as i understand you're talking about some burst traffic, yes ? I agree then it would be drops. But if we are 100% sure, that traffic is not burstable (for example) the traffic is policed in other device so, there would be no congestion even at milliseconds level.

 

Now im thinking that the picture and the text took in a account possible bursts and that explains how responsivness can increase.

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

"Burst traffic", yes and no.

Simple queuing theory assumes randomly distributed ingress traffic.

However, in networking, we're often dealing with ingress bandwidth that oversubscribes the egress bandwidth, especially when dealing with WAN links (as your text mentions).

For example, assume a server has a gig LAN connection but your WAN connection is only 10 Mbps.  The moment your server sends a file that's larger than one packet can contain, subsequent packets will queue.  Yet, since the file is of finite size, the transmission may stop with just the one file.  So, again, depending on how many files are requested, and how large each is, your utilization might be low, but during the actually transmission (at 100x the egress bandwidth), you're packets are going to be queued (or dropped).

Then, even on LAN, you often have multiple ingress ports to the an egress uplink port.  Consider 24 gig ports but a single gig uplink port.  Now assume more than one edge port host transmits at the same time.  Again, you'll have queuing and/or drops, how much, and what you're utilization stats show depends on your edge hosts transmission behavior.

Regarding policers, they allow bursts.  What they do is drop packets to try to maintain some longer term usage average, but actual transmission rate is wire speed, not policed rate.

thanks again

 

"The moment your server sends a file that's larger than one packet can contain, subsequent packets will queue. "

 

One packet in standard term can be 1500bytes, so you're about the case when the packets is divided in fragments, and there is somewhat called a "queue depth" ? and here is the limit which cannot be exceeded ? :)

 

so the conclusion is the queue limit has higher chances to be reached as the link utilization exapands , am i right ?

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

"so the conclusion is the queue limit has higher chances to be reached as the link utilization exapands , am i right ?"

Correct, and if there more packets queued, there's more chance for queuing latency.