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

[Magnus Westerlund <[e-mail]>]

Den 2016-07-18 kl. 09:55, skrev Harald Alvestrand:
> 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?
>

https://irtf.org/anrw/2016/anrw16-final17.pdf

> 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
>
>


-- 

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]
----------------------------------------------------------------------