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

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

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:

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