Re: [rtcweb] DSCP marking for STUN packets

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

I think we are discussing two different problems:
1. Determining what DSCP actually works over the Internet, by using ICE.
2. For one or more DSCPs an endpoint uses for a traffic flow, what DSCP ICE needs to use.

In the case of #2, the endpoint uses those DSCPs because the network is provisioned that way by the network admin or the service provider. This could possibly be achieved through a combination of some browser configuration and JS input. For this case, using the highest DSCP value among those that are used for a given media or data-channel flow for ICE connectivity/consent checks makes sense to me.

On this other hand, #1 looks a bigger problem. In the absence of any information, starting with BE or not setting anything in the packet looks a good option to me.

Muthu

|-----Original Message-----
|From: rtcweb [mailto:[e-mail]] On Behalf Of Magnus Westerlund
|Sent: Wednesday, March 12, 2014 1:33 PM
|To: Justin Uberti; Simon Perreault
|Cc: [e-mail]
|Subject: Re: [rtcweb] DSCP marking for STUN packets
|
|On 2014-03-12 04:53, Justin Uberti wrote:
|>
|>
|>
|> On Tue, Mar 11, 2014 at 7:02 AM, Simon Perreault
|> <[e-mail] <mailto:[e-mail]>> wrote:
|>
|>     Le 2014-03-10 16:57, James Polk a écrit :
|>     > At 12:16 AM 3/10/2014, Justin Uberti wrote:
|>     >> I think that the existing guidance should be sufficient in
|>     >> non-multiplexing cases (i.e. BUNDLE). For consent checks, I think the
|>     >> same DSCP markings as any other ICE connectivity checks should be
|>     >> used; for ICE-for-SCTP checks, the same DSCP markings as media
|>     packets
|>     >> (i.e. the SCTP traffic) should be used.
|>     >>
|>     >> If multiplexing is being performed, the connectivity checks probably
|>     >> should use the highest DSCP value being used by the multiplexed
|>     media.
|>     >
|>     > why is (seemingly) everyone's default position "use the highest DSCP
|>     > available" for signaling packets?
|>     >
|>     > You just need to make sure the packets aren't starved or dropped by/at
|>     > congestion points.
|>
|>     The underlying principle is that connectivity checks need to *check
|>     connectivity* (duh!). That's why you use the same DSCP as the media.
|>     Connectivity is affected by the DSCP. For example some DSCPs could be
|>     filtered, or could be placed in a low-priority queue and get dropped
|>     such that connectivity fails.
|>
|>     >From this principle follows this conclusion: on a given 5-tuple, if
|>     your
|>     media uses different DSCPs, you need to check connectivity for all those
|>     DSCPs. That is, you would send multiple connectivity checks, one for
|>     each DSCPs in the set used on this 5-tuple. Yeah, it sucks, so we might
|>     need an alternative heuristic: try the lowest-priority DSCP, and assume
|>     that if that one works, the higher-priority ones should work as well.
|>     (Note that Justin suggested the contrary.)
|>
|>     What you want to avoid is STUN packets getting through but not the
|>     corresponding media. That is an unworkable situation. The reverse is not
|>     ideal either (you think you have no connectivity when in fact you do),
|>     but at least ICE can work around it (by picking a different candidate).
|>
|>
|> We also need to consider the scenario of STUN consent checks, which will
|> need to get through reliably even when media marked with DSCP is already
|> flowing. In this case I think that using the highest DSCP value for STUN
|> is unavoidable.
|>
|
|(as individual)
|
|Sorry, I don't understand your reasoning here. Is it to provide the
|lowest possible drop probability, i.e. using the AFx class that has
|least drop probability?
|
|If there exist nodes that stomp on some DSCP markings, and not only
|remark them to Best Effort (BE), and instead drop then. Then, it is not
|obvious that that an AFx class is the most appropriate to use. In that
|case using BE might be more suitable for the consent freshness.
|
|I would also point out that highest DSCP value isn't clear. We are
|talking about forwarding behavior and I don't see how Expedited
|Forwarding (EF) can be compared with AF for example.
|
|I think we have to consider what our goals are here. To determine if we
|can get any packets through or determine if a particular 6-tuple (Source
|Address, Destination Address, Source Port, Destination Port, Protocol,
|and DSCP value) works? If it is the later then I think we need to have
|checks running on all the 6-tuples in use. This clearly have overhead
|concerns and helps worsening the ICE The Voice Hammer Attack (See
|section 18.5.1. of RFC 5245).
|
|If the goal is the first, isn't using BE a reasonable choice. Yes, it
|might have higher drop probability than AF, but it is likely to be
|robuster in general deployments and it determine if the peer is there or
|not. Dealing with broken 6-tuples needs to be a separate issue.
|
|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]
|----------------------------------------------------------------------
|
|_______________________________________________
|rtcweb mailing list
|[e-mail]
|https://www.ietf.org/mailman/listinfo/rtcweb