To answer your question: if, under /interface bridge settings, you set use-ip-firewall=yes, you can refer to in-bridge-port in the firewall rules used to mark packets for queueing. Or, if the traffic between LAN and WAN is routed, you may remove port 5 from the bride, create a dedicated subnet for the streamer and attach it directly to port 5.
However, I wonder how your whole setup looks like, and especially what kind of other traffic it is that competes with the streaming one. What is the actual issue, and why do you think that prioritizing the streamed video, which effectively means throttling other traffic, will resolve it?
Well, to me it seemed most likely that it is actually the number of remote clients subscribed to the live “broadcast” that exhausts the uplink bandwidth during the service. If the guests run their own live broadcasts (or take videos and store them into cloud online, that’s the same bandwidth-wise), or if you have a half-duplex uplink to the internet, such as a WiFi-based one, where upload and download share a common bandwidth, that’s a different case of course.
As usually with QoS, you need to classify the traffic and to enforce the bandwidth for each class.
As you’ve mentioned you wanted to prioritize the complete traffic of the encoder, you can use the information about the src-address (of the encoder), rather than the information about in-bridge-interface, to classify the traffic for use of the right queue without need for the reconfiguration I’ve suggested.
So for a full duplex uplink, i.e. where the bandwidth for upload and download is independent, and if the traffic between LAN and WAN is routed, the whole solution would look as simple as follows.
This rule must not be shadowed by any other one in chain=prerouting of /ip firewall mangle, nor must any other rule change the packet-mark assigned by this one, but I suppose you currently have no mangle rules at all. You don’t need to packet-mark any other traffic than the one from the encoder.
The first queue limits the total bandwidth below the physical speed of the Ethernet link which connects your Mikrotik to the uplink gear, to the actual throughput of the uplink, which you’ve stated to be 50 Mbit/s; as it has the uplink interface as a parent, all its children only serve the upload traffic, whereas the download traffic bypasses any queueing.
The second queue is a child of the common one and guarantees the complete bandwidth to be given to packets marked with a packet-markencoder if they come.
The third queue is another child of the common one and it holds all the other traffic, thanks to matching on packet-mark=no-mark; since it has no guaranteed bandwidth (no limit-at value), the traffic handled by this queue only gets the badwidth that the other child queue did not use.
There is no priority specified because in this simple case, it is implicit: the encoder-ul queue always wins because it is the only one with limit-at set above 0. Priority is only needed to control how the bandwidth unused by other queues will be distributed among multiple child queues.
Any answer can only be as detailed as the question is, hence:
not knowing the protocol the encoder uses, I have no idea whether it depends on any feedback traffic; if it does, you also need to prioritize the feedback traffic over any other download traffic.
if the encoder eventually sends the stream to a server somewhere in a datacenter, which provides its replication to the actual subscribers, you can set the limit-at value of the respective queue to the actual maximum bandwidth of the stream rather than the total bandwidth of the upload direction of the uplink
for a half-duplex link, the setup would have to be different
if the traffic between LAN and WAN ports is actually switched, the setup would have to be slightly different as well
Wow!! Thank you for all of the information and the actual way to execute this!!
We are broadcasting our stream to a company on the internet via the RTMP protocol. I do not believe that the unit requires any information back while streaming. All it does is send a MP4 compressed file via RTMP that gets rebroadcast.
We have a full duplex fiber link. True 50mb/50mb.
I am unsure of what you mean by LAN and WAN ports being switched… I have a DHCP server setup for the VLAN that the Encoder is on, and the RouterBoard is sending the traffic from port 5 to port 1. Also, not sure if this matters, i have 2 ports bridged together and instead of entering the dedicated IP
Fascinating topic and clear amazing education.
I would like to see your config to see if it can be further optimized in any case.
/export hide-sensitive file=anynameyouwish
@sindy Confirm once you start using mangle rules the router slows down (fasttrack has to be disabled in foreward fw rules) and if so by how much?? (What is the real effect)??
OK, so no need to worry about multiple streams occupying the downstream (from the encodes’s perspective) = upload (from the router perspective) bandwidth, and no dependence on any upstream=download confirmation packets.
OK, so no need to worry about the download direction at all.
It is hard to assess the knowledge of people on the forum from a few lines they post. It is not unusual that people call the box a router because it is sold as such, but actually use it as a managed switch. So I just wanted to know that there really is routing between the encoder port and the WAN one, as it affects the necessary configuration for QoS.
And here I’m unsure about your vernacular. Do you mean a port-based VLAN, i.e. in plain words a dedicated bridge with some (two in your case) member ports, while one of these ports is free and to the other one only the encoder is connected? Or you mean a tag-based VLAN, where the encoder port is an access port to one VLAN and the other port is an access one to another VLAN, while both VLANs exist on the same bridge? The thing is that /ip firewall rules match on L3 port names, so there is a theoretical chance that the native VLAN of the streaming_bridge is not the one used by the encoder, so the mangle rule could be theoretically matching other traffic than you expect.
I wouldn’t be this sticklery if it was clear from your OP that you have dedicated a bridge with an own IP subnet for the encoder, as I’ve assumed from that post that you run the default configuration where ether1 is WAN and ether2..ether5 are members of the same bridge, and want to prioritize traffic from one of the member ports (i.e. to distinguish the encoder traffic from other traffic coming in via the same L3 interface - the common bridge).
@anav, strictly speaking the router doesn’t slow down but has to spend more effort to handle a single packet. So the traffic may slow down as a consequence - if the CPU throughput becomes more limiting than the uplink bandwidth. A total throughput of 100 Mbit/s (50+50) may be close to the limit without fasttracking and with PPPoE for older devices. The manual shows the benefits of fasttracking on a RB2011; my test shows that difference for hAP ac² (where the limit with fasttracking at both ends may actually have been the link speed of the interface); both these tests only illustrate the benefits of fasttracking, not of the throughput decrease caused by mangle rules and queue processing.
It is noteworthy that CPU core load exceeding, say, 25% except short-time spikes is already dangerous for the traffic. E.g. an IPsec rekey process may easily cause drops of unrelated packets when it spawns while the CPU is almost fully occupied by packet forwarding. But it’s quite off this topic.
And here I’m unsure about your vernacular. Do you mean a port-based VLAN, i.e. in plain words a dedicated bridge with some (two in your case) member ports, while one of these ports is free and to the other one only the encoder is connected? Or you mean a tag-based VLAN, where the encoder port is an access port to one VLAN and the other port is an access one to another VLAN, while both VLANs exist on the same bridge? The thing is that /ip firewall rules match on L3 port names, so there is a theoretical chance that the native VLAN of the streaming_bridge is not the one used by the encoder, so the mangle rule could be theoretically matching other traffic than you expect.
I wouldn’t be this sticklery if it was clear from your OP that you have dedicated a bridge with an own IP subnet for the encoder, as I’ve assumed from that post that you run the default configuration where ether1 is WAN and ether2..ether5 are members of the same bridge, and want to prioritize traffic from one of the member ports (i.e. to distinguish the encoder traffic from other traffic coming in via the same L3 interface - the common bridge).
[/quote]
Thank you again for your input here. Im sorry my OP did not have all the details. I honestly am unsure of what information is relevant in seeking out help. I know enough about networking to be dangerous. I am not an expert in any way.
Port 1 = WAN
Port 2 = Goes to my network switch and carries 6 VLANs and DCHP information for everyone
Port 3 = Empty
Port 4 & 5 = Members of streaming_bridge and VLAN 7 is assigned here with a DCHP server handling this traffic.
I will find out this Sunday if I did this correctly!
I am concerned about the comments about the load on the CPU. Where would I track this to make sure that I am not asking too much from my RouterBoard?
As this description still hasn’t removed the doubts, can you just follow the instruction in my automatic signature below?
On the hardware product page, there is always a tab called Test Results; there, you are interested in the table under Ethernet Test Results. A rule of thumb says that the throughput stated for 512 byte packets is quite informative for a mixed traffic (it’s a sum of traffic in all directions, and TCP traffic like web browsing and file transfers tends to be mixed of one small packet per one to four large ones, whereas interactive traffic like voice and video calls use small-to-mid-sized packets in both directions); your throughput will be better than the lower one of the “25 filter rules” and “25 simple queues”, at least if you don’t use PPPoE on WAN.
Running /tool profile while the service will be broadcast will tell you what is actually going on, along with running queue tree print stats interval=1s in another window. If everything is fine, you should see no packets dropped for the queue handling the RTSP, and possibly some packet drops in the queue handling the rest of the upload.
Any unnecessary handling of packets slows the machine down a bit, so e.g. if you do run VLAN 7 alone on a dedicated bridge, you may simplify the configuration and thus remove one handling step.
Okay. So first, the “beauty of this beast” (the Mikrotik) is that, unlike with most hardware-only switches, you may create several independent bridges, and the VLAN IDs are only relevant within each bridge, i.e. frames are not forwarded from one virtual bridge to another just because they carry a VLAN ID which happens to be used at both bridges.
Hence as you have dedicated a bridge to the encoder and its control, it was not necessary to change the pvid of that bridge itself and its member ports to 5 - but it is not harmful either. But given that you don’t actually need a full-featured VLAN tag processing on this bridge, setting vlan-filtering to no may save some CPU cycles.
With this configuration, and regardless whether you change the vlan-filtering setting or not, assigning packet-mark=encoder based on in-interface=“Streaming Ports Bridge” is correct (as the pvid of the bridge itself and (04) - NV33 Stream is the same, no /interface vlan needs to be attached to the bridge to extract the tagless parts of the frames).
So since you say the queue named encoder shows packet drops, its limit-at and max-limit values (18M) are lower than the actual traffic volume the encoder sends. The manual doesn’t explain whether the rate value in the stats is the arrival rate or the departure rate, so you have to find that out on your own; in any case, if you set the limit and max-limit to something higher, point the camera to a significantly changing scene (static scenes or scenes with a few moving objects, like a single person walking through the scene, generate much lower data rate) and watch the stats, you should see the actual rate you need to set as limit-at & max-limit even if the rate shown is the departure one, provided that the actual rate is lower than the limits currently set. The rate value is averaged for 10 seconds or so, so take some time before the change becomes visible.
I never needed /queue simple queues, so I’m not sure how they interact with /queue tree queues; however, if the bandwidth calculation in these two trees (simple and tree) is independent as I suppose, the sum of max-limit (or burst-limit if set for the queue) of the root queues in both trees must not exceed the available bandwidth of the uplink in the respective direction. So if your actual uplink bandwidth is 60 Mbit/s, you have to set the max-limit of the root parent in /queue tree to only 58M, in order to leave the rest free for the 2M upload burst-limit set for the only queue in /queue simple.
The thing is that if you overbook the uplink, all the bandwidth control executed by the queues will show no drops, but the packets will be actually dropped because the link would be unable to transport them or, as you’ve mentioned a fibre uplink, more likely because the traffic shaper at the ISP will drop them as the bandwidth limitation is a contractual rather than physical one.
Thank you for all of your great insight with my problem.
I wanted to let you know that I had a great experience yesterday with my streaming device. I even had a user that was doing a major dropbox transfer and my unit did not skip any packets!!
I will be making the adjustment you suggested removing the vlan tagging in the streaming_bridge group to help with compute cycles tomorrow.
Is there anything else you can see from my setup that i might be doing wrong or could do better?