[rmcat] Spencer Dawkins' Yes on draft-ietf-rmcat-scream-cc-12: (with COMMENT)

[Spencer Dawkins <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-rmcat-scream-cc-12: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rmcat-scream-cc/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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".