QoS for SRT and Live Streaming

[TheAlchemist]

Hi,

We have Mx250 as a security appliance and some MS switches connected in our network. For live streaming using SRT and NDI want to employ QoS on the VLANs used on streaming traffic going over public internet. Which QoS DSCP tag could be  attached to the streaming VLAN? Doing some reading seems like DSCP value of 26 should be attached.

Also, streaming traffic would be using Public Internet for ingress and egress through the MX250 appliance.SO, where should I setup QoS for the streaming VLAN ? Under MX250's Security &SD-WAN's > Traffic Shaping rules or under Switch settings > Quality of service.

More than 50% of our data traffic is for streaming, so if QoS rule is set then would it affect traffic on other data VLANs ?

Thanks,

TheAlchemist

[PhilipDAth]

I don't know anything about the protocols you mention.

Typical values are:

• Streaming video, DSCP32 or CS4
• Interactive video, AF31 or AF41
• EF for voice (like telephony)

Ideally, you would get the application itself to apply the DSCP tags.  Otherwise you can ask the switch to do it.

You then tell the MS to trust the DSCP tags.

https://documentation.meraki.com/MS/Other_Topics/MS_Switch_Quality_of_Service_Defined 

Then you would use the MX traffic shaping to assign that traffic to a queue.

https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Using_Packet_Prioritization_on_a_Tr... 

[GIdenJoe]

Hey @PhilipDAth , I also believe the endpoint should be tagging it's own traffic.  However using the MX to match on DSCP values is not configurable... I only know from documentation that EF traffic is implicitly placed in the realtime queue.

@GreenManfew nitpicks for product team:

However no documentation tells the maximum percentage of realtime traffic allowance on the MX.

And as stated above, it's a shame you cannot explicitely configure DSCP value matching on the MX traffic types.  Also there is no way to implement policing with markdown and utilize WRED with drop probabilities.

[PhilipDAth]

>However using the MX to match on DSCP values is not configurable

Crap, you are correct.  I forgot.  They'll have to match using a layer 3/4 expression.

[TheAlchemist]

SRT is a protocol used to media streaming based of UDP. While NDI also used for media transport is primarily  based of TCP but newer versions supports multicast which is UDP

[TheAlchemist]

Based on below article in Meraki documentation, I could assign any DSCP value in any Queue and what percentage of bandwidth is assigned to that traffic in that Queue depends on the CoS queue value chosen. i.e. CoS value 5 will have the maximum weightage and most percentage of bandwidth assigned. Then what does it matter if a DSCP value of 31,36 or 41 or any other number is chosen.

https://documentation.meraki.com/MS/Other_Topics/MS_Switch_Quality_of_Service_Defined

[GreenMan]

Remember too - if the traffic is being forwarded to the Internet;  while the MX can re-order packets outbound, to reflect the priority you assign to different traffic types, the likelihood is that the ISP will remark DSCP values to 0 at the earliest opportunity, thus it would receive no priority upstream.

[TheAlchemist]

So, with the DSCP values setup, at least there will be priority given to the tagged VLAN within our network. Also, do you think, asking the ISPs to retain the DSCP values on our data traffic upstream is a possibility?

[PhilipDAth]

The ISP wont do this.

[TheAlchemist]

Thank you for all the info provided so far. So, employing QoS /Setting DSCP would have any impact whatsoever on improvement/priority wise on a particular VLAN when traffic from that VLAN is supposed to be upstreamed to Public internet. Or is it adding more complexity than the actual weightage of result.

[GreenMan]

That's not quite right.   With appropriate config the MX will re-order packets as they exit towards the Internet, to put more important / more time-sensitive packets first.   Given that performance problems can quite often relate to contention for the available upstream bandwidth (which is often asymmetric), this can make all the difference.  Once that traffic reaches the ISP's PoP, all bets are generally off.