[ippm] Violated vs errored intervals - draft-mhmcsfh-ippm-pam-00

Alexander L Clemm <ludwig@clemm.org> Thu, 31 March 2022 22:40 UTC

Return-Path: <ludwig@clemm.org>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97973A1EBF; Thu, 31 Mar 2022 15:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 Kpl7rLWgsba6; Thu, 31 Mar 2022 15:40:33 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 E07483A1F61; Thu, 31 Mar 2022 15:40:32 -0700 (PDT)
Received: from [172.16.0.44] ([73.189.160.186]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0Lp4sc-1oChb93Hgy-00ew06; Fri, 01 Apr 2022 00:40:31 +0200
Message-ID: <f9010c1c-f004-8322-faa8-d3bda61512f1@clemm.org>
Date: Thu, 31 Mar 2022 15:40:30 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Content-Language: en-US
To: ippm@ietf.org
Cc: draft-mhmcsfh-ippm-pam@ietf.org
From: Alexander L Clemm <ludwig@clemm.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K1:VcxIlrwKhyNrFPZo8lw1K8gfbBx1h6ghUjPi1TB67ZzQ0/zxmIv gnFa25O1tqJRth8egOj755fsVb2JE9qRkbfxT4LGsa9Sj+IiB5EczL5WxD8f3XczgFVh9xJ uEPoxCtZuAmnQwhN8uPozzAGwAALdFWkZtKOsfSZeop/8WoH1vHPTNavrZxX0OeO61dDCUW x5i2x+yMTqQW4KTLbzjow==
X-UI-Out-Filterresults: notjunk:1;V03:K0:oRPnZdsIOmY=:vBqlgxzuXQXhS/7Me+alZr LVrNlpXdX/hzxPpgeEVI9IlVtD+A6MHTZlaBNIFIXa6UyAE6tM0frP1GFi4CQvedxsw72PbcC ru+l0a5Stp8Wkhsl19rtTQ7jTgTVRCPUNk8VQjZSUiUHfOwjIfmq9iiJ5uKLwANHJp/0/+jwx hRBLZ8IDewlZ/KtD9sO6A2N2vT+C/q35zTFlB0/MOrS3nvKqQvx1LLXD+3fry3elahnA0OvzP tfbMOglkqCMJ8yLXEZXBX7jk4D6Ejq46YBz6fqC/GUbh/5XLROyWnSPAWcIbIpUHN4PVSP7h6 5FYoOvFzn+s71vKrYz6yO0v4sAAYCDQmu7RWv0UhKGPkAxNu+Zz5M/5QfB4Ien+AdDlnR9z+E iueDktYKL+TK+XD1BGo/ETCJQ39y0tQz/uRpnZLIb06gj6AJJOfUorM8jA97OxhPzHboU4RCG LpgzTzpKmM9BmRPZBRHP0bEUizP+ET4I3X+Kp5NuG9U+XGBMtW5uCHQ4EwQZqLLXRj0rMukTK LtDHAASXHhnHT9xfjTyNB3KyaVGo/UWy7T3pYwNA7omhrQlfO4y/oBy0Yy/IewyB0fk5cWpmA D6mOMC53ofH3I+dJ8bgmTQViPVfzmxEd2KgICGLI9I0x03mG8R7fWxe29A7F5aZ8bVCbYP8ml NOqNKZQjMPaZev1KFO9C6bGr9cbGg8xmLW+1Grl/DF9tITBvFReBP63r3+WOnCmZD428=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/7_gGQwOY2X7Dn5NvFbUYzp28JGw>
Subject: [ippm] Violated vs errored intervals - draft-mhmcsfh-ippm-pam-00
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Mar 2022 22:40:36 -0000

Hi,

I wanted to follow up on the draft concerning Precision Availability 
Metrics for SLO-governed end-to-end services 
(draft-mhmcsfh-ippm-pam-00), which Greg Mirsky presented at IETF 113.  
One of the motivations for the draft is to provide an agreed-upon set of 
metrics which can provide the basis for accounting for high-precision 
services that feature stringent service level (aka performance) 
guarantees.  We believe that monitoring such services, and indeed the 
ability to provide such services, will hinge on the ability to assess 
whether a service complies with its guarantees.  This will be an 
important enabler for mission-critical applications that depend on such 
guarantees and accordingly I hope that it will be adopted by the WG.

I wanted to pick up on one of the discussion items that are pointed out 
in the draft, for which we (i.e., the authors) would like to request 
feedback from the WG, concerning the terminology to use. The 
foundational metrics that are proposed are concerned with tracking the 
number of time intervals during which a service (generally, a flow) 
complies with its objectives, versus the ones when violations occur.  
The draft currently refers to "errored" intervals (in the sense that 
there is a performance error). However, it seems that the term 
"violated" intervals may in fact be more suitable and semantically 
accurate to use, in the sense that it is really SLO violations that 
occur (and what constitutes a violation depends on the particular 
objectives that govern the flow, as opposed to an "error" which 
constitutes, well, an error).  This would imply replacing the term 
"Errored Interval" (EI) with "Violated Interval" (VI) (including its 
derivatives).

Comments?

--- Alex