cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
728
Views
5
Helpful
9
Replies

QoS - dynamic rapidly changing profiles - impact on end user ?

_|brt.drml|_
Level 1
Level 1

Hi, 

for a client and a non SD-WAN environment. 

Situation: 

The client has a 4G connection. When sailing, and he moves away from the antenna, the signal loses power and therefore weakens. Furthermore, the available bandwidth drops as wel. 

Problem:

I work with a fixed QoS profile on the interface. 

 

What I did: 

I measure with IP SLA the RTT and the threshold triggers an EEM APPLET. Seems to work in the lab. 

 

Question:

What if, the QoS Profile changes and changes and changes again... I mean, It could be that the signal is lying. I added the delay and up timers. But, what happens If I change after 5 seconds up time my QoS Profile. What happens to the traffic inside the 'old-queue'? 

I wonder if this solution will be negative for the end user? 

 

Any idea or experiences?  

9 Replies 9

Hello,

 

I think what you have come up with is a pretty ingenious solution to be honest.

 

I (sort of) lab tested this, changing the 'bandwidth percent' value in the QoS class, and it does not seem to affect existing streams. That said, what is the range of your configured QoS profiles, that is, how much do they differ ?

Well honestly I jump from

First= 20000 bandwidth qos-reference is with connection RTT less than 50ms

20000/2 = 10000 bandwidth qos-reference is with connection RTT more than 50ms less than 100ms

20000/4 = 5000 bandwidth qos-reference is with connection RTT more than 100ms less than 150ms

20000/6 = 2500 bandwidth qos-reference is with connection RTT more than 150ms

After this I noticed that the connection will drop. SAT takes over [this RTT delay is where there is no more advantage]

Downside:

With the sole problem that I have to give in into the effects of bad or good qos.



Still need to test this on the live environment.



And thank you for the ingenious remark - I'll pass this to my boss (LOL)






Hello,

 

I know that in DMVPN, there is something called adaptive shaping. I am thinking that although your solution is very good, there should be a way to automate this even more (and without EEM). Can you check if the below is available on your device ?

 

policy-map parent-policy-name
class class-default
shape adaptive { upper-bound bps |percent percentage }[lower-bound bps| percent percentage]

Joseph W. Doherty
Hall of Fame
Hall of Fame

From experience, I haven't noticed an adverse impact to a network applications when changing a QoS policy on the fly, even during production hours.  But this might have been as much due to there being "few" in-flight packets and/or just a "one-time" blip.

I don't recall seeing any "standard" (found on Cisco's main site) documentation surrounding the actual impact, if any, when making QoS changes.  It's possible, something like this might be documented in some prior Cisco Live presentation, which you might search against here.

Interestingly, the approach you're using is one I would have done years ago, myself, but back then, EEM either didn't exist, or was just starting to roll out.

As an aside, though, why are you doing this?  The reason I ask, unless you're shaping to manage multiple queues, there's not much reason in doing this.  Although, if you're only supporting one queue, shaping might still be of benefit for single queue management, such as using (W)RED, tiered drops or queue size, but otherwise, what benefit do you expect to obtain?

Mr Doherty,

Thank you for reply. I'll have a search.

Reason why.

We are shaping the 'wan' exit.

Our centralized Hub does the same. Problem is, those are fixed policy-maps with multiple classes. I'm hoping that via the EEM/IP SLA that I can manage the changing bandwidth iot obtain a better user experience. If I have a too large bandwidth in the shaper then I'll never have QOS doing it's thing. Correct, not?

The private company told me that the beginning bw for the 4G is around 20Mbps. Depending on the distance this will lower down.

The intent is to measure the delay and therefore the quality. (Other solution is with MOS value for voice- that will be the alternative). If certain value is measured it shall trigger the script. Seems to do the job. Today, finally real testing with live gear and not in modelling labs.



sincerely


"If I have a too large bandwidth in the shaper then I'll never have QOS doing it's thing. Correct, not?"

Correct.

Again, though, you've not made clear how your using your QoS.  VoIP alone, benefits little from QoS.  VoIP with other traffic, though, can benefit very much from QoS.

If you are doing VoIP with other traffic, ideally, you want to keep the non-VoIP traffic from being adverse to VoIP traffic.  This would mean slowing non-VoIP traffic at even a hint of lost bandwidth, or only using whatever bandwidth you're sure is actually available.  (A simple approach, would be shape, all the time, for what should be the worst case for bandwidth provided. Unfortunately, doesn't take advanage of bandwidth that's actually available.)

BTW, in theory, it shouldn't be all that difficult to obtain some measure of available bandwidth, but the level of access needed, generally isn't available on a Cisco router.  However, in the past, for a while, Cisco provided Corvil's bandwidth estimator agent.  Somewhat similar products noted in this (old) article, which might be worth reading for additional ideas on what you might be able to do.

Also that's an interesting idea to using a MOS value, but I would be concerned your QoS would only react (late) to a problem, where, again ideally, we don't want a problem (in something like VoIP) to appear at all.

VoIP and Video are separated in a priq. Other classes are typically interaction, bulk, etc.. Pretty much following the standard. We especially benefit a lot from QoS when using our type of links (radio, lte, sat etc.). I've learned a lot in theory, but saw the effects in reality as well. QoS is importand. I remember a previous post with you, where you where helpful in guiding me to some new information that changed the policy-maps.



The percentage attributed to different classes, including the voice and video stays the same. We only need to adapt bandwidth according the distance to the signal source antenna. It are vessels that can be at the 'fringe' of the signal, but can also be in a situation where they toggle between a good and a bad signal. That is what I also hope to 'not' trigger.



I'll read the suggested article.



For MOS value.

I did some tests, it does work, however I need more testing to know when and how the MOS value is calculated.



Thank you for your help and confirmation.






"I've learned a lot in theory, but saw the effects in reality as well. QoS is importand."

I too consider QoS important.  Unfortunately, most don't consider using it except when there's need to support real-time traffic, like VoIP and/or video conferencing.

 

Now mounting my soapbox. . .

Three stories I like to tell (probably have noted one or more, over the years on these forums), which show benefit of QoS, are centered around a fairly good sized German international firm I worked at a couple of decades ago.

The German firm split its network management into 3 regions, Europe/Africa, Americas, and Asian/Pacific.  Although German networking management had over site for the whole international network, they allowed the two other regions much freedom in how corporate networking goals were obtained.  (Later, when the firm did start to use real-time apps like VoIP and video-conferencing, then QoS was "needed", but of course [laugh] they [German HQ] weren't much interested in our several years experience using QoS.)

When I came on-board, in the America's HQ, I suggested QoS might mitigate the constant complaints, from the other offices, how poorly the networked performed.

America's network management allowed me to implement QoS between our regional HQ and all the other regional offices (varied between 80 to 100).

Interestingly, the WAN lead engineer, thought QoS was just useless voodoo until the morning he came in and noted his phone was lit like a "christmas tree" with most remote offices complaining what's wrong with the network?

He discovered one of our HQ WAN routers crashed, the prior night, rebooted itself, but without its QoS configuration.  He reapplied the missing QoS, and the phone calls stopped.  (BTW, this was pre any real-time traffic being on the network.)

About a year later, we were hosting the twice a year principle network engineers' meeting, where all 3 regions engineers met.  (NB: the meetings rotated through the regions.)  One big complaint, from the other regions was "no matter how much bandwidth, we appear to add [to the WAN], users keep complaining how poorly the network performs".  I noted, since we've implemented QoS, we no longer get those complaints and now very seldom upgrade WAN bandwidths (BTW, at that time, possibly saving us about $100,000 a month).  Other regions' engineers response, don't see any need for QoS, as we've don't have any real-time traffic.

Lastly, we had a major regional office in South America, whose dual (E3) WAN links ran at 100% all day long during business hours.  Those links carried all forms of traffic, from VoIP (by that time we had moved to it), to video-conferencing, to email, to Citrix like apps, to "critical" web apps, to SAP apps, to FTP and Windows file copy traffic, to database replications, to client backups, to other sundry apps.  All worked as expected, without complaints.  Why?  QoS!

So, again, I too consider QoS important.

That reads so familiar :)Thanks for your time. Wish you all the best !


Review Cisco Networking products for a $25 gift card