Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT)

["Ben Campbell" <[e-mail]>]

Hi,

Comments inline. I removed parts that do not seem to need further 
discussion.

On 11 Jun 2015, at 7:04, Magnus Westerlund wrote:

[...]
>>>> -- 7.1, first paragraph: "applications MUST also implement 
>>>> congestion
>>>> control to
>>>> allow them to adapt to changes in network capacity."
>>>>
>>>> Is that the aformentioned not-yet-standardized congestion control
>>>> algorithm, or something else?
>>>
>>> As we have no standardized congestion control yet, we can't point to
>>> anything. But, an implementation must implement something, even if
>>> completely proprietary.
>>
>> It would be helpful to either clarify the "even if proprietary" part, 
>> or
>> perhaps move this sentence closer to the bit about no standardized
>> mechanism. (But this is not a show stopper.)
>
> Ok,
>
> I propose that we add this sentence: "The congestion control algorithm 
> will have to be proprietary until a standardized congestion control 
> algorithm is available." into the first paragraph in 7.1:
>
> WebRTC Endpoints MUST implement the RTP circuit breaker algorithm
> that is described in [I-D.ietf-avtcore-rtp-circuit-breakers].  The
> RTP circuit breaker is designed to enable applications to recognise
> and react to situations of extreme network congestion.  However,
> since the RTP circuit breaker might not be triggered until congestion
> becomes extreme, it cannot be considered a substitute for congestion
> control, and applications MUST also implement congestion control to
> allow them to adapt to changes in network capacity.  The congestion
> control algorithm will have to be proprietary until a standardized
> congestion control algorithm is available.  Any future RTP congestion
> control algorithms are expected to operate within the envelope
> allowed by the circuit breaker.
>
> Does this satisfies your concerns?
>

Yes, thanks.

>>
>>>
>>>
>>>>
>>>> -- 11, 2nd paragraph from end:
>>>>
>>>> It seems like the msid reference should be normative.
>>>
>>> Our intention was to keep this informative. Therefore the chosen 
>>> style
>>> of writing that sentence. The actual normative inclusion of MSID 
>>> into
>>> the WebRTC solution is done by JSEP.
>>
>> Okay. It might be helpful, but not required, to state this sentence 
>> in
>> the form of "[jsep] specifies that..."
>>
>
> So what you want is that paragraph to read more like this?
>
> Javascript Session Establishment Protocol [I-D.ietf-rtcweb-jsep]
> specifies that the binding between the WebRTC MediaStreams,
> MediaStreamTracks and the SSRC is done as specified in "Cross Session
> Stream Identification in the Session Description Protocol"
> [I-D.ietf-mmusic-msid].  The MSID document [I-D.ietf-mmusic-msid]
> also defines, in section 4.1, how to map unknown source packet stream
> SSRCs to MediaStreamTracks and MediaStreams.

Yes, I think that helps.

[...]

>>> The TSVWG document referenced do normatively reference the DART
>>> document. But, we could include the DART document in the same 
>>> sentence
>>> as the TSVWG document.
>>
>> I'm okay leaving it to the deeper conversation in the TSVWG doc. I
>> mainly mentioned it because I had thought the intent was to add the
>> mention here if the dart draft was sufficiently far along in the 
>> process
>> when this draft was submitted.
>
> Actually, I think I found a simple way of referencing it, and it is 
> relevant in that discussion. So the sentence is proposed to read:
>
>  However, depending on the QoS
> mechanism and what markings that are applied, this can result in not
> only different packet drop probabilities but also packet reordering,
> see [I-D.ietf-tsvwg-rtcweb-qos] and [I-D.ietf-dart-dscp-rtp] for
> further discussion.
>

That works for me.

>>>> -- 13: 3rd paragraph:
>>>>
>>>> Isn't that security solution MTU as well as MTI? If so, it might be
>>>> worth
>>>> mentioning it here.
>>>
>>> You mean Mandatory to Use, not Maximum Transmission Unit, don't you?
>>> Yes, it is mandatory to use, we can make that clear.
>>>
>>
>> Yes, mandatory to use. :-)
>>
>
> So text proposed to be changed to.
>
> A mandatory to implement and use
> media security solution is created by combining this secured RTP
> profile and DTLS-SRTP keying [RFC5764] as defined by Section 5.5 of
> [I-D.ietf-rtcweb-security-arch].

That works for me.

Thanks!

Ben.