Re: [rtcweb] DSCP marking for STUN packets

In all this talk about drop precedence and so on I'd like to point people
at some details of some currently deployed packet scheduling and aqm
systems.

http://snapon.lab.bufferbloat.net/~d/draft-taht-home-gateway-best-practices-00.html
On Mar 10, 2014 1:36 AM, "Muthu Arul Mozhi Perumal (mperumal)" <
mperumal@cisco.com> wrote:

>  |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> 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
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>