DSCP class/classification for Nest Audio network traffic

[Razuberī]

I wonder what would be the recommended DSCP classification for a Nest Audio (2nd gen) device.

I want to classify the Nest Audio traffic appropriately. I am using OpenWRT for the main router that provices the overall DSCP marking.

According to RFC4594 (https://datatracker.ietf.org/doc/html/rfc4594), the following markings could be appropriate.

• EF since we can make Meet calls on Nest Audio. 
• AF3x since we can stream audio/music
  • Perhaps AF4x instead for the same reason: audio/music streaming (interactive)
• I don't know the classification for issuing voice commands/prompts but EF seems appropriate as well.

I am worried that EF is too huge a priority for audio/music streaming. Futhermore, are there mapped ports/protocol (TCP/UDP) for the traffic? Can I assume tcp.80 and tcp/udp.443?

What would be the recommended DSCP marking? Consider that I am not doing this on a Nest Wi-Fi device. I am applying the markings using Linux on OpenWRT.

For example, for marking Microsoft Teams traffic according to Microsoft (https://docs.microsoft.com/en-us/microsoftteams/qos-in-teams)

• Audio: source device ports 50000-50019 to any destination. EF marking
• Video: source device ports 50020-50039 to any destination. AF41 marking
• Application/Screen Sharing: source device ports 50040-50059 to any destination. AF21 marking

How should I classify Nest Audio?

• From Nest Audio source device to any destination udp.443 (QUIC/HTTP3), classify EF
• From Nest Audio source device to any destination tcp.443 (TLS), classify EF
• From Nest Audio source device to any destination tcp.80, classify EF

Follows a table with the marking recommendations from RFC4594. Just as an example. They do not directly apply nowadays.

Service Class Name	DSCP Name	Applilcation Examples
Network Control	CS6	Network Routing
Telephony	EF	IP Telephony bearer
Signaling	CS5	IP Telephony signaling
Multimedia Conferencing	AF41, AF42, AF43	H.323/V2 video conferencing (adaptive)
Real-Time Interactive	CS4	Video conferencing and Interactive gaming
Multimedia Streaming	AF31, AF32, AF33	Streaming video and audio on demand
Broadcast Video	CS3	Broadcast TV & live events
Low-Latency Data	AF21, AF22, AF23	Client/server transactions and Web-based ordering
OAM	CS2	OAM&P
High-Throughput Data	AF11, AF12, AF13	Store and forward applications
Standard	DF (CS0)	Undifferentiated applications
Low-Priority Data	CS1	Any flow that has no BW assurance ( DEPRECATED, use LE instead)
Low-Priority Data	LE	RFC8622

[Razuberī]

According to

(Google Information) Prepare your network for Meet meetings  (https://web.archive.org/web20231014162701/https://support.google.com/a/answer/1279090#Outbound&zippy...

• Update your firewalls to allow media traffic to flow to and from your organization:
  • For audio and video, set up outbound UDP ports 3478 and 19302​–19309.
    • If you want to limit the number of Chrome WebRTC ports being used, use the ports specified at WebRTC UDP Ports.
    • Alternatively, you can limit those ports with your firewall.
  • For web traffic and user authentication, use outbound UDP and TCP port 443.

I am little confused by the term "outbound".

The firewall rules would it be?

• From (source) Nest Audio source device to (target) any destination udp.3478
• From (source) Nest Audio source device to (target) any destination udp.19302​–19309
• From (source) Nest Audio source device to (target) any destination udp.443
• From (source) Nest Audio source device to (target) any destination tcp.443

Or?

• From (source) Nest Audio source device udp.3478 to (target) any destination
• From (source) Nest Audio source device udp.19302​–19309 to (target) any destination
• From (source) Nest Audio source device udp.443 to (target) any destination
• From (source) Nest Audio source device tcp.443 to (target) any destination

[Razuberī]

Furthermore, according to

(Google Information) Meet QoS best practices (https://web.archive.org/web/20231014162701/https://support.google.com/a/answer/13383716?hl=en)

•  To add QoS at the network edge:
  • On all network edges, add a rule to mark Meet traffic. You should assign the Expedited Forward (EF) class for Meet traffic to ensure low delay and low jitter. This traffic is the RTP/RTCP traffic that uses the Meet port ranges.
  • Remove the DSCP tagging for the traffic that leaves your internal gateway to the internet.
  • Tag Meet traffic received from the internet using the EF class. This traffic is the RTP/RTCP traffic that uses the Meet port ranges.
  • Within your company, to achieve low delay, jitter, and loss values, prioritize EF traffic and place it into low latency or strict priority queues. Implement additional precautions, such as rate limiting above predefined bandwidth values, to make sure that EF traffic doesn’t limit other traffic classes on the network. 

Therefore, the recommendation matches RFC 4594 in regards to using EF marking for Meet. 

However, once again, EF marking is appropriate for Meet Voice/Audio but excessive for Meet Video.

Which ports are used for Video and which ports are used for Audio? From Meet UDP ports 3478 and 19302​–19309 ?I go back to my original point.

• Google Meet calls (Nest Audio or Android Phone)
  • EF since we can make Meet calls (voice/audio) on Nest Audio. 
  • EF ??? for video for Meet Video call (I added this condition to understand Meet network traffic better).

• Audio/Podcast/Music streaming (Nest Audio)
  • AF3x since we can stream audio/music
    • Perhaps AF4x instead for the same reason: audio/music streaming (interactive)

• Google Assistant (Nest Audio)
  • I don't know the classification for issuing Google Assistant voice commands/prompts but EF seems appropriate as well.

We've already mapped Meet ports to differentiate from other network traffic.

Is it possible to differentiate Audio/Podcast/Music streaming from Google Assistant ? So that we can do the same?

[Razuberī]

RFC 8837: Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS (https://web.archive.org/web/20230314234529/https://datatracker.ietf.org/doc/rfc8837/)

Provides the following recommendations for WebRTC. Therefore, they should apply to Google Meet and Nest Audio. Although, it assumes that all Audio traffic is interactive which is not the case for Podcast/Music streaming.

Flow Type	Very Low	Low	Medium	High
Audio	LE (1)	DF (0)	EF (46)	EF (46)
Interactive Video with or without Audio	LE (1)	DF (0)	AF42, AF43 (36, 38)	AF41, AF42 (34, 36)
Non-Interactive Video with or without Audio	LE (1)	DF (0)	AF32, AF33 (28, 30)	AF31, AF32 (26, 28)
Data	LE (1)	DF (0)	AF11	AF21

The DSCP recommendations are exactly the ones used for Microsoft Teams:

• For Audio, use EF DSCP marking.
• For Interactive Video, use AF41 DSCP marking.
• For Data, use AF21 DSCP marking.

From

(Google Information) Prepare your network for Meet meetings (https://web.archive.org/web/20231014162701/https://support.google.com/a/answer/1279090#Outbound&zipp...)

we gathered that

• For web traffic and user authentication, use outbound UDP and TCP port 443. This will be considered Data. Thus, AF21 DSCP marking.
• For audio and video, set up outbound UDP ports 3478 and 19302​–19309. We still can't differentiate audio from video: which ports are each? It is a big difference between EF (audio) and AF41 (Video).

Once again, on a Nest Audio, is it possible to differentiate Google Meet audio call from Podcast/Music streaming ?

Futhermore, how do we differentiate amongst Google Meet network traffic: Audio, Video and Data ? Which is a very simple thing for Microsoft Teams.