Skip to main content

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

Yes

(Mirja Kühlewind)
(Spencer Dawkins)

No Objection

(Alexey Melnikov)
(Alvaro Retana)
(Deborah Brungard)
(Martin Vigoureux)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 06 and is now closed.

Mirja Kühlewind Former IESG member
Yes
Yes (for -06) Unknown

                            
Spencer Dawkins Former IESG member
Yes
Yes (for -06) Not sent

                            
Adam Roach Former IESG member
No Objection
No Objection (2019-02-05 for -06) Sent
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..."
Alexey Melnikov Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2019-02-07 for -06) Sent
Please respond to the Gen-ART review.
Alvaro Retana Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Ben Campbell Former IESG member
No Objection
No Objection (2019-02-05 for -06) Sent
§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.
Benjamin Kaduk Former IESG member
No Objection
No Objection (2019-02-06 for -06) Sent
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.)
Deborah Brungard Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -06) Not sent