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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 25 Nov 2016 15:49:01 +0100

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.

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.

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.

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.

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.

I note that SFU also requires sequence number rewriting, which affects 
other RTCP packet type that reference sequence numbers, like NACK.

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.

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.

Cheers

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: Lorenzo Miniero <[email-masked]>
Date: Tue, 29 Nov 2016 12:31:16 +0100

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.

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

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

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

>           A media-aware B2BUA MUST properly rewrite the additional
> SSRC identifier(s) in REMB packets, if it changed the related RTP
> 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.

>     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!
Lorenzo

> _______________________________________________
> straw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/straw