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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 2 Dec 2016 10:57:03 +0100

Den 2016-11-29 kl. 12:31, skrev Lorenzo Miniero:
> On Fri, 25 Nov 2016 15:49:01 +0100
> Magnus Westerlund <[email-masked]> 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.
>>
>
>
> Hi Magnus,
>
> thanks for reviewing this again!
>
>
>>
>> 1. Section 3.1: I am surprised that there are no discussion for a
>> Media Relay regarding a=rtcp-mux and its impact on where RTP/RTCP
>> packets will flow and if a=rtcp attribute is at all relevant. I think
>> there would be clearer if one in the context of a=rtcp also discusses
>> a=rtcp-mux and how that impacts the actual transport layer flows that
>> will result.
>>
>
>
> You're right, we talk about 'rtcp-mux' in 3.2 but not 3.1, I'll fix
> this. Considering we're talking of a possibly/probably media-unaware
> component, would you be ok with a text suggesting a 3.1 Media Relay
> SHOULD reject 'rtcp-mux'? If the MR is able to demux RTP/RTCP then it's
> looking at packets rather than just forwarding them, making it more of a
> Media-aware Relay than a plain Media Relay.

I would say that it is a SHOULD unless the signalling component has 
verified that demultiplexing can be performed without any RTP Payload 
Type rewrites, i.e. no overlap between any RTP PTs and the RTCP PT 
space. This is quite likely in many point to point via the MR scenarios, 
but becomes possibly difficult in any multiparty scenarios.

>
>
>> 2. Section 3.1:
>>     While [RFC7022] can prevent this from
>>     happening, there may be implementations that don't make use of it.
>>     As such, a B2BUA MAY rewrite CNAME items if any potential
>> collision is detected, even in the Media Relay case.  If a B2BUA does
>> indeed decide to rewrite CNAME items, though, then it MUST generate
>> new CNAMEs following [RFC7022].
>>
>> While the Media Relay is generally safe in regards to the use of RTP
>> header extensions, this text above actually requires translation of
>> the RTP header extension identified as
>> "urn:ietf:params:rtp-hdrext:sdes:cname" [RFC7941]. Then also that
>> needs to be translated.
>>
>
>
> Mh, this would also mean making a plain MR (or assuming it is) too aware
> of the media it is handling, especially if it comes up to editing RTP
> extensions. Anyway, since we're talking about CNAME rewriting, it makes
> sense to refer to RFC7941 too where that's mentioned, so I'll update the
> sections where that happens.

Yes, I wonder if you should rather point out that one can't use an MR in 
this case, but can use a very basic Media-Aware Relay (Translator) that 
only translates the CNAME items, including the RTP header extension if 
negotiated.

>
>
>> 3. Section 3.2:
>>
>> Also this section will need a discussion of RTP header extensions. So
>> one set of header extensions that may be translated are any SDES
>> items. So CNAME, MID, RID should be considered. Especially MID and
>> RID as they are directly related to SDP they are likely to need
>> translation.
>>
>> However, also the set of transport related information, like the ones
>> that has been proposed for use with RMCAT but have not yet been
>> approved. As they can have packet specific information, if one starts
>> removing packets, then one may need to consider these also.
>>
>
>
> Isn't this widening the scope too much? The purpose of the draft is to
> address RTCP-related problematics, and opening the door to RTP (even
> just header extensions) could mean adding way more text and cases to
> this than originally planned.

I think the relevant level here is to point out that there exist RTP 
header extensions, and especially the SDES ones, i.e. pointer to RFC7941 
that can result in that information that has been the responsibility of 
RTCP can show up in RTP and thus require translation of also RTP 
packets. This has potential MTU issues.

>
>
>> 4. Section 3.2: SR Entry:
>>
>> I like to note that if an Media Relay act in the role of a SFU, then
>> it needs to track in the outgoing SR, the relevant number of packets
>> sent, total amount of bytes sent to that particular receiver, rather
>> than what was received. Note, that as this is SR specific, it does
>> not apply to RR.
>>
>
>
> Ok, I'll clarify this in the SR text.
>
>
>> I note that SFU also requires sequence number rewriting, which
>> affects other RTCP packet type that reference sequence numbers, like
>> NACK.
>>
>
>
> That's already in the document, at least for NACKs themselves.

Yes, but also RTCP SR needs to be locally generated based on what is 
actually sent. So, I think there is a point of pressing a generic 
clarification that SFU results in RTP sequence number rewrites affecting 
RTCP.

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

>
>
>> 6. Section 3.2:
>>
>> In fact, while a Media Relay B2BUA may choose to
>>     use it on the side that supports it and not on the side that
>> doesn't, there are other aspects to take into account before doing so.
>>
>> The above sentence indicates that it is okay to use reduced sized
>> RTCP on one leg but not the other. I would strongly discourage that
>> due to the issues that are raised. If one is going to "forward" a
>> reduced size RTCP packet, that needs to be upgraded to a compliant
>> RTCP compound packet. Which makes it bigger, and then RTCP bandwidth
>> becomes an issue. I think the above sentence should be clearer that
>> there are real issues here. And I think the conclusion should be to
>> use it only if both legs support it.
>>
>
>
> I actually added that text after feedback from your previous review :-)
>
> https://www.ietf.org/mail-archive/web/straw/current/msg00336.html
>
> The text following the snippet you pasted tries indeed to convey exactly
> the point you make, that is that if you decide to go that road there
> are issues to be aware of. I'll try to make it clearer in the text that
> the issues are actually more severe than one might think, and so advice
> against negotiating it on one leg and not on the other.

Thanks

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 2 Dec 2016 08:49:41 -0600

Lorenzo,

>>> rest would be good to address. I am sorry that this review is late in
deleted down to

> I think you should leave it in, I have no other example which actually has
> deployment, maybe something like this:
>
>
> specific RTCP Payload-Specific Feedback message. If negotiated to be used a
> media-aware B2BUA MUST properly rewrite the additional SSRC

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.

Thanks!

Spencer

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 7 Dec 2016 13:25:47 +0100

On Fri, 2 Dec 2016 08:49:41 -0600
Spencer Dawkins at IETF <[email-masked]> wrote:

> >>> 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:  
> >>>
> >>> 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:
> >
> >
> > specific RTCP Payload-Specific Feedback message. If negotiated to
> > be used a media-aware B2BUA MUST properly rewrite the additional

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'll work on a revised version of the document next week, as tomorrow
and Friday it's holiday here in Italy.

Thanks,
Lorenzo

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 9 Dec 2016 15:48:06 +0100

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

Cheer

Magnus

-- 

Magnus Westerlund

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 12 Dec 2016 15:59:46 -0600

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

>>> evaluation, so I'd like to confirm that Magnus's suggestion works 
>>> for
>>> me.
>>>
>>
>>
>> Spencer, Magnus,
>>

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.

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 13 Dec 2016 16:41:32 +0100

On Mon, 12 Dec 2016 15:59:46 -0600
"Ben Campbell" <[email-masked]> wrote:

> >>>>>> 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:  
> >>>>>>
> >>>>>> 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.
> >>>>>  
> >>>>
> >>>> 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 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.  
> 
> "[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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/straw

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 14 Dec 2016 02:10:01 -0600

Hi, Ben,

On Dec 13, 2016 11:41 PM, "Lorenzo Miniero" <[email-masked]> wrote:

Hi Ben,

I think your proposed text is a good way to handle this.

Spencer

Thanks,
Lorenzo