Subject: Re: [straw] Alissa Cooper's Discuss on draft-ietf-straw-b2bua-rtcp-15: (with DISCUSS and COMMENT)

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 1 Dec 2016 09:58:10 +0100

On Tue, 29 Nov 2016 11:58:12 -0800
"Alissa Cooper" <[email-masked]> wrote:

> Alissa Cooper has entered the following ballot position for
> draft-ietf-straw-b2bua-rtcp-15: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut
> this introductory paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
> information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/
> 
> 

Hi Alissa,

thanks for reviewing the document! A few comments inline.

> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> = Section 3.1 =
> 
> I think there is a lack of clarity in the recommendations here,
> because "such attributes" aren't listed out anywhere and then later
> it's not clear what the "mentioned attributes" are referring to. I've
> proposed some edits below to try to clarify what I think the
> recommendations are saying -- does this capture the intent? 
> 
> OLD
> However, certain SDP attributes may
>    lead to call failures when forwarded by a media relay.  Such
>    attributes SHOULD NOT be forwarded.  One notable example is the
>    'rtcp' [RFC3605] attribute, that UAC may make use of to explicitly
>    state the port they're willing to use for RTCP.  Considering the
>    B2BUA would relay RTCP messages, the port as seen by the other UAC
>    involved in the communication would differ from the one negotiated
>    originally, and it MUST be rewritten accordingly.  Apart from the
>    mentioned attributes, B2BUAs SHOULD forward all other SDP
> attributes they don't have a reason not to forward, in order to avoid
> breaking additional functionality endpoints may be relying on.
> 
> NEW
> However, certain SDP attributes may
>    lead to call failures when forwarded by a media relay. One notable
> example is the
>    'rtcp' [RFC3605] attribute, that UAC may make use of to explicitly
>    state the port it is willing to use for RTCP. Assuming that the
>    B2BUA would relay RTCP messages, the port as seen by the other UAC
>    involved in the communication would differ from the one negotiated
>    originally. The 'rtcp' attribute MUST be rewritten accordingly,
> rather than being forwarded.  Any other attributes known to the B2BUA
> to cause call failures when forwarded SHOULD NOT be forwarded. B2BUAs
> SHOULD forward all other SDP attributes in order to avoid breaking
> additional functionality endpoints may be relying on.
> 

It does, thanks for the proposed text! Alia and Ben proposed some minor
revision to this in related comments, so I'll integrate the new text in
the next version.

> = Section 3.2 =
> 
> (1)
> "It is worthwile to point out that such a B2BUA may not necessarily
>    forward all the packets it receives, though.  Selective Forwarding
>    Units (SFU) [RFC7667], for instance, may aggregate or drop incoming
>    RTCP messages, while at the same time originating new ones on their
>    own.  For the messages that are forwarded and/or aggregated,
> though, it's important to make sure the information is coherent."
> 
> I don't see much beyond this text that discusses the implications of
> dropping and aggregating RTCP messages. Is this written down in
> another document? If not, I'm wondering about what happens with RTCP
> information aside from identifiers, SSRCs, and sequence numbers in
> these cases. E.g., if a B2BUA drops one RTCP message containing an
> RFC 7002 block but forwards the next one containing such a block,
> won't the interval and the discard count reported to the receiver be
> wrong? I assume there are a lot of cases involving XR blocks where
> this could be a problem, but this document doesn't address those
> cases.
> 

Good point. Do you think adding some text like "A B2BUA SHOULD NOT
randomly drop or forward RTCP feedback of the same type within the
context of the same session, as that may lead to confusing, if not
broken, feedback to the recipients of the message." would help clarify
the consequences of such a behaviour? If you think it's worthwhile, I
might add as an example the RFC 7002 block one you presented.

> (2)
> "SR:  [RFC3550]
>       If the B2BUA has changed the SSRC of the sender RTP stream a
>       Sender Report refers to, it MUST update the SSRC in the SR
> packet header as well.  If the B2BUA has changed the SSRCs of other
> RTP streams too, and any of these streams are addressed in any of the
>       SR report blocks, it MUST update the related values in the SR
>       report blocks as well.  If the B2BUA has also changed the base
> RTP sequence number when forwarding RTP packets, then this change
>       needs to be properly addressed in the 'extended highest sequence
>       number received' field in the Report Blocks."
> 
> Why is the recommendation about the extended highest sequence number
> received not also a MUST?
> 

You're right, I'll fix this.

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> = Section 3.2 =
> 
> s/properly address/reflected/
> 

Thanks!
Lorenzo

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

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 1 Dec 2016 09:35:52 -0500

Hi Lorenzo,

> On Dec 1, 2016, at 3:58 AM, Lorenzo Miniero <[email-masked]> wrote:
> 
>> = Section 3.2 =
>> 
>> (1)

That would help somewhat (although you’d have to explain what you mean by “feedback of the same type”), but I think there is a broader question here about all of the possible information sent within an RTCP message and the effects of selectively dropping or aggregating RTCP messages on that information. I just picked out the RFC 7002 example because it’s a document produced somewhat recently by one of my WGs, but I think a more comprehensive review of all the XR blocks and other RTCP info is warranted, *if* B2BUAs are actually currently dropping or aggregating this info.

Alissa

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 16 Dec 2016 15:42:22 -0600

Hi, please see inline:

On 1 Dec 2016, at 8:35, Alissa Cooper wrote:

> That would help somewhat (although you’d have to explain what you 
> mean by “feedback of the same type”), but I think there is a 
> broader question here about all of the possible information sent 
> within an RTCP message and the effects of selectively dropping or 
> aggregating RTCP messages on that information. I just picked out the 
> RFC 7002 example because it’s a document produced somewhat recently 
> by one of my WGs, but I think a more comprehensive review of all the 
> XR blocks and other RTCP info is warranted, *if* B2BUAs are actually 
> currently dropping or aggregating this info.
>

I see that version 16 at least partially addresses this. the text added 
an some examples to help clarify "...of the same type:

"(e.g., a specific XR block type, or specific Feedback messages)"

Unless I missed something, the text does not attempt the more 
comprehensive review that Alissa mentioned. Such a review could add 
quite a bit of effort, and I'm not sure the working group has the energy 
for that these days. Would it make sense to add some disclaimer text to 
the effect of "This document does not attempt to analyze the impact of 
dropping or aggregating each existing XR block or RTCP message"?

Thanks!

Ben.

---

From: Lorenzo Miniero <[email-masked]>
Date: Sat, 17 Dec 2016 10:09:44 +0100

On Fri, 16 Dec 2016 15:42:22 -0600
"Ben Campbell" <[email-masked]> wrote:

> >>> "It is worthwile to point out that such a B2BUA may not
> >>> necessarily forward all the packets it receives, though.
> >>> Selective Forwarding Units (SFU) [RFC7667], for instance, may
> >>> aggregate or drop incoming
> >>> I don't see much beyond this text that discusses the implications
> >>> of dropping and aggregating RTCP messages. Is this written down in
> >>> another document? If not, I'm wondering about what happens with
> >>> RTCP information aside from identifiers, SSRCs, and sequence
> >>> numbers in these cases. E.g., if a B2BUA drops one RTCP message
> >>> containing an RFC 7002 block but forwards the next one containing
> >>> such a block, won't the interval and the discard count reported
> >>> to the receiver be wrong? I assume there are a lot of cases
> >>> involving XR blocks where this could be a problem, but this
> >>> document doesn't address those cases.
> >>>  
> >>
> >>
> >> the consequences of such a behaviour? If you think it's
> >> worthwhile, I might add as an example the RFC 7002 block one you
> >> presented.  
> >
> > aggregating RTCP messages on that information. I just picked out
> > the RFC 7002 example because it’s a document produced somewhat
> > recently by one of my WGs, but I think a more comprehensive review
> > of all the XR blocks and other RTCP info is warranted, *if* B2BUAs
> > are actually currently dropping or aggregating this info.
> >  
> 
> I see that version 16 at least partially addresses this. the text
> added an some examples to help clarify "...of the same type:
> 
> quite a bit of effort, and I'm not sure the working group has the
> energy for that these days. Would it make sense to add some
> disclaimer text to the effect of "This document does not attempt to
> analyze the impact of dropping or aggregating each existing XR block
> or RTCP message"?
> 

Hi Ben,

you're right, I didn't delve into the details of each possible XR
block, as that would have been quite complex in such a short time. The
text I added was basically aimed at specifying that bad things can
happen if you drop RTCP packet type X (whether X is an XR report/block
or something else) and then you let the next packet of same type X
through instead, without some logic/criterion/adaptation behind it. I
can definitely add the statement you suggested if you believe it can
remove the ambiguity from the meaning of the paragraph.

Thanks!
Lorenzo

---

From: "Ben Campbell" <[email-masked]>
Date: Sat, 17 Dec 2016 13:33:22 -0600

> remove the ambiguity from the meaning of the paragraph.

Let's see what Alissa thinks about how this fits her discuss comment. Alissa?

Thanks!

Ben.

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 19 Dec 2016 09:36:54 -0500

I cleared, I think the update provided is good enough. Thanks.

Alissa

> On Dec 16, 2016, at 4:42 PM, Ben Campbell <[email-masked]> wrote:
> 
> Hi, please see inline:
> 
> I see that version 16 at least partially addresses this. the text added an some examples to help clarify "...of the same type:
> 
> Unless I missed something, the text does not attempt the more comprehensive review that Alissa mentioned. Such a review could add quite a bit of effort, and I'm not sure the working group has the energy for that these days. Would it make sense to add some disclaimer text to the effect of "This document does not attempt to analyze the impact of dropping or aggregating each existing XR block or RTCP message"?
> 
> Thanks!
> 
> Ben.
>

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 19 Dec 2016 09:55:47 -0600

Thanks! I assume that means the most recent update to the draft without 
additional clarification.

Lorenzo and Christer: Let's stick with with the text in the latest 
revision. I sent a separate email to Stephen to see if he is ready to 
clear with this version.

Thanks!

Ben.

On 19 Dec 2016, at 8:36, Alissa Cooper wrote:

>>>>> necessarily
>>>>> of
>>>>> RTCP
>>> RFC 7002 example because it’s a document produced somewhat