Re: [rmcat] AD review for draft-ietf-rmcat-rtp-cc-feedback-08

[Colin Perkins <[e-mail]>]

On 4 Jul 2022, at 15:52, Zaheduzzaman Sarker wrote:

> Hi,
>
> Thanks for working on this informational document. This was a nice short read with useful information.
>
> I think this is ready for IETF last call. I, however, have some minor comments below -
>
> ## Comments -
>
>     - Anna has some good comments in her Shepherd write up mail (https://mailarchive.ietf.org/arch/msg/rmcat/XRWgsOrPbeWLXp7cRqutWZcRU70/ <https://mailarchive.ietf.org/arch/msg/rmcat/XRWgsOrPbeWLXp7cRqutWZcRU70/> ), please address them.

The -09 draft was intended to address Anna’s comments.

>     - Section 2: Says -
>
>    			"Approaches like in-network filtering of acknowledgements
>    can reduce the feedback frequency and overhead in some cases, but
>    this so-called "stretch-ACK" behaviour is non-standard and not
>    guaranteed"
>
>
>    		would be great to have references supporting this claim and definition of “stretch-ACK” or reference to that.

Addressed in -09

>     - Section 2: Says -
>
>     		"indeed, it is unlikely that a video codec can react instantly to a rate change anyway, and there is little point in providing feedback more often than the codec can adapt"
>
>     	 This kind of builds up the hope/assumption that it might be affecting the feedback frequency if this fact is known. But rest of the document does not deal with this information at all. I would suggest to be clear on how this information is used to calculate the frequency.

Added a clarification on -10, suggesting that the feedback should be configured to match the codec rate of adaptation.

>     - Section 3.2 : repeats the Trtcp equation. Can we tag the same equation in section 3.1 and cross reference from section 3.2?

Added a cross-reference. The maths is easier to follow in the equation is repeated, however, so I left the equation.

>     - Section 3.2 : regarding SDES packet size calculation, I think it is worth mentioning where that 1 octet comes from to calculate 28 octet.

Added a reference to RFC 3550 section 6.5, that describes the SDES padding rules, and noted that these require SDES packets to be 32-bit aligned.

>     		"The RTCP SDES packet will comprise a header (4 octets), originating SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding. If the CNAME follows [RFC7022] and [RFC8834] it will be 18 octets in size, and will need 1 octet of padding, making the SDES packet 28 octets in size.”
>
>     	this calculates , 4 (header)+4 (SSRC)+18(CNAME)+1(padding) = 27 octet ( + 1 octet of terminating chunk ? Or more padding?)

4 (header) + 4 (SSRC) + 18 (CNAME) + 1 (padding) + 1 (terminating) = 28.

I updated the text to be more explicit.

I’ll submit -10 with these changes.

Colin