Subject: Re: [rmcat] AD review of draft-ietf-rmcat-eval-criteria-10

From: Joerg Ott <[email-masked]>
Date: Wed, 12 Feb 2020 17:03:53 +0100

Hi Mirja,

so, finally, we are getting there now that teaching is over...

> One high level comment:
> 
> The intro says:
> "This document only provides broad-level criteria for evaluating a new
>     congestion control algorithm. “
> However, this doc doesn’t really provide that much criteria, it rather specifies evaluation metrics and testing parameter/models. Under criteria I would rather understand something like we have for every test case (“In this scenario, the flows should share the available capacity roughly equally.”). I’m not proposing to extend this doc this way as most criteria might be scenario specific but it could at least say that criteria are further described with the test cases and then the intro could be adapted to better reflect the actual content of the doc.

The "criteria" (after which the doc was named originally) has probably
historic roots and specific criteria (and threshold, etc.) got lost
during splits over time.  I fixed the wording to no longer make an
explicit reference to criteria but just point to the specific other
documents for test cases.

> Other small technical comments:
> 
> - sec 4.2: Losses of 10% or 20% seems really high. Is that really needed? Where that values even used in any of the results presented?

We expect all IETF protocols to gracefully degrade in response to
increasingly severe situations.  This also implies avoiding that
protocols exhibit strange behavior once they leave their primary
operational range.  By extending the parameter space beyond just
sunshine conditions, we ensure that also less favorable conditions
are validated and compared.

I could add a note to this end, but I do not want to create the
assumption of some values being of secondary relevance only.
So will leave this as is.

> - sec 4.4: Do you maybe have a reference for the Gilbert-Elliot model? And what’s exactly meant by "losses generated by modeling a queue including its (different) drop behaviors”? Do you have a reference for that as well? Maybe there are also some IPPM RFCs that could be referred here?

I could include a reference here for Gilbert-Elliot such as:
http://www.ohohlfeld.com/paper/hasslinger_hohlfeld-mmb_2008.pdf

However, this not mandatory text and the second part of the sentence
is even less specific and does (deliberately) not give a specific
example.  We don't want to create any prejudice here beyond random
losses.  The Internet changes, after all.

As for IMPP, do you have specific ones in mind?  I am not familiar
with all IMPP work except that I looked a metrics -- but not loss
or other models.

Whatever we extend here may need more serious consideration and
weighting.  And going back to the WG.  Given that none of this would
be mandatory, we may opt not specify this in detail.

IIRC, the above text came from comments from the group beyond random
losses but without a clear mandate of what to pick.

> - I don’t quite understand this sentence in section 6.1:
> “This covers the case where the short TCP flows are not fetching a video file.”
> Wouldn’t it be better to say but case it does covers?
> Also you say file sizes of 30-50 KB: Should they be equally distributed?

Fixed.

I also looked again at the reference provided in the text.  This does no
longer yield the necessary resolution detail below 100K.  but the mean
still holds, yielding about 30 KB per request.

> Editorial comments/nits:
> 
> - Sec 3 maybe: s/The following are calculated based on/The following metrics are calculated based on/

Done.

> - It doesn’t seem that section 5 is needed at all, given draft-ietf-rmcat-wireless-tests is already mention in the intro.

Agree and removed.  Also, the wireless draft is already referred to in
the introduction, which I kept.

> - sec 6.2: "The currently chosen video streams are: Foreman and FourPeople.”
> “currently” is a bit weird here, maybe: “The following video streams are recommended for testing.”…?

Yupp, fixed.

> - sec 7: s/congestion control protocola/congestion control protocols/

Fixed -- and also fixed another typo around there.

Thanks much, Mirja, will submit this update now.

Best,
Jörg

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 12 Feb 2020 23:24:04 +0100

Hi Joerg,

Thanks for these updates. However, there were actually additional comments I’ve sent in a second mail right afterwards. Here are the comments again for your convince (mostly about references):

-----
Actually one more question: There is appendix A which reads like there is still work to do. Maybe that is information that should be rephrased and added in the intro?

Further the terminology section (2) references to a bunch of RTP document normatively. However, I don’t think this terminology is actually used in this draft. Can you please double-check and adapt the references accordingly!?

And again about the spilt between normative and informational. I think this document does not need to have the test RFCs as normative references (but only the other way around: test RFCs reference this doc normatively). However, given section 6.2., RFC8593 should probably be a normative reference.

And as I’m looking at the references: I think section 3 could probably reference more closely some sections of RFC5166.
——

I will request the IETF last call now nevertheless. You can fix these things after the last call or any time during the last. 

Thanks!
Mirja

> On 12. Feb 2020, at 17:03, Joerg Ott <[email-masked]> wrote:
> 
> Hi Mirja,
>

---

From: Joerg Ott <[email-masked]>
Date: Thu, 13 Feb 2020 18:21:03 +0100

Hi Mirja,

oops, my bad, I briefly looked at the other email, too, but thought
there wasn't much additional stuff in there.  Sorry.  I can do the
update as part of the LC process then.  To avoid confusion, I won't
post an immediate update (for some definition of immediate).

Best,
Jörg

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 13 Feb 2020 18:24:27 +0100

I’d be okay if you post an immediate update (if the intention is to remove some or most of appendix A) as having the appendix might be confusing as well. If there is no intention to remove the appendix (but maybe just rephrase it slightly) it could be more appropriate to do it afterwards… it's on you!

> On 13. Feb 2020, at 18:21, Joerg Ott <[email-masked]> wrote:
> 
> Hi Mirja,
>

---

From: Joerg Ott <[email-masked]>
Date: Fri, 14 Feb 2020 18:25:31 +0100

Ok, I will figure something out, most likely driven by time budget...