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

[Michael Welzl <[e-mail]>]

> On 05 Sep 2016, at 08:14, Harald Alvestrand <[e-mail]> wrote:
> 
> On 08/31/2016 02:00 PM, Michael Welzl wrote:
>> Hi all,
>> 
>> A small follow-up on this:
>> 
>> given that this paper of ours at ANRW has started this whole discussion on DSCP blackholing:
>> https://irtf.org/anrw/2016/anrw16-final17.pdf
>> 
>> ... I think it would be appropriate for draft-ietf-rtcweb-transports to cite this paper in the text discussing it.
> 
> Can you give me the XML blob to insert?

<reference anchor="ANRW16" target="">
		  <front>
              <title>How to say that you're special: Can we use bits in the IPv4 header?</title>
              <author initials="R." surname="Barik" fullname="R. Barik"></author>
              <author initials="M." surname="Welzl" fullname="M. Welzl"></author>
              <author initials="A." surname="Elmokashfi" fullname="A. Elmokashfi"></author>
              <date month="July" year="2016"/>
          </front>
          <seriesInfo name="ACM, IRTF, ISOC Applied Networking Research Workshop (ANRW 2016), Berlin" value=""/>
</reference>


Cheers,
Michael


> 
> It's not unreasonable to cite it as a reference for "there might be a
> problem", but I'm not going to spend much time constructing the reference.
> 
>> 
>> Cheers,
>> Michael
>> 
>> 
>> 
>>> On 05 Aug 2016, at 23:27, Black, David <[e-mail]> wrote:
>>> 
>>> The -15 version of the rtcweb-transports draft has now been posted, and the new text on non-zero DSCPs black-holing traffic is in Section 4.2 (https://tools.ietf.org/html/draft-ietf-rtcweb-transports-15#section-4.2).  Many thanks to Harald for adding this text.
>>> 
>>> The tsvwg-rtcweb-qos draft needs to note this issue and point to that section of the rtcweb-transports draft.  Here’s proposed text to do that, which I suggest inserting as a new paragraph in Section 5 immediately before Figure 1 (https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-17#section-5):
>>> 
>>>   WebRTC use of multiple DSCP values may encounter network blocking of packets
>>>   with certain DSCP values.   See section 4.2 of [I-D.ietf-rtcweb-transports]  for
>>>   further discussion, including how WebRTC implementations establish and
>>>   maintain connectivity when such blocking is encountered.
>>> 
>>> I hope something this short and simple will suffice.
>>> 
>>> Thanks, --David
>>> 
>>> From: Spencer Dawkins at IETF [mailto:[e-mail]] 
>>> Sent: Tuesday, August 02, 2016 1:29 PM
>>> To: Black, David
>>> Cc: Alissa Cooper; RTCWeb IETF; [e-mail]
>>> Subject: 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 <[e-mail]> 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:[e-mail]] 
>>> Sent: Monday, August 01, 2016 4:46 PM
>>> To: Spencer Dawkins at IETF
>>> Cc: Black, David; RTCWeb IETF; [e-mail]
>>> 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 <[e-mail]> wrote:
>>> 
>>> Hi, all,
>>> 
>>> On Thu, Jul 14, 2016 at 4:13 PM, Black, David <[e-mail]> 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 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:[e-mail]]
>>>> Sent: Thursday, July 14, 2016 4:53 AM
>>>> To: Cullen Jennings (fluffy); Black, David
>>>> Cc: RTCWeb IETF; Michael Welzl; [e-mail]
>>>> 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  [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
>>> 
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
>