QOS and H.263 video and bridging vs routing

Greetings,

I’ve looked at a lot of info about QOS, and came to very few conclusions. The articles/posts I see about QOS and priority marking, many seem to be referencing VOIP and videoconferencing that takes place over the internet, which also usually includes the ROS device being used in “routing mode”, and often, uses NAT too.

The setup I am using is none of that. The system I am looking at, is using ROS on an RB411AH board with XR5 radio cards. The units themselves are bridging WLAN and ETH. A bridge is created, and both ether1 and WLAN1 are added to the bridge as ports. There is one AP and only one CLIENT radio.

The network is private, has several legs of 100mbps fiber, and the AP is set up at the end of one of the fiber runs, with a single client that has one H.263 PTZ streaming video camera attached to the CL to send video back to HQ.

Some video glitches were seen, and I was sent to search for info on QOS and packet marking, to see if there was anything that can be done to resolve this (although the source of the glitches had not been determined, but, being in the wireless comms business for 30+ years, I know it’s always the radio that gets blamed first.)

The first question: Does QOS have any effect while in bridging mode, rather than routing mode? What I’ve seen indicates the marking is done under mangle, but uses a param of pre- or post-routing. Bridging between WLAN and ether1 is not routing, and nor is ethernet bridging from the ROS device to the bridge it is connected to.

The second question: These camera(s) are used in streaming UDP mode…is UDP even processed by QOS? I assume a packet being sent form the AP eth to the eth network headed back to HQ could have a priority attached to it, if UDP is processed by QOS, and then it would be up to the rest of their network to honor that.

What about the WLAN link? Knowing that UDP, for all intents and purposes, is connectionless and ack’less, I am aware that the WLAN link has retry attempts for UDP packets in the 802.11 wireless protocol only, like between CL and AP. Does QOS settingts affect any of this?

Thanks in advance.

I doubt bandwidth shaping, which is what you do with Queue Trees and mangling would help you in that situation.

The camera actually uses the radios as a point to point link. No other traffic is coming apart from the camera, so AFAIK bandwidth shaping is not going to help.

The first thing I’d check is that wireless link. What are the CCQ values? How is it setup? You can export its setup by connecting via Winbox, opening a New terminal and typing

export

Then pasting the text here (mask or edit out sensitive information).

Real QoS (traffic priorization on a per packet basis) i.e. DSCP, etc may help you, but again, I doubt it will help, and should be done not on the PTPs but on the involved switches/routers in your LAN; the only thing you could do on your PTP would be setting DSCP values on the camera packets (all packets coming from it).

Are both AP and client Mikrotik?