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

[Karen Elisabeth Egede Nielsen <[e-mail]>]

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