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

["Ben Campbell" <[e-mail]>]

On 17 Dec 2016, at 3:09, Lorenzo Miniero wrote:

> On Fri, 16 Dec 2016 15:42:22 -0600
> "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"?
>>
>
>
> 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.

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


Thanks!

Ben.