Video Traffic Models for RTP Congestion Control Evaluations
draft-ietf-rmcat-video-traffic-model-07

[Ballot comment]
Thank you for the easy-to-read, well-written document.  I just have a few
minor (IIUC) editorial comments.

Section 4

Do we need to define I-frame?  (And P-frame, in Section 6.1 later.)

Section 6.1

Could the text (either here or in a previous section) call out more clearly
that n_s is a (new) defined parameter for the simulation?

Section 6.2.1

I think I'm missing a qualifier somewhere -- in the first bullet point of
the main algorithm, we see that:

                                                      It is assumed that
      the value of R_v is clipped within the range [R_min, R_max].

but later on the section we calculate frame sizes for cases where  b) R_v <
r_min , and c) r_v >= R_max.  What am I missing that makes these two places
in the text different?

                  factor = R_v / R_min

Does it matter if I use integer or floating-point arithmetic to compute
'factor'?  (Same question for R_max as well, of course.)

[Ballot comment]
Thanks everyone who worked on this document.

As a general comment: the various discussions of intra frame generation might
benefit from a reference to the FIR behavior described in section 4.3.1 of RFC
5014. The current description seems focused on local decisions to generate
intra frames, where the sender is in control of when such frames should be
generated. It seems that receiver-requested I frames should also be considered
by any party making use of these models.

---------------------------------------------------------------------------

§3:

>  In the presence of a
>  significant change in target rate, the encoder output frame sizes
>  sometimes fluctuates for a short, transient period of time before the
>  output rate converges to the new target.

Nit: "...frame sizes sometimes fluctuate..." or "...frame size sometimes
fluctuates..."

[Ballot comment]
§3: I am a little surprised not to see much discussion of how much variation in behavior you expect from different real-world encoders. I think the models probably have enough knobs to handle this, but an overview discussion would be helpful.

§6: From reading further, I understand the real-world encoder creates a library of frames to be sent during testing. If that is correct, it would be helpful to say a few words about it in the opening paragraphs.

§10: It's not obvious to me how the listed consideration is security related. I am willing to believe it is, but some words to tie it to security would be helpful.

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

The IANA Functions Operator has reviewed draft-ietf-rmcat-video-traffic-model-06, 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
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-01-28):

From: The IESG
To: IETF-Announce
CC: rmcat-chairs@ietf.org, draft-ietf-rmcat-video-traffic-model@ietf.org, Colin Perkins , rmcat@ietf.org, ietf@kuehlewind.net, csp@csperkins.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Video Traffic Models for RTP Congestion Control Evaluations) to Informational RFC


The IESG has received a request from the RTP Media Congestion Avoidance
Techniques WG (rmcat) to consider the following document: - 'Video Traffic
Models for RTP Congestion Control Evaluations'
  as Informational 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 2019-01-28. 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 document describes two reference video traffic models for
  evaluating RTP congestion control algorithms.  The first model
  statistically characterizes the behavior of a live video encoder in
  response to changing requests on target video rate.  The second model
  is trace-driven, and emulates the output of actual encoded video
  frame sizes from a high-resolution test sequence.  Both models are
  designed to strike a balance between simplicity, repeatability, and
  authenticity in modeling the interactions between a live video
  traffic source and the congestion control module.  Finally, the
  document describes how both approaches can be combined into a hybrid
  model.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rmcat-video-traffic-model/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-rmcat-video-traffic-model/ballot/


No IPR declarations have been submitted directly on this I-D.

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 2012.
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?  Why
> is this the proper type of RFC?  Is this type of RFC indicated in the
> title page header?

Informational.

This was chosen because the draft gives guidelines for evaluation
of congestion control algorithm candidates but doesn't specify an
algorithm or protocol in itself. As such, there is no requirement
that it be standards track or BCP.

This is indicated in the title page header.

> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary
>
>  Relevant content can frequently be found in the abstract
>  and/or introduction of the document. If not, this may be
>  an indication that there are deficiencies in the abstract
>  or introduction.

  This document describes two reference video traffic models for evaluating
  RTP congestion control algorithms. One is based on a statistical model of
  a live video encoder, the other is trace-driven and models the output of
  a real video encoder. These are intended to supply input data to be used
  during evaluation of congestion control algorithms for interactive RTP
  media flows under development in the RMCAT working group.

> Working Group Summary
>
>  Was there anything in WG process that is worth noting? For
>  example, was there controversy about particular points or
>  were there decisions where the consensus was particularly
>  rough?

  The initial individual draft was submitted for IETF 91, and was adopted
  as a working group draft for IETF 95. Development has not moved quickly,
  but there was little controversy. Rather, the relatively slow pace of
  development reflects a desire to ensure the model is realistic and is
  implementable.

> Document Quality
>
>  Are there existing implementations of the protocol? Have a
>  significant number of vendors indicated their plan to
>  implement the specification? Are there any reviewers that
>  merit special mention as having done a thorough review,
>  e.g., one that resulted in important changes or a
>  conclusion that the document had no substantive issues? If
>  there was a MIB Doctor, Media Type or other expert review,
>  what was its course (briefly)? In the case of a Media Type
>  review, on what date was the request posted?

  The authors have made available an open source implementation of the
  model described in the draft. The draft has been widely reviewed by
  the working group over a number of years. There is no need for MIB
  doctor, media type, or other expert review,

> Personnel
>
>  Who is the Document Shepherd? Who is the Responsible Area
>  Director?

  The document shepherd is Colin Perkins.
  The responsible AD is Mirja Kuehlewind.

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.

  The document shepherd reviewed the draft in detail during the WG last
  call in July 2018, and found only relatively minor issues. These were
  addressed, along with minor nits found by other WG members, and the
  draft was updated and discussed at IETF 103. It was determined that
  the issues had been addressed, and there were no remaining concerns,
  so the draft is being forwarded to the IESG.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

  No concerns.

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.

  No such review needed.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

  No concerns.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.

  Each author has confirmed this.

> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

  No IPR disclosure has been filed.

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it? 

  There is solid consensus. No objections have no raised.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)

  There is no such discontent.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

  The idnits tool reports no issues.

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.

  No such review needed.

> (13) Have all references within this document been identified as
> either normative or informative?

  Yes.

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state? If such normative
> references exist, what is the plan for their completion?

  No such references.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

  No downward normative references.

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

  No such status changes are made.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

  No IANA actions are needed.

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

  No IANA actions are needed.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.

  No formal checks have been made on the code fragments, but the authors
  have done extensive simulations using their open source implementation
  to validate the approach taken, and have repeatedly confirmed that the
  code is in sync with that implementation.