Re: [ippm] Cost metrics in draft-wu-alto-te-metrics
Joachim Fabini <joachim.fabini@tuwien.ac.at> Thu, 21 July 2016 14:46 UTC
Return-Path: <joachim.fabini@tuwien.ac.at>
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 6F44B12D68F; Thu, 21 Jul 2016 07:46:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level:
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 ttWcSUxY-V-q; Thu, 21 Jul 2016 07:46:55 -0700 (PDT)
Received: from mail.nt.tuwien.ac.at (mail.nt.tuwien.ac.at [128.131.67.5]) (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 A7E7012D675; Thu, 21 Jul 2016 07:46:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.nt.tuwien.ac.at (Postfix) with ESMTP id 04BD34709B9; Thu, 21 Jul 2016 16:46:54 +0200 (CEST)
X-Virus-Scanned: amavisd-new at mail.nt.tuwien.ac.at
Received: from mail.nt.tuwien.ac.at ([127.0.0.1]) by localhost (mail.nt.tuwien.ac.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8lcubv-GQEC; Thu, 21 Jul 2016 16:46:52 +0200 (CEST)
Received: from [31.133.152.68] (dhcp-9844.meeting.ietf.org [31.133.152.68]) by mail.nt.tuwien.ac.at (Postfix) with ESMTPSA id 9DDD84709A6; Thu, 21 Jul 2016 16:46:52 +0200 (CEST)
References: <EBA5164E-B24F-456B-82C2-EC388CA9EE26@tik.ee.ethz.ch>
To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, alto@ietf.org, ippm@ietf.org
From: Joachim Fabini <joachim.fabini@tuwien.ac.at>
Message-ID: <6da02ef8-6422-97ba-c836-2a5933483250@tuwien.ac.at>
Date: Thu, 21 Jul 2016 16:46:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <EBA5164E-B24F-456B-82C2-EC388CA9EE26@tik.ee.ethz.ch>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/fUqC4d5tiiUL8A4xw9BtcQnCjfk>
Subject: Re: [ippm] Cost metrics in draft-wu-alto-te-metrics
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: joachim.fabini@tuwien.ac.at
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, 21 Jul 2016 14:46:58 -0000
Hi Mirja, thanks for bringing this topic to ippm. Some technical notes on this: RFC2330 does not differentiate at which layer timestamps are acquired. If the host time is considered to be an application layer timestamp, alto could immediately adopt/use the base framework and all the metrics that have been defined so far in ippm - including OWD, RTD, IPDV (alias Jitter), Loss, Loss Patterns, BTC, etc., all defined in separate documents and in substantial detail. So yes, I share your opinion. I recommend alto to consider this procedure - unless there are specific reasons why this can't be done (in which case ippm will likely be very interested in feedback on the reasons). Some more related documents: - The update to 2330 (RFC7312) has particular focus on uncertainty factors that measurements at application level will encounter in today's networks. - Al and I have written a draft to update RFC2330 to be more specific wrt timestamp acquisition, even considering virtualization and related challenges. The draft (https://datatracker.ietf.org/doc/draft-fabini-ippm-2330-time/ ) has expired but I plan to rewrite it to fit what we have discussed in Yokohama (in particular a use-case based discussion of timestamp acquisition in measurements). - IPv6 update for 2330 is on the way. (https://tools.ietf.org/html/draft-ietf-ippm-2330-ipv6-00 ) Any feedback and summary on requirements from alto is very welcome; likewise some statements on the challenges in adopting the existing ippm metrics. I guess that this information is valuable feedback for ippm in evaluating past and guiding future work. Joachim On 2016-07-21 15:41, Mirja Kühlewind wrote: > Hi ippm folks, hi alto folks, > > cross-posting because draft-wu-alto-et-metrics defines a set of alto cost metrics such as delay or bandwidth which sound to me like IP performance metrics. At the same time IPPM is currently in the process of defining a metric registry (draft-ietf-ippm-metric-registry-07 and draft-ietf-ippm-initial-registry-01). How do these relate to each other and how can we make sure that they are inline with each other? > > Mirja > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm >
- Re: [ippm] [alto] Cost metrics in draft-wu-alto-t… Leeyoung
- Re: [ippm] [alto] Cost metrics in draft-wu-alto-t… Qin Wu
- Re: [ippm] Cost metrics in draft-wu-alto-te-metri… Qin Wu
- Re: [ippm] [alto] Cost metrics in draft-wu-alto-t… MORTON, ALFRED C (AL)
- Re: [ippm] Cost metrics in draft-wu-alto-te-metri… MORTON, ALFRED C (AL)
- Re: [ippm] Cost metrics in draft-wu-alto-te-metri… Joachim Fabini
- Re: [ippm] [alto] Cost metrics in draft-wu-alto-t… Gao Kai
- Re: [ippm] Cost metrics in draft-wu-alto-te-metri… Qin Wu
- [ippm] Cost metrics in draft-wu-alto-te-metrics Mirja Kühlewind