Help Understanding User-Defined Traffic Prioritization Rules

[Snapcaster]

Hello friends,

I am using the following:

Board Model		XR300
Firmware Version	1.0.3.72_10.3.55
DumaOS Name		A7Legit

I'm trying to understand exactly how my router implements custom "Traffic Prioritization" QoS rules.

As I understand it, network devices communicate like this:

TCP_80 Example:

	1. A device initiating a connection on TCP_80 will choose an unregistered TCP port at random (often called an "Ephemeral Port")
	   For this example, lets assume TCP_34567 was chosen.

	2. The initiator will send something to the target device.
	   It will use a source_port of TCP_34567 and a destination_port of TCP_80.

	3. The target device will respond to the initiator.
	   It will respond using a source_port of TCP_80 and a destination_port of TCP_34567.

	4. For as long as the connection remains - 
	   a. The initiator will use a source_port of TCP_34567 and a destination_port of TCP_80.
	   b. The responder will use a source_port of TCP_80 and a destination_port of TCP_34567.

Consider the following:
 - I have a LAN device that uses a service on some port.
 - The device's private IP is 192.168.1.2, and the service it uses operates on port UDP_1234.

My ultimate goal is for my XR300 to prioritize all traffic that is:
   1. sent FROM 192.168.1.2 using a destination_port of UDP_1234
   2. sent TO 192.168.1.2 using a source_port of UDP_1234

How many user-defined rules do I need to achieve this?

For outbound traffic, UDP_1234 is the destination_port.
For inbound traffic, UDP_1234 is the source_port.

Most importantly - when creating a rule for a device, should the source/destination ports be entered as if the device is receiving or sending?

[Netduma Liam]

Welcome to the forum!

Traffic Prioritisation works by identifying outgoing priority traffic, in your case traffic on a specific port, and sending it out ahead of any other background traffic on the router.

It does not work by prioritising traffic that is being received by the router, it can't work like that.

For you scenario, you'd want to add a Traffic Prio rule using source ports 1-65535, and destination ports 1234.

I hope that makes sense, let me know if you have any other questions.

[Snapcaster]

3 hours ago, Netduma Liam said:

Welcome to the forum!

Traffic Prioritisation works by identifying outgoing priority traffic, in your case traffic on a specific port, and sending it out ahead of any other background traffic on the router.

It does not work by prioritising traffic that is being received by the router, it can't work like that.

For you scenario, you'd want to add a Traffic Prio rule using source ports 1-65535, and destination ports 1234.

I hope that makes sense, let me know if you have any other questions.

Thanks Liam,

But, if Traffic Prioritization is only applied to outgoing traffic, what do the High Priority Download packets represent on the Traffic Prioritization meter?

 

[Netduma Liam]

25 minutes ago, Snapcaster said:

Thanks Liam,

But, if Traffic Prioritization is only applied to outgoing traffic, what do the High Priority Download packets represent on the Traffic Prioritization meter?

Oh no my apologies, it works both ways in that sense yes.

What's your use case? Perhaps that'll help us understand a little more and help you tailor some Traffic Prio rules.

 

[Snapcaster]

6 hours ago, Netduma Liam said:

Oh no my apologies, it works both ways in that sense yes.

What's your use case? Perhaps that'll help us understand a little more and help you tailor some Traffic Prio rules.

 

I ended up just brute-forcing a solution by prioritizing ALL traffic to/from my device.

I created one rule like this:

myDevice
Source Port: 1 - 65535
Destination Port: 1 - 65535
Protocol: TCP & UDP

It’s not elegant, but it seems to work.

[Netduma Fraser]

That would work but not ideal, in theory, if you know the exact source and destination port and it doesn't deviate from that at all then just putting the same port for source and destination would work, is that something you've tried?

[Snapcaster]

2 hours ago, Netduma Fraser said:

That would work but not ideal, in theory, if you know the exact source and destination port and it doesn't deviate from that at all then just putting the same port for source and destination would work, is that something you've tried?

Maybe I'm not understanding what each field does when creating a rule...

If the above rule is for a device called My_Device, my impression is that the rule would work something like this:

1. Router sees a packet.
2. Is the packet associated with My_Device in some way?
   (This step is mysterious to me and I have no idea how it works.)
   (You are forced to chose a device when creating a rule.)
   (It's totally unclear what choosing the device actually does.)
   (Does it make the router care about packets SENT TO the device?)
   (Does it make the router care about packets SENT FROM the device?)
   (Does it make the router care about any packet sent either TO and FROM the device?)
   (All three options seem equally reasonable. PLEASE TELL ME IF YOU KNOW)
3. Is this a TCP packet?
	NO -> Do nothing and go to next packet
	YES -> Is the source port of this packet in the range 1024 - 65535?
		NO -> Do nothing and go to next packet
		YES -> Is the destination port of this packet 80?
			NO -> Do nothing and go to next packet
			YES -> Prioritize this packet and go to next packet

I don't believe a packet is allowed to have a source port that is the same as it's destination port.
If the rule fields work like above, then setting all the source and destination fields to the same port wouldn't make sense.
There would be no packets that meet the prioritization criteria.

Unless I'm totally wrong about what the rule fields do.
Please help.

[Netduma Liam]

The rule relates to all traffic going to and from a device. As far as I'm aware, your understanding in point three is correct. If the source port of the packet matches your range, as does the destination port, then the traffic is prioritised.

Again, it would be easiest for us to know your use case here, it'd be much easier to advise you properly if we knew what this is for.