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

On Mon, 12 Dec 2016 15:59:46 -0600
"Ben Campbell" <ben@nostrum.com> wrote:

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

Hi Ben,

as usual, thanks for the precious suggestions! I'll integrate the text
you propose in the next version of the document, which I plan to submit
in the next few days.

Thanks,
Lorenzo

> 
> Thanks!
> 
> Ben.
> 
> _______________________________________________
> straw mailing list
> straw@ietf.org
> https://www.ietf.org/mailman/listinfo/straw