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

"Ben Campbell" <ben@nostrum.com> Fri, 12 June 2015 21:00 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1541B2AB2; Fri, 12 Jun 2015 14:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lo10RqbS4ss7; Fri, 12 Jun 2015 14:00:26 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 399AA1B2AAE; Fri, 12 Jun 2015 14:00:26 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (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 ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" <ben@nostrum.com>
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>
Date: Fri, 12 Jun 2015 16:00:10 -0500
Message-ID: <9C881C2A-B25A-41EC-852B-7D138D383349@nostrum.com>
In-Reply-To: <55797949.2030004@ericsson.com>
References: <20150609030408.24606.8383.idtracker@ietfa.amsl.com> <5576A8FE.2060001@ericsson.com> <A316BF37-CBEC-41D5-95AF-233E50EBFFD7@nostrum.com> <55797949.2030004@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/QlbBRdpAD52fLSZ6IsV6S_TJGxE>
Cc: rtcweb@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jun 2015 21:00:31 -0000

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.