Re: [rtcweb] DSCP marking for STUN packets

|I think that the existing guidance should be sufficient in non-multiplexing
|cases (i.e. BUNDLE).

I don't think so. Even for non-multiplexing cases, a same stream could use different drop precedence for different packets, as described in draft-dhesikan-tsvwg-rtcweb-qos

   The combination of priority input and multiple precedence levels
   within a data class provides flexibility for an implementation in
   deciding the importance of the stream and packets within a stream.
   For example, if I frames are more important than the P frames then
   the I frames can be marked with a DSCP with the lower drop
   precedence.

My take is that STUN connectivity/consent checks SHOULD use the lowest drop precedence within a given data type and priority.

|For consent checks, I think the same DSCP markings as any other ICE connectivity
|checks should be used.

Agree.

|If multiplexing is being performed, the connectivity checks probably should
|use the highest DSCP value being used by the multiplexed media.

For multiplexed media, I guess there is no WG consensus on how to mark the stream, yet (draft-ietf-mmusic-sdp-mux-attributes lists two possible options). But, I agree with your proposal in general, since these STUN packets are a kind of (media path) signaling packets and signaling packets are generally given higher priority..

Muthu

From: Justin Uberti [mailto:juberti@google.com]
Sent: Monday, March 10, 2014 10:46 AM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] DSCP marking for STUN packets

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.

On Fri, Mar 7, 2014 at 4:35 AM, Muthu Arul Mozhi Perumal (mperumal) <mperumal@cisco.com<mailto:mperumal@cisco.com>> wrote:
ICE says that an endpoint SHOULD apply the same DSCP marking as media packets to connectivity checks. This looks insufficient for RTCWEB, since it doesn't cover (at least) the following:
- connectivity checks performed for a stream using different drop pecedences (draft-dhesikan-tsvwg-rtcweb-qos).
- connectivity checks performed for non-media/data-channel traffic.
- DSCP markings for consent checks.

Comments on where we need to specify them? The last one can probably go into draft-ietf-rtcweb-stun-consent-freshness?

Muthu

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb