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

[Lorenzo Miniero <[e-mail]>]

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.

Thanks!
Lorenzo


> Thanks!
> 
> Ben.
> 
> _______________________________________________
> straw mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/straw