Subject: [rmcat] AD review of draft-ietf-rmcat-scream-cc

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 6 Oct 2017 22:17:43 +0200

Hi Ingemar, hi all,

first of all sorry for the long delay. I think we need a quick update before we can go to IEFT last call. There are a couple of normative statements where no normative language should be used (see the list below). Note that only things that are guidance for the implementation can be normative. That means even though the words ‚may' or ‚must' are used for e.g. describing something than can or will happen in the network, it cannot be normative. Not all ‚may‘ and ‚must‘ must be written in upper case. In those cases I propose below to use ‚can‘ or ‚have to‘ instead to be clear but one could also just use lower case ‚may‘ and ‚must‘.

   Sec 1 (incl. 1.1): 
   "Applications that are deployed in the Internet MUST employ congestion
   control, …“
   s/MUST/have to/
   and
   „… as the transmission channel bandwidth MAY vary over time.“
   s/MAY/can/
   and
   „… SHOULD be both quick and be able to operate over a large
   range in channel capacity.“
   s/SHOULD/should/
   and
   "The network throughput MAY vary
   considerably for instance in cases where the wireless terminal is
   moving around.“
   s/MAY/can/
   and
   „… the network throughput MAY drop for short time intervals…“
   s/MAY/can/
   and
   "an RMCAT flow in that bearer SHOULD reduce the sending rate quite quickly“
   s/SHOULD/aims to/
   and in sec 3.3:
   „… it MAY be necessary to implement additional actions …“
   s/MAY/can/
   and sec 4.1.1.1
   „The target qdelay MUST NOT be initialized to this high value…“
   s/MUST NOT/does not have to/
   Note: this one really changes the meaning because 'MUST NOT' would mean you can not used the proposed value!
   in sec 4.1.2
   „... and MAY have the effect that …“
   s/MAY/can/
   in sec 4.1.2.2:
   "Still it SHOULD be possible to increase the qdelay target if the qdelay
   continues to be high.“
   and sec 4.1.2.4:
   "the one way delay in the reverse direction MAY jump due to congestion“
   s/MAY/can/
   sec 4.1.3:
   „...that MAY itself cause an unnecessary rate reduction...“
   s/MAY/can/
   also sec 4.1.3:
   "The aware reader MAY notice the dependency on the qdelay...“
   s/MAY/may/
   also sec 4.1.3:
   „...one MAY suspect some odd interaction
   between the media rate control and the network congestion control…"
   s/MAY/may/
   sec 4.2.1:
   "In a typical use case, no more than four Loss RLE chunks SHOULD be
   needed...“
   s/SHOULD be/are/
   also sec 4.2.1
   "The more bulky format MAY be nevertheless be useful
      for e.g ECN black-hole detection.“
   s/MAY be/could/
   sec 4.2.2:
   „… immediate or early mode is not
   REQUIRED by SCReAM but MAY nonetheless be useful for e.g RTCP
   messages not directly related to SCReAM.“
   s/REQUIRED/required/
   s/MAY/can/
   sec 5:
   "Future work on Low Loss Low Latency for Scalable throughput (L4S) 
   MAY lead to updates in a future RFC that describes SCReAM support for L4S.“
   s/MAY/may/
   also sec 5:
   "A new RFC4585 transport layer feedback message MAY to be
      standardized…“
   s/MAY/could/
   sec 7:
   „...it MAY be necessary to use different values…“
   s/MAY/may/

Also in the following sentence you can use normative language but RECOMMENDED basically means SHOULD but I believe you probably rather want to use a MAY here. 
sec 4.1.2.2.: 
OLD
"It is therefore
   RECOMMENDED that the algorithm described in this section is turned
   off it is deemed unlikely that competing flows occur over the same
   bottleneck“
NEW:
„If it is deemed unlikely that competing flows occur over the same
   bottleneck, the algorithm described in this section MAY be turned
   off."
And maybe even add another sentence to further clarify why this is a MAY:
„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 traffic."

Further, there are quite a few cases where normative language could/should be used but is not, e.g. in se 4.1.2
OLD
„… further detected lost RTP packets are ignored for a full smoothed round trip time…“
NEW
"further detected lost RTP packets SHOULD be ignored for a full smoothed round trip time“

There are probably more cases. It would also be okay to not use normatively language at all if that’s easier for you. Or I or maybe Martin as the shepherd can help if this is unclear. However, it’s more important to remove the wrong use of normative languages as listed above and less important to use normative language, given this is a sender-side only congestion control scheme.

@Martin: One request regarding the shepherd write-up: Can you maybe add a note explaining why this is experimental. I know it’s charter as experimental first, however, it could be good for the other ADs to know that this has been so far only tested in simulations but it deemed to be safe for experimentation in the Internet now and that after that experimentation phase the group is charter to go for proposed standard.

Also maybe have another look at the security consideration section. This seems rather short and I can imagine that we will get some questions in the sec-dir review e.g. regarding the safety of using scream in the Internet and co-existence/fairness with other schemes.

See below for some more mostly editorial comments. Given you have to update it would probably be good to address those as well where appropriate.

Mirja

----------------------------------------
1) The intro does not really say that this congestion is designed for the use with RTP traffic. I think it would help to say this early on (and give a reference to RTP).

2) Also in the intro:
   Please at a reference for WebRTC (and eventually expand the acronym) 

3) sec 4.1.1.2: min_cwnd is a constant and should be moved to 4.1.1.1 and written in upper letters (in the whole doc)

4) Sec 4.1.2: I would recommend to move the autocorrelation function R into the body of the document. It is not much text and probably easier for an implementor to read.

5) Sec 4.1.2: I would recommend to split out the part on reaction to loss/ECN as a separate sub subsection, meaning just add a new heading before the paragraph that starts with "A loss event is indicated…“

6)4.1.2.1: I don’t understand this:
The text say:
„… this specification however
      limits the gain when CWND is increased dependent on near
      congestion state and the relation to the last known max CWND
      value.“
However, the pseudo code only say
"gain_t = GAIN“
Is there something missing? 

7) sec 4.1.2.2: maybe use a more meaningful name for oh_t

8) I guess even the text on stream privatization (A.1.) should just be moved somewhere in the body of the doc (e.g. as a subsection of the discussion section (5) or a completely new own section)

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 9 Oct 2017 12:46:22 +0000

Hi
And thanks for a very thorough read-trough. I have implemented all of your suggested changes in the new version and also added normative language where it is actually needed.
An updated version is submitted soon

>Is there something missing?
You are right, SCReAM in fact does this in pretty much the same was as LEDBAT does, as a result I removed this statement completely. 

As regards to the security considerations. I am not sure what more information that should be added so I may need to wait for the review comments.

/Ingemar

> -----Original Message-----
> From: Mirja Kuehlewind (IETF) [mailto:[email-masked]]
> Sent: den 6 oktober 2017 22:18
> To: [email-masked]
> Cc: rmcat WG ([email-masked]) <[email-masked]>
> Subject: AD review of draft-ietf-rmcat-scream-cc
> 
> Hi Ingemar, hi all,
> 
> first of all sorry for the long delay. I think we need a quick update before we
> can go to IEFT last call. There are a couple of normative statements where no
> normative language should be used (see the list below). Note that only
> things that are guidance for the implementation can be normative. That
> means even though the words ‚may' or ‚must' are used for e.g. describing
> something than can or will happen in the network, it cannot be normative.
> Not all ‚may‘ and ‚must‘ must be written in upper case. In those cases I
> propose below to use ‚can‘ or ‚have to‘ instead to be clear but one could also
> just use lower case ‚may‘ and ‚must‘.
> 
>    Sec 1 (incl. 1.1):
>    Note: this one really changes the meaning because 'MUST NOT' would
> mean you can not used the proposed value!
>    in sec 4.1.2
> Also in the following sentence you can use normative language but
> RECOMMENDED basically means SHOULD but I believe you probably rather
> want to use a MAY here.
> sec 4.1.2.2.:
> OLD
> "It is therefore
> „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 traffic."
> 
> Further, there are quite a few cases where normative language could/should
> be used but is not, e.g. in se 4.1.2 OLD „… further detected lost RTP packets
> are ignored for a full smoothed round trip time…“ NEW "further detected lost
> RTP packets SHOULD be ignored for a full smoothed round trip time“
> 
> There are probably more cases. It would also be okay to not use normatively
> language at all if that’s easier for you. Or I or maybe Martin as the shepherd
> can help if this is unclear. However, it’s more important to remove the wrong
> use of normative languages as listed above and less important to use
> normative language, given this is a sender-side only congestion control
> scheme.
> 
> @Martin: One request regarding the shepherd write-up: Can you maybe add
> a note explaining why this is experimental. I know it’s charter as
> experimental first, however, it could be good for the other ADs to know that
> this has been so far only tested in simulations but it deemed to be safe for
> experimentation in the Internet now and that after that experimentation
> phase the group is charter to go for proposed standard.
> 
> Also maybe have another look at the security consideration section. This
> seems rather short and I can imagine that we will get some questions in the
> sec-dir review e.g. regarding the safety of using scream in the Internet and
> co-existence/fairness with other schemes.
> 
> See below for some more mostly editorial comments. Given you have to
> update it would probably be good to address those as well where
> appropriate.
> 
> Mirja
> 
> 1) The intro does not really say that this congestion is designed for the use
> with RTP traffic. I think it would help to say this early on (and give a reference
> to RTP).
> 
> 2) Also in the intro:
> 3) sec 4.1.1.2: min_cwnd is a constant and should be moved to 4.1.1.1 and
> written in upper letters (in the whole doc)
> 
> 4) Sec 4.1.2: I would recommend to move the autocorrelation function R into
> the body of the document. It is not much text and probably easier for an
> implementor to read.
> 
> 5) Sec 4.1.2: I would recommend to split out the part on reaction to loss/ECN
> as a separate sub subsection, meaning just add a new heading before the
> paragraph that starts with "A loss event is indicated…“
> 
> 8) I guess even the text on stream privatization (A.1.) should just be moved
> somewhere in the body of the doc (e.g. as a subsection of the discussion
> section (5) or a completely new own section)
> 
> 
> 
> 
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 10 Oct 2017 09:04:52 +0200

Okay. Thanks! I’ve requested the IETF last cast!
Mirja

> Am 09.10.2017 um 14:46 schrieb Ingemar Johansson S <[email-masked]>:
> 
> Hi