Re: [rtcweb] DSCP marking for STUN packets

[Magnus Westerlund <[e-mail]>]

Hi,
(as individual)

I think we need to start with what the goals are with the STUN packets.

In the initial connectivity establishment of ICE the purpose is to find
paths that works. To make that determination at all, I would argue to
maximize success one should use best effort markings as the network is
least likely to do something strange with such packets, including
dropping them for violating policy (even if they should just be
downgraded).

If one like to use STUN to determine the possibility to get DSCP != BE
packets through the network from a peer to peer perspective, then I
think one should consider specifying something like the STUN ECN check
options that are documented in Section 7.2.2 in RFC 6679.

To summarize, this sends an additional round of STUN packets after a
working path has been found to check ECN compliance in this path. It
includes and option indicating the ECT value entered, and the receiver
echoes the received value back. Thus enabling a sender to determine that
the path is ECT.

Something similar could be specified if desired to determine that at
least the network doesn't drop packets with DSCP != BE.

For consent freshness I don't think we need to do that on a per traffic
marking type level. Thus, the important is that it reaches the peer. And
the packet reaching the just needs to be statistically high enough
probability over a sequence of checks. Thus, I would say that the only
important factor here is to not mark it so that it has significant
higher drop probability. It also don't need to be minimal delay, thus EF
appears overkill and although AFx could be used, that should rather be
based on a traffic mix with a lot of AFx traffic.

In the end, it might be easier to not use other DSCP marking that BE for
the STUN, simple because it gives the most robust behavior and not
subject to network issues due to policing or DSCP remarking.

I think it will be important to take the considerations for using
multiple DSCP on the same 5-tuple that DART will document into account
here.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------