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

[Ballot comment]
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.)

[Ballot comment]
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.

[Ballot comment]
(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/

Request for posting confirmation emailed to previous authors: rmcat-chairs@ietf.org, Stefano D'Aronco , Xiaoqing Zhu , Sergio de la Cruz , Rong * , Jian Fu , Michael Ramalho , Paul Jones

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-rmcat-nada-11, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-08-12):

From: The IESG
To: IETF-Announce
CC: rmcat-chairs@ietf.org, mls.ietf@gmail.com, draft-ietf-rmcat-nada@ietf.org, rmcat@ietf.org, ietf@kuehlewind.net, Martin Stiemerling
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (NADA: A Unified Congestion Control Scheme for Real-Time Media) to Experimental RFC


The IESG has received a request from the RTP Media Congestion Avoidance
Techniques WG (rmcat) to consider the following document: - 'NADA: A Unified
Congestion Control Scheme for Real-Time Media'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-08-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes NADA (network-assisted dynamic adaptation), a
  novel congestion control scheme for interactive real-time media
  applications, such as video conferencing.  In the proposed scheme,
  the sender regulates its sending rate based on either implicit or
  explicit congestion signaling, in a unified approach.  The scheme can
  benefit from explicit congestion notification (ECN) markings from
  network nodes.  It also maintains consistent sender behavior in the
  absence of such markings, by reacting to queuing delays and packet
  losses instead.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rmcat-nada/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-rmcat-nada/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2890/
  https://datatracker.ietf.org/ipr/2671/

Request for posting confirmation emailed to previous authors: rmcat-chairs@ietf.org, Stefano D'Aronco , Xiaoqing Zhu , Sergio de la Cruz , Rong * , Jian Fu , Michael Ramalho , Paul Jones

Document Writeup for draft-ietf-rmcat-nada-10

1. Summary

Who is the document shepherd? Who is the responsible Area Director?

The document shepherd is Martin Stiemerling (mls.ietf@gmail.com).
The responsible AD is Mirja Kuehlewind (ietf@kuehlewind.net).

Abstract

  This document describes NADA (network-assisted dynamic adaptation), a
  novel congestion control scheme for interactive real-time media
  applications, such as video conferencing.  In the proposed scheme,
  the sender regulates its sending rate based on either implicit or
  explicit congestion signaling, in a unified approach.  The scheme can
  benefit from explicit congestion notification (ECN) markings from
  network nodes.  It also maintains consistent sender behavior in the
  absence of such markings, by reacting to queuing delays and packet
  losses instead.

2. Review and Consensus

The document has been reviewed of the RMCAT WG and there have been no controversial points.

3. Intellectual Property

Each author has confirmed that they do not have any direct, personal knowledge of any IPR related to this document, other than stated in the IPR notices

The WG is aware of the IPR notices listed under
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-rmcat-nada

4. Other Points

There are no other points.

Document Writeup for draft-ietf-rmcat-nada-10

1. Summary

Who is the document shepherd? Who is the responsible Area Director?

The document shepherd is Martin Stiemerling (mls.ietf@gmail.com).
The responsible AD is Mirja Kuehlewind (ietf@kuehlewind.net).

Abstract

  This document describes NADA (network-assisted dynamic adaptation), a
  novel congestion control scheme for interactive real-time media
  applications, such as video conferencing.  In the proposed scheme,
  the sender regulates its sending rate based on either implicit or
  explicit congestion signaling, in a unified approach.  The scheme can
  benefit from explicit congestion notification (ECN) markings from
  network nodes.  It also maintains consistent sender behavior in the
  absence of such markings, by reacting to queuing delays and packet
  losses instead.

2. Review and Consensus

The document has been reviewed of the RMCAT WG and there have been no controversial points.

3. Intellectual Property

Each author has confirmed that they do not have any direct, personal knowledge of any IPR related to this document, other than stated in the IPR notices

The WG is aware of the IPR notices listed under
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-rmcat-nada

4. Other Points

There are no other points.

Request for posting confirmation emailed to previous authors: Stefano D'Aronco , Xiaoqing Zhu , Sergio de la Cruz , Rong * , Jian Fu , Michael Ramalho , Paul Jones

Request for posting confirmation emailed to previous authors: Stefano D'Aronco , Xiaoqing Zhu , Sergio de la Cruz , Rong * , Jian Fu , Michael Ramalho , Paul Jones

Shepherd write-up for the draft:

** General Summary:
Ready to go with some issues.

The draft is well written and good to go for an experimental RFC after fixing the issues below.

** Detailed Review Items:

- Section 1, page 3, "and RTCP feedback reports with non-standard".

This "non-standard" will raise eyebrowns: It is probably good to mention here that the definition of standardized RTCP feedback messages is future work, as it has to be fleshed out what these feedback messages will "look like".


- Figure 3, page 6 and 7: Not a comment about the figure itself, but about the values of the constants.
I assume that you have good reasons for the values of the constants, such as theoretical assumptions and calculations, but also practical experience.

However, this is not specified and it also not specified how confident you are with these values. I guess that this is a bigger work item for the experimental phase, i.e., determining if these parameters are good or if they have to be adapted. Please mention this together with this figure and also in Section 8 about the experiments.


- Section 4.2, page 8: " set both t_last and t_curr as current time"
What granularity should this time reading provide?


- Section 4.2, page 8: ""below 100 ms"
Why is this 100 ms? Why couldn't this be 50 ms or 150 ms or any other value? This goes back to my comment above for Figure 3.


- Section 4.2, page 9: "The value of the threshold QTH may need
  to tuned for different operational enviornments."
This is again referring to my comment about Figure 3 and the parameters.
Here especially: What are different operational environments and are you able to express how the threshold may be affected by this.
Further, is this something that would need automatic tuning in later, standardized versions? I.e., beyond experimental deployments.


- Section 4.2, page 9: "Furthermore, the values of DLOSS and DMARK need to be set consistently across all NADA flows for them to compete fairly."
Does "across all flows" refers to all flows of a single node, i.e. locally, or across all flows in the network, i.e., globally, or something else?

- Section 5.1.2: "packets arriving out-of-order are
  discarded, and count towards losses."
Do you have a reasoning why out-of-order packets are counted as losses? This would be good to state here.


- Section 5.3: 3rd bullet point:
"Receiving rate (r_recv): the most recently measured receiving rate
      according to Section 5.1.3.  This information is expressed with a
      unit of bits per second (bps) in 32 bits (unsigned int).  This
      allows a maximum rate of approximately 4.3Gbps."

By today's measures, 4.3Gbps looks "far away", but we know that protocols are deployed for decades and 4.3 Gbps for video might look awfully slow in 2030. So, how do you ensure extensibility in this place?


- Section 6: Thank you for this!
This should, no it must, be linked to Section 8. As these points in Section 6 are subject to what will be explored in experimental setups.

- Section 8: The text is good, but I would link to Section 6 and also to the parameters in Figure 3.
I would also urge implementations and experimentation on real networks, not only in simulators. The current wording could suggest that simulationg different scenarios would be good.

Thanks and looking forward to your responses.

  Martin

Request for posting confirmation emailed to previous authors: rmcat-chairs@ietf.org, Stefano D'Aronco , Xiaoqing Zhu , Sergio de la Cruz , Rong Pan , Jian Fu , Michael Ramalho , Paul Jones

Request for posting confirmation emailed to previous authors: Stefano D'Aronco , Xiaoqing Zhu , Sergio de la Cruz , Rong Pan , Jian Fu , Michael Ramalho , Paul Jones

Request for posting confirmation emailed to previous authors: rmcat-chairs@ietf.org, Stefano D'Aronco , Xiaoqing Zhu , Sergio de la Cruz , Rong Pan , Jian Fu , Michael Ramalho , Paul Jones

Request for posting confirmation emailed to previous authors: Stefano D'Aronco , Xiaoqing Zhu , Sergio de la Cruz , Rong Pan , Jian Fu , Michael Ramalho , Paul Jones

Request for posting confirmation emailed to previous authors: Charles Ganzhorn , rmcat-chairs@ietf.org, Stefano D'Aronco , Xiaoqing Zhu , Sergio de la Cruz , Rong Pan , Jian Fu , Michael Ramalho , Paul Jones

Request for posting confirmation emailed to previous authors: rmcat-chairs@ietf.org, "Dr. Michael A. Ramalho" , "Sergio Mena de la Cruz" , "Xiaoqing Zhu" , "Paul Jones" , "Jian Fu" , "Rong Pan" , "Charles Ganzhorn" , "Stefano D'Aronco"