Re: [ippm] New Version Notification for draft-mhmcsfh-ippm-pam-03.txt

Peter Thompson <Peter.Thompson@pnsol.com> Thu, 24 November 2022 15:01 UTC

Return-Path: <peter.thompson@pnsol.com>
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 DB993C14F6EC for <ippm@ietfa.amsl.com>; Thu, 24 Nov 2022 07:01:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfjmelBZiqeJ for <ippm@ietfa.amsl.com>; Thu, 24 Nov 2022 07:01:51 -0800 (PST)
Received: from st-node04.ct.uk (st-node04.ct.uk [109.69.232.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40679C14F721 for <ippm@ietf.org>; Thu, 24 Nov 2022 07:01:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by st-node04.ct.uk (Postfix) with ESMTP id 417DE30382CB for <ippm@ietf.org>; Thu, 24 Nov 2022 15:01:48 +0000 (GMT)
X-Virus-Scanned: by SpamTitan at ct.uk
Received: from st-node04.ct.uk (localhost [127.0.0.1]) by st-node04.ct.uk (Postfix) with ESMTP id 1217130382C9 for <ippm@ietf.org>; Thu, 24 Nov 2022 15:01:46 +0000 (GMT)
Authentication-Results: st-node04.ct.uk; none
Received: from relay.smtp.pnsol.com (ec2-54-246-165-192.eu-west-1.compute.amazonaws.com [54.246.165.192]) (using TLSv1.2 with cipher AES256-SHA256 (256/256 bits)) (No client certificate requested) (Authenticated sender: predictable) by st-node04.ct.uk (Postfix) with ESMTPSA id 0819730382D1 for <ippm@ietf.org>; Thu, 24 Nov 2022 15:01:45 +0000 (GMT)
Received: from mail.la.pnsol.com ([172.20.5.206]) by relay.smtp.pnsol.com with esmtp (Exim 4.82) (envelope-from <peter.thompson@pnsol.com>) id 1oyE2M-0003NZ-Nr for ippm@ietf.org; Thu, 24 Nov 2022 15:21:14 +0000
Received: from git.pnsol.com ([172.20.5.238] helo=roam.smtp.pnsol.com) by mail.la.pnsol.com with esmtp (Exim 4.76) (envelope-from <peter.thompson@pnsol.com>) id 1oyDbi-0000bg-FI; Thu, 24 Nov 2022 14:53:42 +0000
Received: from gw.eu-west-1b.aws.pnsol.com ([172.30.11.4] helo=smtpclient.apple) by roam.smtp.pnsol.com with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from <peter.thompson@pnsol.com>) id 1oyDbh-000WX5-O8; Thu, 24 Nov 2022 14:53:42 +0000
Content-Type: multipart/signed; boundary="Apple-Mail=_A8DBFC93-B2B1-4CFC-820F-F9E2C4022731"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
From: Peter Thompson <Peter.Thompson@pnsol.com>
In-Reply-To: <mailman.8030.1667824945.15745.ippm@ietf.org>
Date: Thu, 24 Nov 2022 15:01:33 +0000
Message-Id: <6C621BD9-E20F-4D6A-AF6F-44AC38A84A2A@pnsol.com>
References: <mailman.8030.1667824945.15745.ippm@ietf.org>
To: ippm@ietf.org
X-Mailer: Apple Mail (2.3731.200.110.1.12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/UBHmKqr0iFTtnu-T1QWYbBeYT0o>
Subject: Re: [ippm] New Version Notification for draft-mhmcsfh-ippm-pam-03.txt
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
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, 24 Nov 2022 15:01:56 -0000

Dear Greg at el,

I think this a very interesting direction of work and I support the idea of creating metrics for service availability. I have some questions:

1) Definition of a ’service’

There is an implicit identification of a ’service’ with a particular flow of packets. However, if we think of, e.g., a bearer service, this is a *capability* to deliver packets regardless of whether any packets are currently flowing. It seems odd to record a service as ‘available’ only when it is being actively used! Also, a higher-level service may have units of information exchange that are not individual packets, and the notion of whether it is ‘available’ may go beyond whether packets are being exchanged with sufficient reliability.

2) Flow being measured

When we speak of a ‘violated packet’ are we thinking of measuring *all* packets in a flow or just a subset (e.g. a co-incident stream of test packets)? Using a test packet stream has advantages:
- Packets can include transmission times and sequence numbers, making measurement of delay and loss much easier
- measurements continue even when there is no active service flow

3) Service availability transition

A service is moved to the ‘unavailable’ state if ten consecutive SVIs are detected - shouldn’t this number be a configurable parameter? Could it be N of M in a rolling window? (If only every tenth interval was unviolated this ’10 consecutive’ test would fail but the service wouldn’t be very good!)

Peter Thompson, Chief Technical Officer Predictable Network Solutions Ltd., +44 (0)333.340.7713 • Twitter: @PNSolLtd

PS this is my first post to this list, so I apologise in advance for any infelicities of format or etiquette!