Subject: [rmcat] Review of cc-codec-interactions-01

From: Stefan Holmer <[email-masked]>
Date: Sun, 07 Feb 2016 11:11:54 +0000

Hi,

Sorry for missing the deadline for reviewing this document. Here are my
comments:

General observations:

   - Overall this document seems to be in a good state.
   - I think we should mention the possibility of having a single CC for
   the case when several streams are multiplexed over the same port, and maybe
   mention the possibility of having an Allowed Rate Allocator which splits
   the Allowed Rate between the different codecs, possibly according to
   priority/weight.
   - The definition of Codec feels a bit vague to me, and there are some
   sections which are talking about Codec interactions where I don't feel
   Codec is the right component. For instance, I don't understand how the
   Codec would have an opinion on delay tolerance. Would it be better to
   define interactions between delay tolerance and App? I can see the
   connection to loss tolerance though, but that also would fit as an
   interaction between CC and App.

All my raw comments:
*Section 5*
 Startup Ramp (CC-Codec): Initial rate (or number of packets in
      window-based CC proposals) and strategy for increasing the rate
      (or window) during media startup, similar to TCP intial congestion
      window and slow start.  See Section 5.4.3 for details.

Comments:

   - It's not entirely clear to me why the Codec would be interested in
   telling the CC how to ramp up. I see that as possibly something the
   user/App may want to specify, and the Codec will be notified through
   changes in the Allowed Rate.
   - "initial" misspelled.

Priority / Weight (Config-CC-UDP): If the application has multiple
      media flows, and can configure relative priority or weight among
      them, the config can interact with shared state if coupled CC is
      used (Section 5.7), or interact directly with a CC designed with
      intrinsic distributed weighted fairness such as NADA.  Priority
      can also interact with the underlying network stack if it supports
      layer 2/3 prioritization (Section 5.6).

Comments:

   - I don't think this document should refer to the candidate drafts. I
   rather see the candidates referring to this doc.

*Section 5.1*

   The primary interactions between the config and the codec that are
   relevant to congestion control are the multiplexing of media streams
   [I-D.ietf-mmusic-sdp-bundle-negotiation] and RTP/RTCP [RFC5761] on
   the same UDP port.

Comments:

   -
   - How is this a codec interaction? Should it not also mention how it
   affects CC? In my mind, if we do multiplexing of media streams, a single CC
   instance could be recommended for that set of streams (see general
   comments).

*Section 5.3*

   Packetization of codec frames into RTP packets can be an important
   interaction.  Some network interfaces may benefit from small packet
   sizes well below the MTU, while others may benefit from large packets
   approaching the MTU.  Equalizing packet sizes of a frame may also be
   beneficial in some cases, rather than a combination of large and
   small packets.  For example, in some FEC schemes, the FEC bandwidth
   overhead depends on the largest source packet size.  Equalizing the
   source packet sizes can yield lower overhead than a combination of
   large and small packets.

Comments:

   - Are the last two sentences about FEC really relevant for to CC?

*Section 5.4.5*

Note this is unrecoverable post-repair loss after
   retransmission or forward error correction.

Comments:

   - "Note that this"