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

[Alissa Cooper <[e-mail]>]

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

Alissa

> On Dec 16, 2016, at 4:42 PM, Ben Campbell <[e-mail]> wrote:
> 
> Hi, please see inline:
> 
> On 1 Dec 2016, at 8:35, Alissa Cooper wrote:
> 
>> Hi Lorenzo,
>> 
>>> On Dec 1, 2016, at 3:58 AM, Lorenzo Miniero <[e-mail]> wrote:
>>> 
>>>> = 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.
>> 
>> 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.
>