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