Re: [rtcweb] [tsvwg] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos

[Justin Uberti <[e-mail]>]

Great, glad that we've already got this speced. Thanks Harald.

On Wed, Jul 31, 2019 at 7:07 AM Harald Alvestrand <[e-mail]>
wrote:

> draft-ietf-tsvwg-rtcweb-qos is out of scope for this working group, but
> didn't we cover this ground extensively in draft-ietf-rtcweb-transport?
>
> Namely (from -17):
>
> 4.2.  Usage of Quality of Service - DSCP and Multiplexing
>
>    When the packet is sent, the network will make decisions about
>    queueing and/or discarding the packet that can affect the quality of
>    the communication.  The sender can attempt to set the DSCP field of
>    the packet to influence these decisions.
>
>    Implementations SHOULD attempt to set QoS on the packets sent,
>    according to the guidelines in [I-D.ietf-tsvwg-rtcweb-qos].  It is
>    appropriate to depart from this recommendation when running on
>    platforms where QoS marking is not implemented.
>
>    The implementation MAY turn off use of DSCP markings if it detects
>    symptoms of unexpected behaviour like priority inversion or blocking
>    of packets with certain DSCP markings.  Some examples of such
>    behaviors are described in [ANRW16].  The detection of these
>    conditions is implementation dependent.
>
>    A particularly hard problem is when one media transport uses multiple
>    DSCP code points, where one may be blocked and another may be
>    allowed.  This is allowed even within a single media flow for video
>    in [I-D.ietf-tsvwg-rtcweb-qos].  Implementations need to diagnose
>    this scenario; one possible implementation is to send initial ICE
>    probes with DSCP 0, and send ICE probes on all the DSCP code points
>    that are intended to be used once a candidate pair has been selected.
>    If one or more of the DSCP-marked probes fail, the sender will switch
>    the media type to using DSCP 0.  This can be carried out
>    simultaneously with the initial media traffic; on failure, the
>    initial data may need to be resent.  This switch will of course
>    invalidate any congestion information gathered up to that point.
>
>    Failures can also start happening during the lifetime of the call;
>    this case is expected to be rarer, and can be handled by the normal
>    mechanisms for transport failure, which may involve an ICE restart.
>
>    Note that when a DSCP code point causes non-delivery, one has to
>    switch the whole media flow to DSCP 0, since all traffic for a single
>    media flow needs to be on the same queue for congestion control
>    purposes.  Other flows on the same transport, using different DSCP
>    code points, don't need to change.
>
>    All packets carrying data from the SCTP association supporting the
>    data channels MUST use a single DSCP code point.  The code point used
>    SHOULD be that recommended by [I-D.ietf-tsvwg-rtcweb-qos] for the
>    highest priority data channel carried.  Note that this means that all
>    data packets, no matter what their relative priority is, will be
>    treated the same by the network.
>
>    All packets on one TCP connection, no matter what it carries, MUST
>    use a single DSCP code point.
>
>    More advice on the use of DSCP code points with RTP and on the
>    relationship between DSCP and congestion control is given in
>    [RFC7657].
>
> Den 31.07.2019 07:12, skrev Justin Uberti:
> >
> >
> > On Tue, Jul 30, 2019 at 10:10 PM Matthew Kaufman <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     I noted two of particular interest… one is the “network eats
> >     DSCP-marked but allows non-marked” case. Arguments go both ways as
> >     to what one should do in this case (follow network admin desires vs.
> >     work as often as possible).
> >
> >
> > I lean towards 'work as often as possible', which suggests we probably
> > need both marked and unmarked ICE checks to determine whether we should
> > mark media traffic (and potentially multiple differently marked checks
> > in the mux case).
> >
> >     ____
> >
> >     __ __
> >
> >     The other is picking which DSCP value in the case where multiplexing
> >     is in use and you don’t know whether you’re audio-only or
> >     audio-plus-video or data-only at the time you do the ICE
> exchange.____
> >
> >     __ __
> >
> >     (Never mind that Windows has limitations on marking, which I’m sure
> >     we’ve all dealt with)____
> >
> >     __ __
> >
> >     Matthew Kaufman____
> >
> >     __ __
> >
> >     *From: *Justin Uberti <[e-mail] <mailto:[e-mail]
> >>
> >     *Date: *Wednesday, July 31, 2019 at 10:36 AM
> >     *To: *Matthew Kaufman <[e-mail]
> >     <mailto:[e-mail]>>
> >     *Cc: *"[e-mail] <mailto:[e-mail]>" <[e-mail]
> >     <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>"
> >     <[e-mail] <mailto:[e-mail]>>
> >     *Subject: *Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos____
> >
> >     __ __
> >
> >     hmm, right. We have definitely observed that some networks will eat
> >     marked traffic, so there needs to be some sort of trial exchange to
> >     ensure a given marking will work.  ____
> >
> >     __ __
> >
> >     Can you summarize the other issues you are concerned about? ____
> >
> >     __ __
> >
> >     On Tue, Jul 30, 2019 at 9:47 PM Matthew Kaufman
> >     <[e-mail] <mailto:[e-mail]>> wrote:____
> >
> >         IF one believes that none of the open issues mentioned in the
> >         email thread I sent are an issue, then sure, RFC5245 applies.____
> >
> >          ____
> >
> >         But even so, I would argue that draft-ietf-tsvwg-rtcweb-qos
> >         should say what to do and reference 5245.____
> >
> >          ____
> >
> >         Alternatively, one might believe that one or more of the issues
> >         are a real problem… in which case we should specify alternative
> >         behavior.____
> >
> >          ____
> >
> >         Matthew Kaufman____
> >
> >          ____
> >
> >         *From: *Justin Uberti <[e-mail]
> >         <mailto:[e-mail]>>
> >         *Date: *Wednesday, July 31, 2019 at 10:08 AM
> >         *To: *Matthew Kaufman <[e-mail]
> >         <mailto:[e-mail]>>
> >         *Cc: *"[e-mail] <mailto:[e-mail]>" <[e-mail]
> >         <mailto:[e-mail]>>, "[e-mail]
> >         <mailto:[e-mail]>" <[e-mail] <mailto:
> [e-mail]>>
> >         *Subject: *Re: [rtcweb] STUN DSCP and
> >         draft-ietf-tsvwg-rtcweb-qos____
> >
> >          ____
> >
> >         I had thought this was already covered
> >         in https://tools.ietf.org/html/rfc5245#section-7.1.2.4
> >         <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5245-23section-2D7.1.2.4&d=DwMFaQ&c=PpPcabknNF6XJFBaeGH06g&r=9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1YlIatVI&m=fbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=ltGEgbp10iUc1gBO_cimQvtZZ9HfiJOm_ysp3ZOo0eQ&e=
> >,
> >         which basically says exactly what you are asking for.____
> >
> >          ____
> >
> >         On Tue, Jul 30, 2019 at 9:09 PM Matthew Kaufman
> >         <[e-mail] <mailto:[e-mail]>>
> wrote:____
> >
> >             Was chasing down some webrtc rabbit holes today, and came
> >             across the following concern:____
> >
> >              ____
> >
> >             draft-ietf-tsvwg-rtcweb-qos has exactly zero language about
> >             how the STUN packets should be marked for ICE negotiation.
> >             The issue is mentioned in
> >             draft-ietf-rtcweb-stun-consent-freshness, but I believe that
> >             the rtcweb-qos document should be the reference to how an
> >             rtcweb transport author should be setting DiffServ
> markings.____
> >
> >              ____
> >
> >             Also, there was a great conversation on the topic back in
> >             2014 that unfortunately seems to have petered out before a
> >             resolution to some obvious open issues:
> >
> https://mailarchive.ietf.org/arch/browse/rtcweb/?gbt=1&index=HH0qztqt4UtfZdpuxHTVcg7hZdE
> >             <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_browse_rtcweb_-3Fgbt-3D1-26index-3DHH0qztqt4UtfZdpuxHTVcg7hZdE&d=DwMFaQ&c=PpPcabknNF6XJFBaeGH06g&r=9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1YlIatVI&m=fbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=FlrSPxMvUIrN-iqDsEmRI1U0URJnINsru1TEVWNMUBQ&e=
> >____
> >
> >              ____
> >
> >             Would be great to finish the conversation before finalizing
> >             the specification for how to mark these.____
> >
> >              ____
> >
> >             Personally I’m in the “ICE is testing connectivity, so STUN
> >             must be marked exactly the same as corresponding media”
> >             camp.____
> >
> >              ____
> >
> >             Matthew Kaufman____
> >
> >             _______________________________________________
> >             rtcweb mailing list
> >             [e-mail] <mailto:[e-mail]>
> >             https://www.ietf.org/mailman/listinfo/rtcweb
> >             <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rtcweb&d=DwMFaQ&c=PpPcabknNF6XJFBaeGH06g&r=9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1YlIatVI&m=fbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=89GkSxwEhG63-il9an69COx4NNrA8nM3i4siRUHMFHM&e=
> >____
> >
>
>