Self-Clocked Rate Adaptation for Multimedia
draft-ietf-rmcat-scream-cc-13

Thanks for addressing my DISCUSS and comments.

Just a few mostly editorial comments:

- Abstract: By "such as video", am I correct to assume this is specific to interactive video?

- 3.3: The MUST and MAY seem more like statements of fact than normative requirements.

- 4.1.2, last paragraph: The MAY seems like a statement of fact.

- 4.1.2.3, last paragraph: Ditto for the SHOULD

-- Informational References:  It seems like the references to RFCs 3550 and 3611 are needed to really understand this document, which would make them normative.

I'm a Yes with lots of questions and comments. You may be educating me, rather than making text changes, as seems appropriate.

Because 

4.1.1.1.  Constants

   The RECOMMENDED values, within (), for the constants are deduced from
   experiments. 

provides recommended, but not required, constant values (which is fine), could you say something about, or just provide a reference to, those experiments, so that implementers and deployers could verify that they are in an environment that was considered by the working group?

I'd also note that most of the constants, but not all, have associated text that says basically "if you dork with this constant, here's what's likely to change". Some of those constants are pretty self-evident even to me, but not all of them. That could have been intentional, but the working group is likely to have a better grip on that than J. Typical Coder On A Deadline in a couple of years, so if there are useful things to say, I'd imagine people would listen to you.

Is 

  QDELAY_TREND_TH (0.2)
     Averaging factor for qdelay_fraction_avg.

   QDELAY_TREND_TH (0.2)
     Averaging factor for qdelay_fraction_avg.

a duplicate?

In this text,

  rtp_queue_size (0 bits)
     Size of RTP packets in queue.

   rtp_size (0 byte)
     Size of the last transmitted RTP packet.

is "size" being used in the same way (so, rtp_queue_size would be the total number of bytes in queue)? But I'm guessing. Maybe "Sum of the sizes of RTP packets in queue"?

ISTM that 

   Note that the pseudo code does not show all
   details for reasons of readability, the reader is encouraged to look
   into the C++ code in [SCReAM-CPP-implementation] for the details.

might make SCReAM-CPP-implementation a normative reference. Does "encouraged to look at" mean "really needs to look at"?

In this text,

   It is desired to avoid the case that the qdelay
   target is increased due to self-congestion, indicated by a changing
   qdelay and consequently an increased qdelay_norm_var_t.  Still it
   SHOULD be possible to increase the qdelay target if the qdelay
   continues to be high. 

I got lost in the passive tense. Is this saying that *an implementation* should be able to increase the qdelay target algorithmically?

This text,

   If it is deemed
   unlikely that competing flows occur over the same bottleneck, the
   algorithm described in this section MAY be turned off.  However, when
   sending over the Internet, often the network conditions are not known
   for sure.  Therefore turning this algorithm off must be considered
   with caution as that can lead to basically zero throughput if
   competing with other, loss based, traffic.

bothers me a bit, because I'm not sure how a transport implementation knows that it's sending over the Internet. We have discussions from time to time about networks that are playing games with non-RFC 1918 addresses and NATs, for instance, and networks that are directly interconnected can be using routable addresses, while not "sending over the Internet". Is the point that an implementation that turns the algorithm off is well-advised to detect that it should turn the algorithm on?

I couldn't parse

   A strict rule can lead to that the
      media bitrate will have difficulties to increase as the congestion
      window puts a too hard restriction on the media frame size
      variation. 

without guessing. I lost my way at "can lead to that the media bitrate".