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

"Ben Campbell" <> Fri, 12 June 2015 21:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2A1541B2AB2; Fri, 12 Jun 2015 14:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lo10RqbS4ss7; Fri, 12 Jun 2015 14:00:26 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 399AA1B2AAE; Fri, 12 Jun 2015 14:00:26 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.1/8.14.9) with ESMTPSA id t5CL0AFk096849 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 12 Jun 2015 16:00:21 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: Ben Campbell <>
To: Magnus Westerlund <>
Date: Fri, 12 Jun 2015 16:00:10 -0500
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.1r5084)
Archived-At: <>
Cc:, The IESG <>
Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Jun 2015 21:00:31 -0000


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

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.