Re: [rmcat] Comments on draft-zanaty-rmcat-cc-codec-interactions-00

["Mo Zanaty (mzanaty)" <[e-mail]>]

Hi Karen,

Thanks for the review and comments.

Your first point is the most important to set the direction of this draft. This will be highlighted in the status slide (of the chairs update). So far, nearly all discussion about interactions in CC drafts and list threads is focused on Allowed Rate, with little or no discussion about the other interactions listed. I'm happy to remove the others, or mark them optional, or move them to an appendix, if the CC authors can confirm they don't intend any such interactions as they progress.

The rest of your edits and points look good. We will update the draft to incorporate them.

Cheers,
Mo

On Jul 19, 2015, at 8:04 PM, Karen Elisabeth Egede Nielsen <[e-mail]<mailto:[e-mail]>> wrote:

Hi Mo,

For what it is worth then please accept the following comments to the draft.

General:

I think that the document now only includes the CC-Codec interactions. I think this complies with what we intended in the wg.

I think that we should divide into MANDATORY and OPTIONAL sections, so that the
minimal set of features that
a codec developer have to rely on from the CC, and interact with, is absolutely clear.

Right now the document includes more interactions that what the present RMCAT CC proposals provides.
Indeed it seems that they only provides the very basic one (and with couple CC one more).
I think that further work shall narrow down the CC-codec interactions that we want to have in the document.
While it has value during the progress of the RMCAT CC definition work, to describe codec-cc  interactions,
that we from a theoretical perspective identify as something that could make sense for an RMCAT CC to provide, but which are not provided by any
solution (yet?),  then I am not sure that it makes sense to have  these interactions in there in the end.

Perhaps a  solution could be to put the interaction features, which are not supported by any of the CC proposals into the appendix and
here describe why one have ended up not supporting each.
I indeed suppose that there will be good reason for  why one can have or will have to live without.

I think that the introduction is a little too heavy and detailed in content.
E.g., I don’t think that the doc necessarily needs to motivate why RMCAT CC is needed nor
does it need to describe what present application do instead of using RMCAT CC (I think).
Also section 3 and section 4 are a little to detailed to my taste. But on the other hand, then as long as
no framework document exists, then some context should be given.

Detailed comments:

Abstract:

Suggest to rephrase:


and the components dedicated to congestion control functions --> and the RMCAT congestion control layer

I assume that FEC is the reason why you use the formulation


the application components that relate
   to congestion control, specifically the media codec control layer,

instead of simply:

the media codec control layer

Section 1:

I am not sure if we really need the historical perspective on CC implemented (or not) in RTP media applications in this document.
I think that the text is good, but I think that it belongs rather in the requirements doc or in a framework doc.
I think that one could jump right into the paragraph under the bulleted list in section 1 or even right into the paragraph starting with .

The RMCAT requirements..


Second last paragraph of Section 1:

In order to meet these requirements, interactions are necessary
   between the application's congestion controller, the RTP layer, media
   codecs, other components, and the underlying UDP/IP network stack.
   This memo attempts to present a conceptual model of the various
   interfaces based on a simplified application decomposition.  This
   memo discusses interactions between the congestion control and codec
   control layer in a typical RTP Application.

I suggest to rephrase to (something like):


In order to meet these requirements, interactions are necessary
   between the application's congestion controller and other
   application components, like the media codecs layer and the
   RTP layer. This memo describes the interactions between the
   RMCAT congestion control layer and the codec
   control layer in a interactive real time media RTP application.
Section 3:

Suggest to rephrase:


understanding and discussion of where congestion
   control functions operate, and how they interface with the other
   components.

to



understanding and discussion of where congestion
   control functions operate, and how they interface with the codec control layer.



Bullet 2 on Config seems to be too detailed for the purpose of this document. I suggest to keep only the text until  “For example ..

Bullet 4: I suggest to eliminate the text from  “such as REMB [I-D.alvestrand-rmcat-remb] ..” and onwards in this bullet.

Bullet 6: Shared state : I don’t think this detail is needed here. It is ? If so then I think that it should just be part of bullet 5 on congestion control.

Section 5:

The section starts with saying “the necessary..”. but it seems to describe both necessary and optional interactions. IF we end up describing optional interactions then I think we should have two subsections here – one for the “necessary” ones and, one section for the optional ones.

Section 5.2:

Right now what we have here is the priorities in coupled congestion. Correct ? If so I think that this could be made more concrete.

Section 5.3, 5.4, 5.5, 5.6, 5.8, 5.9:

No RMCAT CC solution seems to support this at present.  Should it be here ?

5.6 has the heading Forward Error Correction, but truly speaks about sensitivity to loss patterns. Shouldn’t this be the tittle ? (if kept).

Section 5.7:

This may be provided by the RMCAT CC (judging from the present discussions in the wg). Should as the other paragraph say
more exactly what the interaction consists of (CC-FEC/encoder).

BR, Karen