Subject: [rmcat] Update of draft-ietf-rmcat-scream-cc (was RE: Shepherd review of draft-ietf-rmcat-scream-cc-07)

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 29 May 2017 15:26:10 +0000

Hi

With the latest update I believe that the review comments by Martin should be addressed

Regards
Ingemar 

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

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

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.

> -----Original Message-----
> From: Ingemar Johansson S [mailto:[email-masked]]
> Sent: den 16 mars 2017 15:37
> To: Martin Stiemerling <[email-masked]>; rmcat WG ([email-masked])
> <[email-masked]>
> Cc: [email-masked]
> Subject: RE: [rmcat] Shepherd review of draft-ietf-rmcat-scream-cc-07
> 
> Hi
> 
> Thanks for the review, comments inline.
> 
> /Ingemar
> 
> > -----Original Message-----
> > From: Martin Stiemerling [mailto:[email-masked]]
> > Sent: den 15 mars 2017 10:18
> > To: rmcat WG ([email-masked]) <[email-masked]>
> > Subject: [rmcat] Shepherd review of draft-ietf-rmcat-scream-cc-07
> >
> > Dear all,
> >
> > Please find here the document shepherd review of
> >
> > Summary:
> > Draft is not ready for submitting it to the AD, as it has a few items
> > to be checked first which are formal issues and but no technical flaws!
> >
> > Issues:
> > 1) ID nits has a number of issues, noteable these:
> >
> > a) The copyright year in the IETF Trust and authors Copyright Line
> > does not match the current year
> > b) The document doesn't use any RFC 2119 keywords, yet has text
> > resembling RFC 2119 boilerplate text.
> > c) Found something which looks like a code comment -- if you have code
> > sections in the document, please surround them with '<CODE BEGINS>'
> > and '<CODE ENDS>' lines.
> >
> > a) is easily fixable, when recompiling the draft
> [IJ] OK
> 
> >
> > 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.
> 
> >
> > c) a bit of work, but easily fixable.
> [IJ] OK
> 
> >
> > Other comments beyond idnits:
> >
> > - Section 4.1.1.1: 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 (https://www.ietf.org/proceedings/96/slides/slides-96-
> rmcat-0.pdf ), 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.
> 
> >
> > - Section 4.1.1.1, 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 ?
> 
> >
> >
> > - 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.
> 
> >
> > Thanks,
> >
> >    Martin
> >