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

[Harald Alvestrand <[e-mail]>]

Answering my own question:

perusing my TSVWG archives, I found
http://heim.ifi.uio.no/~michawe/research/publications/anrw16-measurement.pdf,
which says:

" We did, however, see consistent packet drops too: on 23 paths for DSCP
value 8, 21 paths for 36, 19 for 46. This failure rate of approximately
10 - 13% is a reason to be concerned about WebRTC QoS; implementations
should probably react to consistent failures with a fall-back to DSCP
value 0."

The data is not broken down further on what kinds of paths the failures
were detected on, but the design of the experiment seems fairly solid if
I understand the description right.

On 07/18/2016 09:55 AM, Harald Alvestrand wrote:
> David,
>
> repeating for transparency what I asked in person:
>
> Can you post the links to the measurements that led to the conclusion
> that non-arrival of DSCP-marked packets is a big enough problem that we
> should develop specific mechanisms to detect it?
>
> I'd like to make sure we're all on the same page wrt what the problem
> is, how we can measure it, and in what contexts the problems are likely
> to have significant impact.
>
> (I worry in particular about how many false positives a blackhole
> detection mechanism is likely to have, and how much this will in turn
> increase randomness in performance as percieved by the user, making
> performance problems harder to diagnose.)
>
>
> On 07/14/2016 11:13 PM, Black, David 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.
>>
>> 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
>


-- 
Surveillance is pervasive. Go Dark.