Re: [rmcat] Shepherd review of draft-ietf-rmcat-scream-cc-07

Martin Stiemerling <> Mon, 27 March 2017 06:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0DE841274D0; Sun, 26 Mar 2017 23:03:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s4SOhL7Epvpd; Sun, 26 Mar 2017 23:03:43 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 191861293DA; Sun, 26 Mar 2017 22:58:38 -0700 (PDT)
Received: by with SMTP id u1so39196744wra.2; Sun, 26 Mar 2017 22:58:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Oa0Y80SEED3mTQM5Sb7JywoLH7IlqxATtZJCnRq8Ziw=; b=CifFROX0BKh9w8dGmD98hA8pR1E6392QrMIh92uDymjluJIGWQ6fYyuhdEPtaiN7yj auaHpSQH13QtAiTOutEC3asdIFaWtozUlfXR29BEa5z8e68Ud5OKL3bXze9F3UHFQkbt gwuBKS4N/KlMZrbCNfySXKvDV1I6cAr0AK9DSVzAZSEyrj+Lm3+Ua1Z10wJnqvef16V3 tDE8gfQWwnxb1pzFmZkxQahKiqVhjdh12cUT93YQ6cZbwb5R78RX+M8oNaXnxbqi8Mv7 sOS5WijZXljcfIJsd2t4KkbTWMDIrpfvl33JILUbdIaVg/n8wPH4MUlWEeRZFI8M6U01 CGWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Oa0Y80SEED3mTQM5Sb7JywoLH7IlqxATtZJCnRq8Ziw=; b=cF0/Rw7DHp4J5f+S2iGDSYF+b9Ln08I5J3cURbF/pI7YpvmNT88+Q45J28SPNo9SJF yGnG9Wikd2tinXszyRSf5T5H3ukWEOmSN7YTZldaCFlZmP6RNf4JxrFFYZoTM5oYXgok gavncN+1egWWapKrrQFniGVXpNxbZN2aTXATAOIT7b/t25muselLbD366E2C40QtsucL P6KCts2LQEo6z8+F9u324vM9JxRxNLAkMZlnqAJUs/EH8309v+oGuqZWxqGkMnkEZaam lmz+Juwdf9jaCel8IpshqvADQkjcHklwrm636Pt38NzdgrycEjrFGhkGJrC+HK/DKCIa 8sjg==
X-Gm-Message-State: AFeK/H19iIY4oN1FDSg99WMwcIoD7DbHGgBf/AfXYIfgHhB4Hv8FVIhqGL08ugIWx2RObQ==
X-Received: by with SMTP id m52mr1498539wrm.201.1490594316362; Sun, 26 Mar 2017 22:58:36 -0700 (PDT)
Received: from mn-mn0F-2.local ([2a01:598:89c3:9fc3:690f:2515:3d51:4bee]) by with ESMTPSA id l70sm7227705wrc.40.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Mar 2017 22:58:35 -0700 (PDT)
To: Ingemar Johansson S <>, "rmcat WG (" <>
References: <> <>
Cc: "" <>
From: Martin Stiemerling <>
Message-ID: <>
Date: Mon, 27 Mar 2017 07:58:27 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [rmcat] Shepherd review of draft-ietf-rmcat-scream-cc-07
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Mar 2017 06:03:45 -0000

Hi Ingemar, all,

Am 16.03.17 um 15:36 schrieb Ingemar Johansson S:
> Hi
> Thanks for the review, comments inline.
> /Ingemar
>> -----Original Message----- From: Martin Stiemerling
>> [] Sent: den 15 mars 2017 10:18 To: rmcat
>> WG ( <> Subject: [rmcat] Shepherd
>> review of draft-ietf-rmcat-scream-cc-07
>> b) This is a bigger issue: The draft specifies a number of protocol
>> behaviors, but is never using any of the RFC 2119 keywords. While
>> not using the RFC 2119 keywords is acceptable for an experimental
>> draft it is troublesome on the long run. The intention is for sure
>> to move this draft to standards track, once the experimental phase
>> is over. However, at this later stage RFC 2119 key words will be
>> required.
> [IJ] OK, yes. This can take a few hours to fix, should not be too
> troublesome, I hope. I had worse issues with rfc6236 as the RFC2119
> keywords had to be chosen carefully in light of existing SDP and SIP
> specs. This one should be more simple, I hope.

Ok, I will wait for the updated version.

>> c) a bit of work, but easily fixable.
> [IJ] OK
>> Other comments beyond idnits:
>> - Section It says that the constantns are deduced from
>> experiments. In what context have these experiments been specified,
>> carried out and documented? Is this something you can refer you?
>> The current text is a bit underspecified in that respect.
> [IJ] There are experiments results presented at the RMCAT meetings,
> last time was  in Berlin
> ( ),
> It is possible that I can present new results soon. Question is in
> which form should the results be presented ?. Is material presented
> at RMCAT sufficient.

A reference to this would be just good!

>> - Section, page 10, bottom: " TARGET_BITRATE_MIN Min target
>> bitrate [bps].
>> TARGET_BITRATE_MAX Max target bitrate [bps]. "
>> I assume that the notion [bps] shall introduce the unit of this
>> constant. Please specify that this is the notion you are using for
>> specifying the unit.
> [IJ] If I understand it correct you mean that I should specify that
> [bps] indicate the unit "bits per second", right ?

Yes, and also introducing that the notation of "[]" in this case means a 
statement of the unit to be used.

>> - Section 9. IANA Considerations: This is not section for IANA but
>> more a question for the WG. Please remove the text from this
>> section and place it in a new section "Open Issues" or similar.
>> There is currently no request to IANA. Please state just this and
>> the request to remove the section before publication as RFC.
> [IJ] OK
>> - Appendix A.4 looks like a regular section, with the note that
>> this is an experimental version and needs further vetting during
>> the experimentation period, isn't it?
> [IJ] Yes. The proposed feedback while waiting for some kind of
> generic feedback, this is the best one can do with existing
> standardized feedback. The feedback intensity is verified in
> simulator over a large range of bitrates, and also verified in an
> experimental testbed for a high quality video solution over LTE/5G.
> The objective has been to ensure a feedback rate that is not overly
> high and that at the same time does not limit throughput. It is not
> ruled out that the equations in section A.4.2 may change during the
> experimentation period.

How about adding at the top of A.4 what you replied to me, at least 
roughly? This will help to get other reviews a better understanding.

Thank you,