Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media
draft-ietf-rmcat-nada-13

(1) Section 4.  Per “In the experimental phase of this draft …”, what experiment is being proposed and what is the exit criteria for it?  Is this a reference to Section 8?  If so, perhaps, drop the introductory clause:

OLD:
In the experimental phase of this draft, additional studies in real-world settings will gather further learnings on how to choose and adapt these parameter values in practical deployment.

NEW:
Additional studies in real-world settings suggested in Section 8 could gather further insight on how to choose and adapt these parameter values in practical deployment.

(2) Editorial Nits:
Section 1.  Typo. s/descirbed/described/

Section 3.  Typo. s/abrevity/brevity/

Section 3.  Editorial.  s/into compressed bitstream/ into a compressed bitstream/

Section 4.  Typo. s/mutliplier/multiplier/

Section 4.1.  Editorial?  For the MULTILOSS variable, the default value is listed as “7.”, it seems like it should read 7 (no period), but maybe there is a missing decimal portion?

Section 4.2.  Typo.  s/milliseonds/milliseconds/

Section 4.3. Typo.  s/stablizes/stabilizes/

Section 4.3.  Typo.  s/absense/absence/

Section 5.1.3.  Typo.  s/straighforward/ straightforward/

Section 6.3. s/enviornments/environments/

Section 6.3. s/futher/further/

Section 7.  Typo. s/descirbed/described/

Section 7.  Typo. s/implemention/implementation/

Section 7.  Typo.  s/wirelss/wireless/

Section 8. Typo. s/adapte/adapt/

Section 8.  Typo. s/preferrably/preferably/

Section 8.  Typo. s/set up/setup/

Nice work; thanks for this.

Thanks for this document; it provides a clear picture of an interesting
scheme, and it will be interesting to see further reports of its
efficacy.  I just have some essentially editorial comments, that may not
even be worth responding to, so I will try to sneak them in after the
telechat.

Do we need to say anything further about aborting the flow when the
level of congestion does not support even the minimum bitrate supported
by the encoder?  Mirja thinks this is sufficiently well-known that we
probably don't need to, which seems reasonable to me.

Section 4

   o  Accelerated ramp-up: when the bottleneck is deemed to be
      underutilized, the rate increases multiplicatively with respect to
      the rate of previously successful transmissions.  The rate

"multiplicatively" is synonymous with "exponentially" here?
(Thank you for specifying it this way, though, to make clear what the
multiplier value is.)

Section 4.3

                                   QBOUND
       gamma = min(GAMMA_MAX, ------------------)     (3)
                               rtt+DELTA+DFILT

It seems impossible for the minimum to be GAMMA_MAX with the defaults
for QBOUND, DELTA, and DFILT, since the second argument to min() is less
than 50/(120+100) = 0.23, which is much less than the default GAMMA_MAX
of 0.5.

Section 5.1.1

   one-way delay and base delay.  By re-estimating the base delay
   periodically, one can avoid the potential issue of base delay
   expiration, whereby an earlier measured base delay value is no longer
   valid due to underlying route changes.  All delay estimations are

I think that clock *rate* skew between peers could also cause issues
with base delay values growing less useful over time.  Clock rate skew
is much less prominent than absolute clock skew, though.

   based on sender timestamps with a recommended granularity of 100
   microseconds or higher.

Is this a normative requirement?
Also, pedantically, I think "granularity of 100 microseconds or higher"
has "higher" apply to the numerical value 100, so it would
include a granularity of 1 second.  I see that later on we recommend
measuring the delay as an integer multiple of 100 microseconds, so this
seems like the intended sense, but does the scheme become less useful if
the granularity of the measurment becomes too coarse-grained (e.g., the
second granularity I mentioned above)?  If so, we may want to put a
bound on the other direction as well.

Section 5.3

   o  Aggregated congestion signal (x_curr): the most recently updated
      value, calculated by the receiver according to Section 4.2.  This
      information is expressed with a unit of 100 microsecond (i.e.,
      1/10 of a millisecond) in 15 bits.  This allows a maximum value of
      x_curr at approximately 3.27 second.

There's perhaps a minor editorial mismatch between the "information is
required" intro and declarative "is expressed in [specific format]".
(Similarly for r_recv.)

A Question regarding Section 5.1.1.

This section recommends using a NADA specific transmission timestamping mechanism embedded in the transport. What about the header extension for  	Transmission Time offsets? Are there a reason to not discuss using that a potential solution for providing that. I know it has the downside of being expressed in RTP payload format timescales and not in a nice and likely more compact milisecond, but it is a standardized solution that can provide the necessary signal.