Subject: [rmcat] Ben Campbell's Yes on draft-ietf-rmcat-scream-cc-12: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 25 Oct 2017 13:06:29 -0700

Ben Campbell 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:
----------------------------------------------------------------------

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.

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 26 Oct 2017 07:29:07 +0000

Hi

And thanks for the review, comments inline marked [IJ]

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: den 25 oktober 2017 22:06
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Martin Stiemerling
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> Subject: Ben Campbell's Yes on draft-ietf-rmcat-scream-cc-12: (with
> COMMENT)
> 
> 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.)
> 
> 
[IJ] Interactive video it is, generally low latency video but nothing prevents the use of SCReAM with applications that have less stringent requirements on delay. Will replace with "such as interactive video"

> - 3.3: The MUST and MAY seem more like statements of fact than normative
[IJ] Yes, will replace with 'must' and 'may'. 
> - 4.1.2, last paragraph: The MAY seems like a statement of fact.
[IJ] Yes, will replace with 'may'
> - 4.1.2.3, last paragraph: Ditto for the SHOULD
[IJ] Not sure I am convinced. It order for the loss detection and congestion control adjustment to work properly, it is important to only react at most once per RTT, otherwise the bitrate can become reduced too much. 

> 3611 are needed to really understand this document, which would make
> them normative.
> 
[IJ] OK with me. Will move them to normative

---

From: Ben Campbell <[email-masked]>
Date: Thu, 26 Oct 2017 09:05:46 -0500

Hi, thanks for the response!

> On Oct 26, 2017, at 2:29 AM, Ingemar Johansson S <[email-masked]> wrote:
> 

The text says "Still it SHOULD be possible to increase the qdelay target if the qdelay continues to be high.” That sounds like a general statement about the possibility. Is that intended to ask implementations to _make_ it possible? If so, it would help to clarify the actor and specific action that the SHOULD applies to.

[Otherwise, your responses all look fine.]

Thanks!

Ben.

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 26 Oct 2017 18:16:47 +0000

Hi

Regarding the comment on 4.1.2.3   Realized that I looked in the wrong section. I will rewrite this section completely to make it more comprehensible.

Regards
Ingemar

> Sent: den 26 oktober 2017 16:06
> To: Ingemar Johansson S <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Ben Campbell's Yes on draft-ietf-rmcat-scream-cc-12: (with
> COMMENT)
> 
> > On Oct 26, 2017, at 2:29 AM, Ingemar Johansson S
> <[email-masked]> wrote:
> >
> > [IJ] Not sure I am convinced. It order for the loss detection and congestion
> control adjustment to work properly, it is important to only react at most
> once per RTT, otherwise the bitrate can become reduced too much.
> 
> 
> The text says "Still it SHOULD be possible to increase the qdelay target if the
> qdelay continues to be high.” That sounds like a general statement about the
> possibility. Is that intended to ask implementations to _make_ it possible? If
> so, it would help to clarify the actor and specific action that the SHOULD
> applies to.
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 26 Oct 2017 19:40:54 +0000

Hi
I just submitted an updated version that should address the DISCUSS as well as the Comments.

Regards
/Ingemar

======
A new version of I-D, draft-ietf-rmcat-scream-cc-13.txt has been successfully submitted by Ingemar Johansson and posted to the IETF repository.

Name:		draft-ietf-rmcat-scream-cc
Revision:	13
Title:		Self-Clocked Rate Adaptation for Multimedia
Document date:	2017-10-26
Group:		rmcat
Pages:		38
URL:            https://www.ietf.org/internet-drafts/draft-ietf-rmcat-scream-cc-13.txt 
Status:         https://datatracker.ietf.org/doc/draft-ietf-rmcat-scream-cc/ 
Htmlized:       https://tools.ietf.org/html/draft-ietf-rmcat-scream-cc-13 
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-scream-cc-13 
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-scream-cc-13 

Abstract:
   This memo describes a rate adaptation algorithm for conversational
   media services such as interactive 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.

======================

> From: Ingemar Johansson S [mailto:[email-masked]]
> Sent: den 26 oktober 2017 20:17
> To: Ben Campbell <[email-masked]>
> Subject: RE: Ben Campbell's Yes on draft-ietf-rmcat-scream-cc-12: (with
> COMMENT)
> 
> Hi
> 
> Regarding the comment on 4.1.2.3   Realized that I looked in the wrong
> section. I will rewrite this section completely to make it more
> comprehensible.
> 
> Regards
> Ingemar
> 
> > control adjustment to work properly, it is important to only react at
> > most once per RTT, otherwise the bitrate can become reduced too much.
> >
> >
> > The text says "Still it SHOULD be possible to increase the qdelay
> > target if the qdelay continues to be high.” That sounds like a general
> > statement about the possibility. Is that intended to ask
> > implementations to _make_ it possible? If so, it would help to clarify
> > the actor and specific action that the SHOULD applies to.
> >