Re: [straw] [Tsv-art] TSV-ART review of draft-ietf-straw-b2bua-rtcp-15

"Ben Campbell" <ben@nostrum.com> Mon, 12 December 2016 21:59 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767E7129DA9; Mon, 12 Dec 2016 13:59:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.796
X-Spam-Level:
X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no
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 3IS4D15xmqAW; Mon, 12 Dec 2016 13:59:52 -0800 (PST)
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 B56FC129D84; Mon, 12 Dec 2016 13:59:52 -0800 (PST)
Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBCLxkbj056531 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 12 Dec 2016 15:59:47 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39]
From: Ben Campbell <ben@nostrum.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Date: Mon, 12 Dec 2016 15:59:46 -0600
Message-ID: <65AC39F1-2047-4368-9373-0FF8F04F480C@nostrum.com>
In-Reply-To: <93a45f63-ea97-77cf-ee29-a79369e55d14@ericsson.com>
References: <394e842e-d0bc-309f-86ac-8279741dd8a3@ericsson.com> <20161129123116.033312d7@lminiero.lan> <088e785d-4758-2d77-4926-8fe165aee232@ericsson.com> <CAKKJt-daGB=FcEFEe6NdxD06_v3qVMDU4m2dtShPhL0-uXG76w@mail.gmail.com> <20161207132547.57e14e87@lminiero.lan> <93a45f63-ea97-77cf-ee29-a79369e55d14@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.6r5310)
Archived-At: <https://mailarchive.ietf.org/arch/msg/straw/RNn-1QUr6VraG-SuHBsr0UDkKXE>
Cc: "tsv-art@ietf.org" <tsv-art@ietf.org>, Lorenzo Miniero <lorenzo@meetecho.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, "tsv-ads@tools.ietf.org" <tsv-ads@tools.ietf.org>, straw@ietf.org
Subject: Re: [straw] [Tsv-art] TSV-ART review of draft-ietf-straw-b2bua-rtcp-15
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/straw/>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2016 21:59:54 -0000

On 9 Dec 2016, at 8:48, Magnus Westerlund wrote:

> Den 2016-12-07 kl. 13:25, skrev Lorenzo Miniero:
>> On Fri, 2 Dec 2016 08:49:41 -0600
>> Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
>>
>>> Lorenzo,
>>>
>>> On Fri, Dec 2, 2016 at 3:57 AM, Magnus Westerlund <
>>> magnus.westerlund@ericsson.com> wrote:
>>>
>>>> Den 2016-11-29 kl. 12:31, skrev Lorenzo Miniero:
>>>>
>>>>> On Fri, 25 Nov 2016 15:49:01 +0100
>>>>> Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
>>>>>
>>>>> Hi,
>>>>>>
>>>>>> I have done this review as part of the TSVART's task to review
>>>>>> documents with potential transport impact.
>>>>>>
>>>>>> Below you will find a number of comments on issues that I found. 
>>>>>> I
>>>>>> think there are several significant issues below: 2, 3, 4, and 6.
>>>>>> The rest would be good to address. I am sorry that this review is
>>>>>> late in the process.
>>>>>>
>>>>>
>>> deleted down to
>>>
>>>
>>>>
>>>>> 5. Section 3.2:
>>>>>>
>>>>>>        REMB:  [I-D.alvestrand-rmcat-remb]
>>>>>>           A media-aware B2BUA MUST properly rewrite the 
>>>>>> additional
>>>>>> SSRC identifier(s) in REMB packets, if it changed the related RTP
>>>>>>           SSRC of the media sender.
>>>>>>
>>>>>> I assume that you have had some thought about the need to include
>>>>>> this individual proposal. I do note that it is not clear if this
>>>>>> ever will be published, especially considering the RMCAT WG's
>>>>>> work on a different feedback format.
>>>>>>
>>>>>>
>>>>>
>>>>> We had this in the beginning since most of our experimentation in
>>>>> this field was based on WebRTC implementations, and REMB played a
>>>>> great deal in that respect. Failing to adapt things would lead to
>>>>> recipients possibly flooded with data they couldn't handle, due to
>>>>> missing or broken feedback.
>>>>>
>>>>> I do know the REMB draft has been obsoleted for a while, but it's
>>>>> still used in both Chrome and Firefox, and so I thought it made
>>>>> sense to keep the related text there, as it is indeed still useful
>>>>> in the "real world". If you believe we should rather remove it, or
>>>>> replace references to REMB with something else, no problem from 
>>>>> me.
>>>>>
>>>>
>>>> I think you should leave it in, I have no other example which
>>>> actually has deployment, maybe something like this:
>>>>
>>>>
>>>> REMB:  [I-D.alvestrand-rmcat-remb] is a deployed application layer
>>>> specific RTCP Payload-Specific Feedback message. If negotiated to
>>>> be used a media-aware B2BUA MUST properly rewrite the additional
>>>> SSRC identifier(s) in REMB packets, if it changed the related RTP
>>>>       SSRC of the media sender.
>>>
>>>
>>> This was mentioned in a few ballots (including mine) during IESG
>>> evaluation, so I'd like to confirm that Magnus's suggestion works 
>>> for
>>> me.
>>>
>>
>>
>> Spencer, Magnus,
>>
>> sorry for this awfully late reply, busy days... thanks for the
>> additional feedback! Just so that I'm sure we're on the same page, 
>> does
>> this mean that we can keep the reference to the obsolete document as
>> well, or should we just mention REMB without the reference itself?
>
> I am fine with maintaining the reference, it makes it simpler to find. 
> However, one could potentially argue that the combination with MUST 
> makes this a normative reference to a draft document. It is possible 
> that one should consider reformulating this in a more informative 
> fashion just stating that it will be necessary to perform the 
> translation for this message.

That's an argument that I'm likely to make :-)

Could this be reformulated to say something like:

"[I-D.alvestrand-rmcat-remb] describes an RTCP Payload-Specific feedback 
message that reports the receiver's available bandwidth to the the 
sender. As of the time of this writing, REMB has been widely deployed, 
but has not been standardized. The REMB mechanism will not function 
correctly across a media-aware B2BUA that changes the SSRC of the media 
sender unless it also changes the SSRC values in the REMB packet."


Thanks!

Ben.