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

Joerg Ott <> Wed, 12 February 2020 16:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA39D120013; Wed, 12 Feb 2020 08:04:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hRa0Hic-snxK; Wed, 12 Feb 2020 08:04:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A9D41200E7; Wed, 12 Feb 2020 08:03:58 -0800 (PST)
Received: by (Postfix, from userid 107) id CAD1D1C07E6; Wed, 12 Feb 2020 17:03:55 +0100 (CET)
Received: (Authenticated sender: ott) by (Postfix) with ESMTPSA id 5C7661C07DD; Wed, 12 Feb 2020 17:03:53 +0100 (CET) (Extended-Queue-bit
To: Mirja Kuehlewind <>,
References: <>
From: Joerg Ott <>
Message-ID: <>
Date: Wed, 12 Feb 2020 17:03:53 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [rmcat] AD review of draft-ietf-rmcat-eval-criteria-10
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Feb 2020 16:04:05 -0000

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:

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?


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/


> - 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.