Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ?

Hi, Alissa and David,

Thanks to both of you. I didn't see the minutes on the Proceedings page but
didn't think to look for draft minutes on the mailing list.

Very helpful.

Spencer

On Mon, Aug 1, 2016 at 5:12 PM, Black, David <david.black@emc.com> wrote:

> > The -rtcweb-transports author Harald Alvestrand took on the action item
> and will work with Justin Uberti to send a text proposal to the list.
>
> And when that text appears, we can figure out the wording (probably a
> short sentence) to add to the tsvwg-rtcweb-qos draft to point to it over in
> the rtcweb-transports draft.
>
>
>
> Thanks, --David
>
>
>
> *From:* Alissa Cooper [mailto:alissa@cooperw.in]
> *Sent:* Monday, August 01, 2016 4:46 PM
> *To:* Spencer Dawkins at IETF
> *Cc:* Black, David; RTCWeb IETF; tsvwg@ietf.org
> *Subject:* Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in
> draft-ietf-tsvwg-rtcweb-qos ?
>
>
>
> Hi Spencer,
>
>
>
> On Aug 1, 2016, at 6:56 AM, Spencer Dawkins at IETF <
> spencerdawkins.ietf@gmail.com> wrote:
>
>
>
> Hi, all,
>
>
>
> On Thu, Jul 14, 2016 at 4:13 PM, Black, David <david.black@emc.com> wrote:
>
> Magnus,
>
> I think that's a fine suggestion.   I think the next step is:
>
> > 3. The natural place to indicate the need/recommendation for
> > implementing this functionality would be in draft-ietf-rtcweb-transports
> > (Currently in IETF LC). However, here I think we need to have a
> > discussion if RTCWEB WG wants to only place a suitable warning about the
> > need, and indicate future forthcoming specification or if we hold this
> > document up until this solution is available?
>
> I'll attend the Thu RTCWEB session in Berlin to see how this comes out,
> after which it should be straightforward for the draft authors and yours
> truly to write the sentence or two that draft-ietf-tsvwg-rtcweb-qos will
> need.
>
>
>
> I'm just following up on this because we have draft-ietf-rtcweb-transports
> on the telechat agenda this week, and I didn't see a discussion on this
> topic in the RTCWeb agenda (or in poking around for minutes, jabber,
> etherpad, etc).
>
>
>
> Here is the relevant bit from the RTCWEB minutes:
>
>
> DSCP Black-holing Issue
>
> David Black (TSVWG co-chair) presented the DSCP black-hole issue with
> -rtcweb-transports
> <https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/> draft
> that was recently discussed on the list. This issue needs to be solved and
> described, even though both -rtcweb-transports and the referenced
> draft-ietf-tsvwg-rtcweb-qos has gone through IESG review. Magnus Westerlund
> has suggested a solution to the list, but what should the
> -rtcweb-transports draft say about DSCP black-holing and the possibility to
> use ICE to avoid it?
>
> The WG discussed this and concluded that the issue should be described by
> the -rtcweb-transports draft. Ted Hardie summarized the discussion by
> suggesting a text formulation for a resolution that seemed acceptable to
> the WG: “We will treat DSCP-induced path failure parallel with other types
> of path failures and resolve it by using ICE restart. Note: There is a
> problem with multiple DSCP codepoints on a single transport, where one
> might be blocked and other might get through. In this case, the ICE probes,
> using one DSCP codepoint, may succeed while others fail. This is complex
> and should be warned about. A likely viable solution is ICE restart with
> DSCP markings turned off, but detection requires watching the
> multiple-DCSP-codepoint-using channels for differential failures”. If there
> are other proposals for resolution, please contact Harald. Cullen Jennings
> asked David if this solution was acceptable, but David wanted to see the
> text proposal. The -rtcweb-transports author Harald Alvestrand took on the
> action item and will work with Justin Uberti to send a text proposal to the
> list.
>
>
>
> Harald has been on holidays since the IETF meeting but will aim to get to
> this before the telechat.
>
>
>
> Best,
>
> Alissa
>
>
>
>
>
> Did it happen? Was there a resolution?
>
>
>
> Thanks,
>
>
>
> Spencer
>
>
>
> Thanks, --David
>
>
> > -----Original Message-----
> > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> > Sent: Thursday, July 14, 2016 4:53 AM
> > To: Cullen Jennings (fluffy); Black, David
> > Cc: RTCWeb IETF; Michael Welzl; tsvwg@ietf.org
> > Subject: Re: [tsvwg] [rtcweb] Fall-back to DSCP 0 in
> draft-ietf-tsvwg-rtcweb-qos ?
> >
> > Den 2016-07-12 kl. 18:19, skrev Cullen Jennings (fluffy):
> > >
> > > short answer here but as David suggested …  some implementation use
> > > the STUN packets in ICE  or just  in WebRTC style liveness tests to
> > > do the tests of if a given DSCP works or not. In general ICE is a
> > > good tool to take a bunch of possible paths, test which work, and
> > > select the best.
> >
> > I do agree that how you do the path checks when setting DSCP values != 0
> > is dependent on the context. For the WebRTC I do agree doing checks
> > using ICE is quite reasonable.
> >
> > We already have similar path testing usages of ICE in the ECN for RTP
> > specification (RFC6679), see Section 7.2.1. I will note that taking this
> > as blueprint for DSCP testing, what is needed clearly requires a new
> > separate specification. The components needs are: 1) A new STUN
> > parameter to request the ICE peer to echo the DSCP field value received.
> > 2) A ICE capability parameter to be used in signalling negotiations to
> > determine capability for this feature. 3) Behaviour specification on how
> > to test values and interpret responses. This include things like if one
> > should actually establish multiple candidate pairs one with DSCP testing
> > and one without?
> >
> > So the question here is how to proceed with this issue. So I would
> > suggest the following way forward.
> >
> > 1. draft-ietf-tsvwg-rtcweb-qos identifies the issue and recommends the
> > user to apply path verification methods but don't specify them.
> >
> > 2. Someone takes on the task to write a DSCP path verification extension
> > to ICE.
> >
> > 3. The natural place to indicate the need/recommendation for
> > implementing this functionality would be in draft-ietf-rtcweb-transports
> > (Currently in IETF LC). However, here I think we need to have a
> > discussion if RTCWEB WG wants to only place a suitable warning about the
> > need, and indicate future forthcoming specification or if we hold this
> > document up until this solution is available?
> >
> >
> > Cheers
> >
> > Magnus Westerlund
> >
> > ----------------------------------------------------------------------
> > Services, Media and Network features, Ericsson Research EAB/TXM
> > ----------------------------------------------------------------------
> > Ericsson AB                 | Phone  +46 10 7148287
> > Färögatan 6                 | Mobile +46 73 0949079
> > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> > ----------------------------------------------------------------------
>
> _______________________________________________
> 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
>
>
>