Re: [rmcat] Benjamin Kaduk's No Objection on draft-ietf-rmcat-eval-criteria-12: (with COMMENT)

Joerg Ott <jo@netlab.tkk.fi> Thu, 19 March 2020 15:08 UTC

Return-Path: <jo@netlab.tkk.fi>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E613A0363; Thu, 19 Mar 2020 08:08:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiUq3nEepCOS; Thu, 19 Mar 2020 08:08:39 -0700 (PDT)
Received: from smtp-out-01.aalto.fi (smtp-out-01.aalto.fi [130.233.228.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815163A02BE; Thu, 19 Mar 2020 08:08:37 -0700 (PDT)
Received: from smtp-out-01.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id B81C611565E_E738AF3B; Thu, 19 Mar 2020 15:08:35 +0000 (GMT)
Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-out-01.aalto.fi (Sophos Email Appliance) with ESMTP id 8A482115504_E738AF3F; Thu, 19 Mar 2020 15:08:35 +0000 (GMT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 737491E13A; Thu, 19 Mar 2020 17:08:35 +0200 (EET)
X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi
Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BcT9DAox3nzr; Thu, 19 Mar 2020 17:08:30 +0200 (EET)
Received: from [192.168.0.102] (ip5f5bede2.dynamic.kabel-deutschland.de [95.91.237.226]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id B2D331E138; Thu, 19 Mar 2020 17:08:29 +0200 (EET)
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
Cc: rmcat-chairs@ietf.org, varun.singh@iki.fi, draft-ietf-rmcat-eval-criteria@ietf.org, Martin Stiemerling <mls.ietf@gmail.com>, rmcat@ietf.org, csp@csperkins.org
References: <158340265948.14598.6334057012764853455@ietfa.amsl.com>
From: Joerg Ott <jo@netlab.tkk.fi>
Message-ID: <d9efb4b8-a16d-1423-cd84-0fe69477b164@netlab.tkk.fi>
Date: Thu, 19 Mar 2020 16:08:24 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <158340265948.14598.6334057012764853455@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-SASI-RCODE: 200
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/9Mzf7EqAXwhlmXOIAOdVzODaIHg>
Subject: Re: [rmcat] Benjamin Kaduk's No Objection on draft-ietf-rmcat-eval-criteria-12: (with COMMENT)
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2020 15:08:42 -0000

Hi Benjamin,

thanks for the comments.  Quick notes inline while I am producing -14:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 1
> 
>     media flow's throughput.  Furthermore, the proposed algorithms are
>     expected to operate within the envelope of the circuit breakers
>     defined in RFC8083 [RFC8083].
> 
> The "proposed algorithms" are the congestion-control schemes, not the
> evaluation procedures, right?

Good point.  Inserted "congestion control" for clarification.

> Section 3.1
> 
>     If the congestion control implements, retransmissions or FEC, the
> 
> nit: no comma (first one)

removed

> Section 4.4
> 
> It's too bad that we don't have more specific guidance to give on loss
> generation modeling.
We now have a reference to the Gilbert-Elliott model to provide minimal
guidance.

> Section 4.5.1
> 
>     path.  Due to this, if a packet becomes overly delayed, the packets
>     after it on that flow are also delayed.  This is especially true for
> 
> Doesn't this imply that the real PDV data poitns are not independent and
> that we should expect simple PDF modeling to produce inaccurate or
> unphysical results?

For 4.5.1, which allows reordering, the PDV data points would be
independent.  I am not sure what is meant by unphysical, but if you mean
the sudden reordering that could occur, yes, this could happen.  This is
why we have 4.5.2.  And we make explicit what the impacts of these two
are.

Both random models don't capture queuing behavior properly (cf. the 
definition of x[n]) but is a simple random distribution rather than
derived from a more complex process.  This more random behavior probably
causes more stress on algorithms than smooth increases or decreases of
jitter would.

Best,
Jörg