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

[Ballot discuss]
I'm confused about whether the text in this document is intended to form a normative description of SCReAM. The document contains the following statement:

  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.

This effectively states that the cited C++ code forms the normative specification of the SCReAM algorithm, and that this document is a non-normative companion to help understand the normative code.

If this is the case, then:

- The [SCReAM-CPP-implementation] reference needs to be moved from "Informative References" to "Normative References",

- The abstract and introduction need to make it much clearer that the normative definition of the SCReAM algorithm is a body of C++ code rather than the prose and psuedocode in this document, and

- We need to coordinate with the RFC editor to ensure proper archival of the code at [SCReAM-CPP-implementation]. At this time, github.com does not meet the standards of archival quality that the RFC series is expected to meet.

If the C++ implementation is *not* the normative definition of SCReAM, then the psuedocode and definitions in this document need to be complete and sufficient to implement the algorithm; and, in particular, it cannot omit algorithm details "for reasons of readability."

[Ballot comment]
Section 5 indicates:

  o  Support for alternate ECN semantics: This specification adopts the
      proposal in [I-D.ietf-tcpm-alternativebackoff-ecn] to reduce the
      congestion window less when ECN based congestion events are
      detected.

This needs some clarification. While the psuedocode in section 4.1.2.2 has two different code paths for ECN- versus non-ECN-congestion, they differ only in terms of whether they reduce the CWND according to BETA_LOSS versus BETA_ECN. Section 4.1.1.1 defines the RECOMMENDED value for both of these constants as 0.8. If these are the same value, then treatment of ECN will be identical to treatment of loss, right?

I suspect that either (a) one of these values was intended to be different than the other, or (b) I've missed some additional ECN-related handling that provides differential treatment. If neither is true, please amend the statement in Section 5 to be more accurate (i.e.: the algorithm supports differential handling, but the normatively recommended configuration does not provide it).

___

The document talks extensively about ECN, without ever making it clear whether the SCReAM algorithm works without ECN. The final paragraph of section 4.2.1 sort of implies that it is optional; but this is very late in the document, and it isn't very explicit. I would suggest adding text to the introduction that indicates that the algorithm can take advantage of ECN information when it is present, but that it does not require ECN to work properly.

___

Minor editorial comments follow.

Section 1.2:

  the RTP queue is kept short (preferably empty).  In addition the
  output from a video encoder is rarely constant bitrate, static
  content (talking heads) for instance gives almost zero video rate.

I think you mean "bit rate" rather than "video rate."


Section 4.1.1.1:

  QDELAY_WEIGHT (0.1)
    Averaging factor for qdelay_fraction_avg.

  QDELAY_TREND_TH (0.2)
    Averaging factor for qdelay_fraction_avg.

  QDELAY_TREND_TH (0.2)
    Averaging factor for qdelay_fraction_avg.

All three of these appear to have the same definition, and the last two appear to have the same name.


Please expand ECN and EWMA on first use.

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

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

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

The IANA Services Operator has reviewed draft-ietf-rmcat-scream-cc-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
IANA Services Specialist

1. Summary

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

  This memo describes a rate adaptation algorithm for conversational
  media services such as video.  The solution conforms to the packet
  conservation principle and uses a hybrid loss and delay based
  congestion control algorithm.  The algorithm is evaluated over both
  simulated Internet bottleneck scenarios as well as in a Long Term
  Evolution (LTE) system simulator and is shown to achieve both low
  latency and high video throughput in these scenarios.

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.

The WG is aware of the IPR notice no. 2890 posted on 2016-10-07.

4. Other Points

This document is experimental, as a number of technical parameters have to be tested under real network conditions, as described in Section 7.  "Suggested experiments." The current set of parameters and algorithms have been mainly evaluated in a simulator. The WG will collect the feedback from first experiments using SCREAM and use them to discuss futher steps.

1. Summary

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

  This memo describes a rate adaptation algorithm for conversational
  media services such as video.  The solution conforms to the packet
  conservation principle and uses a hybrid loss and delay based
  congestion control algorithm.  The algorithm is evaluated over both
  simulated Internet bottleneck scenarios as well as in a Long Term
  Evolution (LTE) system simulator and is shown to achieve both low
  latency and high video throughput in these scenarios.

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.

The WG is aware of the IPR notice no. 2890 posted on 2016-10-07.

4. Other Points

This document is experimental, as a number of technical parameters have to be tested, as described in Section 7.  Suggested experiments. The WG will collect the feedback from first experiments using SCREAM and use them to discuss futher steps.

The following Last Call announcement was sent out (ends 2017-10-23):

From: The IESG
To: IETF-Announce
CC: rmcat-chairs@ietf.org, rmcat@ietf.org, mls.ietf@gmail.com, ietf@kuehlewind.net, draft-ietf-rmcat-scream-cc@ietf.org, Martin Stiemerling
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Self-Clocked Rate Adaptation for Multimedia) to Experimental RFC


The IESG has received a request from the RTP Media Congestion Avoidance
Techniques WG (rmcat) to consider the following document: - 'Self-Clocked
Rate Adaptation for Multimedia'
  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 2017-10-23. 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 memo describes a rate adaptation algorithm for conversational
  media services such as video.  The solution conforms to the packet
  conservation principle and uses a hybrid loss and delay based
  congestion control algorithm.  The algorithm is evaluated over both
  simulated Internet bottleneck scenarios as well as in a Long Term
  Evolution (LTE) system simulator and is shown to achieve both low
  latency and high video throughput in these scenarios.




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

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

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

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

1. Summary

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

  This memo describes a rate adaptation algorithm for conversational
  media services such as video.  The solution conforms to the packet
  conservation principle and uses a hybrid loss and delay based
  congestion control algorithm.  The algorithm is evaluated over both
  simulated Internet bottleneck scenarios as well as in a Long Term
  Evolution (LTE) system simulator and is shown to achieve both low
  latency and high video throughput in these scenarios.

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.

The WG is aware of the IPR notice no. 2890 posted on 2016-10-07.

4. Other Points

There are no other points.