If you are using your local internet connection at home for IP-based phone or video calls, maybe participating or even hosting online meetings and webinars, you already might have heard about something like Quality of Service (QoS), IEEE 802.1p precendence, Differentiated Services or just traffic prioritization before. Traffic prioritization is about handling data packets according to their importance, which basically means that packets that are timecritical or should not be dropped on connection congestion will be send out first.
why Traffic Prioritization is needed
Network packet drops or delays will most likely happen at places, where too much traffic is aggregating and needs to be send out on a network link that just can‘t handle that amount of traffic with the same speed (amount of data divided by time). I would like to point out two things here, which are highly important to remember:: a) we can only apply packet prioritization on any device in egress (ie. outgoing) direction – this does not work on ingress traffic (ie. incoming) and b) as soon as the traffic leaves your controlled network environment, there is no traffic prioritization warranty anymore, which is especially true for the whole internet (at least as long as no provider has some special contract with a content provider to prioritize let’s presume their advertizing video streams) . Let me give you some examples here:
- multiple clients accessing the network using a single wireless access point
- multiple devices on a single network switch, where the traffic destination for all those devices is reachable by a single specific port on that switch
- your internet router, where all devices of your household are connected by about gigabit network speed and have to access the internet with a link which only have about 1-10% bandwidth on upload
As the internet router is the one device where link congestion will happen most often, this is the one that we will be looking at within the scope of this article. As I only use AVM FRITZ!Boxes everywhere, I will use those as an example. I have seen some other ones in between and their configuration is done in a similar way. Please take note, that there are certain routers that can’t be configured for traffic prioritization specifically, although they support it internally already as it is required to get internet telephony or internet TV working properly. Those routers branded with the internet provider logo are the most likely ones where you will not be able to configure it to your needs.
what happens on link congestion
What happens on link congestion largely depends on the TCP/IP protocol used. TCP or transmission control protocol is a verified transmission of data. If a packet does not arrive at the destination or has a transmission/data error, it is requested/resend again – so arrival is guaranteed, but might be delayed. If UDP (user datagram protocol) is used, the packets are send blind without checking for proper transmission or recieval at the other end. In case of network congestion, UDP packets will just be dropped at the congestion point. As you might imagine, delaying data which is expected to travel in real-time, will have noticable impact.
If a certain amount of packets is dropped on audio calls, the quality of the call will drop, the voice may get scrambled, audio could stop and resume intermittently and in worst case the complete call will drop. Which makes audio in many cases the most critical data. Video will get pixelated or freeze, but in many cases quality (resolution) will just be reduced. Video is still important, but not as critical as voice – without voice the call or meeting is useless. For online gaming you might want to ensure that your clients communication to the game‘s server is prioritized against other traffic, so that the server knows what you are doing with the least latency possible. And there might even be traffic, where you do not care if that traffic is delayed at all when higher precedence packets are about to be submitted – backup traffic would be a nice fit for that category.
how Traffic Prioritization solves this issue
Network equipment which supports Quality of Service has a mechanism to detect packets based on different criteria and sort them into different queues, from where they are then transmitted according to priority. Digging into this deeper is getting quite complex and requires a ton of network and network protocol knowledge, so we will only touch on what is required here to understand how that works on a high level point of view. A FRITZ!Box is investigating only the traffic directed to the internet and checks the following details:
- originating IP address of the internal client
- to map to a specific device is known or all computers on the network
- network protocol used
- TCP, UDP, ESP, GRE or ICMP (we will briefly touch ESP, GRE and ICMP later)
- source port used
- to send out that traffic from the originating device on your network
- more granular than the IP address and can in many cases be mapped to a specific application
- destination port where the traffic is sent to on the internet
- remember: only works on egress traffic to internet
Knowing which details are checked is necessary for us to know what we need to look out for in the software documentation to be able to prioritize outgoing traffic. Traffic prioritization is most important to do on the usually largest network congestion point called internet router, where bandwidths drop drastically and/or many devices connected to the same network device will have to share the same network link. The more devices sharing the link and the smaller that link is, the more important it will become.
Yes, you can additionally apply traffic markings for prioritization directly on the clients using the group policy management on Windows, but you will need to have network equipment that supports prioritization based on those markings and it must also be configured to do so. For mobile devices running Android or iOS client-based traffic tagging is prohibited by the operating system, so in case you have wireless access points and want to tag and prioritize internal network traffic those must be able to detect the application used directly within the received traffic stream in real-time and apply prioritization appropriately. You can already imagine that this requires higher-end equipment and some expert knowledge in network engineering, so we are skipping that topic here.
Getting back to our FRITZ!Box again, that little router has 4 internal outgoing queues that we can use for prioritization. In decending order from highest to lowest priority these are:
- real-time traffic
- try to use this class exclusively for audio communication
- prioritized traffic
- everything video, screen sharing, presentation, remote desktop should go here
- normal traffic (also called best effort)
- the class which is assigned by default
- background traffic
- all traffic that can wait and/or is taking place in background
- usually without being directly visible or noticable to the user
- eg. data backup to internet storage or file data sent out from a service running on your devices
Important information:
Many services are using http (tcp on port 80) or https (tcp on port 443) to communicate with internet-based services. I highly recommend to not create any rules prioritizing this kind of traffic based on ports, as it will affect all those services and webbrowsing at once. Just some examples here: Teams as well as Zoom use https on port 443 to login to the client, transfer information from and to the client and it can be used as failback for meeting data transfer, if a direct connection to the specific ports cannot be used because the communication is blocked somewhere. You want to only prioritize traffic from a single application and not doing a catch-all. In case of catch-all or near catch-all it will bypass your carefully designed traffic prioritization approach by just putting everything into the assigned priority queue instead of the normal one.
Cleaning up and get started
So, let‘s get this implemented now. Open the webbrowser of your choice and navigate to your FRITZ!Box‘s homepage, which by default should be reachable on http://fritz.box and log in there. Navigate in the left menu via ‘Internet’ to ‘Filters’ and select the ‘Lists’ tab. Expand the ‘Network Applications’ area. As the FRITZ!Box already comes with some predefined network applications, which are kind of non-sense, just remove everything that can be deleted out there. Add now let’s add our first own network application by clicking on the appropriate button.
Adding a Network Application and defining protocols used
I am choosing to add ‘WLAN Calling‘ here, which is a functionality that every smartphone should be capable of by now. You might need to enable that feature on your phone first, but if enable and you are logged in to your WiFi it will use your internet connection to receive and place mobile phone calls. That option will help you a lot, if your mobile operators network signal strength is quite low inside your flat or building. Please note that you should not walk out of the wireless network range when placing a call this way – on wifi connection loss the call will most likely drop. Put in the name of the application to the field top left and start adding the first protocol.
As the type of WLAN Calling connection used will mostly differ by mobile operator, we’ll add a whole stack of protocols now – just based on what I have seen being used in the past years. WLAN Calling worked on all mobile operators I have been using in the same way so far. The mobile phone is building an VPN tunnel to the operator systems – which is an encrypted link end-to-end via Wireless throught the internet, which effectively makes WLAN Calling Voice-over-IP and therefor it should be properly prioritized. For the first protocol entry select the ESP protocol. ESP is the abbreviation for Encapsulating Security Payload, which means that this is the payload transmitted on using WLAN Calling.
Now we add the second protocol to the WLAN Calling network application. UDP for destination port 500 this time. This port is used for the key exchange to verify identity of the devices which are connecting, authenticate the connection and encrypting the data transferred on the ESP protocol.
And here comes the third and final protocol – UDP on port 4500 for NAT Traversal. Most internet routers have only one public IP, which requires that all traffic send from multiple computers or devices inside the home network to be labeled with this public IP for transportation on the internet. This process is called NAT – Network Address Translation. But this creates a problem for the traffic that is sent back from the server to the client on the home network. When those ‘answer packets’ arrive at your internet public ip address the router has to touch those and overwrite the public ip address with the internal ip address of the computer where those traffic needs to go to. This modification of the packets will break their integrity, the receiving client will detect this and just drop them. So the traffic is packed into another packet instead of being modified, and doing that (repacking and unpacking the traffic) is the job of the NAT Traversal.
Now do a final check on the protocols that have been set up and confirm with OK if everything looks good.
Assigning Network Applications to priority queues
Now we’ll set up the Network Application to prioritization queue assignment to classify the data. Therefor move over to the ‘Prioritization’ tab.
Here you can see the queues. Real-Time Applications will have the highest priority and are allowed to consume ALL! the available bandwidth. That’s why my recommendation is to only put pure voice traffic in there. You should usually not be able to congest your complete internet bandwidth with only voice traffic. A single phone call should not use more than 64kbit/s usually, worst case 128kbit/s. Whenever there is something in the queue for Real-Time Applications, it is always send out immediately before the router even looks into the lower-priority ones. If that one is consuming your whole bandwidth, all other traffic will not be send out at all.
Prioritized Applications is lower than Real-Time but higher than normal or Background Applications. Here some unknown percentage is used against the lower queues. Using this class to the brim will not stop traffic from the normal class or Background Applications to be send out, they will just be on lower priority and get less usable bandwidth assigned. I recommend to use this class for outgoing video traffic, remote support applications, screen sharing, online gaming etc. If a video communications application does not allow for separating the audio traffic from the video or presentation traffic, I suggest to put it into the real-time applications to stop audio from dropping when using those. At latest now you should notice that the normal class is not displayed at all. Well, it is the default class, where everything ends up which is not assigned somewhere else already.
Background Applications is the lowest priority class. In case of bandwidth suggestion, that queue is limited to a relatively small percentage of your upload bandwidth to ensure that enough bandwidth for the more important traffic is still available.
Let’s add our newly created Network Application now.
For client-side applications where the server or service is located on the internet, ‘all devices’ should be fine in most cases. If you select a specific client there, you need to ensure that this client does not switch between WLAN and LAN connection – this would make him appear as two devices. And you would need to add each single device later on, where this prioritization should kick in as well.
If you are hosting your own services inside and those are reachable from the outside, you can select the server there and use prioritization on the traffic the server is sending back to the clients on the internet. I am using this setup for my TeamSpeak server hosted internally and available from the internet to ensure that the voice data sent from server to clients is prioritized.
There are some specific things, which I would like to point out here:
- for audio/video conferencing devices, pure SIP phones etc. – put those devices by name and all applications onto real-time
- servers running only background traffic can be put into background applications the same way
Finally, select the created Network Application. Please do NOT select ‘All’, this will create issues somewhere down the road over time.
You should now be able to see the added Network Application inside the corresponding queue and the setting is active now.
quite important hint:
Somehow the bandwidth reservation setting that ensures that the guest network cannot get all the bandwidth is broken – at least here it leads to an effect where usable bandwidth is limited to an amount that basically disables internet usage for more than text messages. Had to switch that off.
full assignment example
A nicely done traffic prioritization backup might look like this:
You might notice that I put Zoom Meetings and Facetime into Real-Time Applications, which is not what I basically recommend as I cannot clearly separate audio from video there – but I am in the lucky position to have enough upload bandwidth on this internet access I am using for this tutorial creation and I do not expect that much concurrent users using these applications at the same point in time. Bandwidth will still be fine as long as video cameras do not increase to tons of megapixels soon.
Traffic Prioritization monitoring
If you want to check if your Network Application protocol definition and queue assignment is working, you can use the Internet – Online Monitor feature and check the upstream chart there when using the app.
Network Application protocol definitions
As I have quite a lot of Network Applications configured and had to search to get the protocol definition, I will share my definitions here. I am skipping on all protocol definitions, that contain http or https basic well-known ports due to be used for multiple applications and all standard browsing traffic – prioritizing that traffic will not bring any benefits, if a target IP or URL cannot be defined.
| Network Application | Protocol | Source port | Destination port | recommended class |
| WLAN Calling (had issues!) | ESP | any | any | Real-Time |
| UDP | any | 500 | ||
| UDP | any | 4500 | ||
| Teams-Audio | UDP | 50000-50019 | any | Real-Time |
| Teams-Video | UDP | 50020-50039 | any | Prioritized |
| Teams-Sharing | UDP | 50040-50059 | any | Prioritized |
| TeamSpeak 3 Client | UDP | any | 9987 | Real-Time |
| TeamSpeak 3 Server | UDP | 9987 | any | Real-Time |
| FaceTime | TCP | any | 5223 | Real-Time |
| UDP | any | 3478-3497 | ||
| UDP | any | 16384-16387 | ||
| UDP | any | 16393-16402 | ||
| RDP Client | TCP | any | 3389-3391 | Prioritized (caution: file transfers) |
| UDP | any | 3389-3391 | ||
| AnyDesk | TCP | any | 6568 | Prioritized (caution: file transfers) |
| TeamViewer | TCP | any | 5938 | Prioritized (caution: file transfers) |
| UDP | any | 5938 | ||
| Zoom Meetings (not phone or room) | TCP | any | 8801-8802 | Real-Time |
| UDP | any | 3478-3479 | ||
| UDP | any | 8801-8810 | ||
| Zoom Phone/Rooms (on top) | TCP | any | 5091 | |
| TCP | any | 390 | ||
| TCP | any | 8888 | ||
| UDP | any | 8889 | ||
| Steam | TCP | 27036 | any | Prioritized |
| UDP | any | 27000-27100 | ||
| UDP | 27031-27036 | any | ||
| UDP | any | 3478 | ||
| UDP | any | 4379-4380 | ||
| Portainer Server | TCP | 9443 | any | Background |
| TCP | 8000 | any | ||
| Portainer Edge Agent | TCP | any | 9443 | Background |
| TCP | any | 8000 | ||
| DNS | TCP | any | 53 | Prioritized |
| UDP | any | 53 |