Re: [ippm] Cost metrics in draft-wu-alto-te-metrics

Qin Wu <bill.wu@huawei.com> Thu, 21 July 2016 15:30 UTC

Return-Path: <bill.wu@huawei.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 1013612D520; Thu, 21 Jul 2016 08:30:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.508
X-Spam-Level:
X-Spam-Status: No, score=-5.508 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, RP_MATCHES_RCVD=-1.287, SPF_PASS=-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 KYQ1Tilzxhu6; Thu, 21 Jul 2016 08:30:26 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C801312D0B4; Thu, 21 Jul 2016 08:30:23 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSZ18815; Thu, 21 Jul 2016 15:30:21 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 21 Jul 2016 16:29:51 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.179]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 21 Jul 2016 23:29:46 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "MORTON, ALFRED C (AL)" <acmorton@att.com>, "joachim.fabini@tuwien.ac.at" <joachim.fabini@tuwien.ac.at>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, "alto@ietf.org" <alto@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
Thread-Topic: [ippm] Cost metrics in draft-wu-alto-te-metrics
Thread-Index: AQHR41W2OEjYSG8Go0qGH3DkNK0f+aAicIWAgAAHogCAAIhDEA==
Date: Thu, 21 Jul 2016 15:29:46 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA853A9B33@nkgeml513-mbx.china.huawei.com>
References: <EBA5164E-B24F-456B-82C2-EC388CA9EE26@tik.ee.ethz.ch> <6da02ef8-6422-97ba-c836-2a5933483250@tuwien.ac.at> <4AF73AA205019A4C8A1DDD32C034631D45963B2664@NJFPSRVEXG0.research.att.com>
In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D45963B2664@NJFPSRVEXG0.research.att.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.219.11]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5790EA8D.0378, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.179, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 5d78ec1900462a975f214952321cf240
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/YmbEGu5AwrN8714xfVR3PtDmQJY>
Subject: Re: [ippm] Cost metrics in draft-wu-alto-te-metrics
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Jul 2016 15:30:29 -0000

Thanks Al and Joachim to share the IPPM view. Please see my clarification inline.

-Qin
-----邮件原件-----
发件人: ippm [mailto:ippm-bounces@ietf.org] 代表 MORTON, ALFRED C (AL)
发送时间: 2016年7月21日 23:14
收件人: joachim.fabini@tuwien.ac.at; Mirja Kühlewind; alto@ietf.org; ippm@ietf.org
主题: Re: [ippm] Cost metrics in draft-wu-alto-te-metrics

Hi Mirja and Joachim,

Another way to interpret what ALTO needs is to look at cost metrics the same as link costs in routing.
Routing link costs are usually static and the values might be set relative to some real metric like latency or max link line rate. These involve no measurement at all.

So when they say:
   In this document, we proposes a set of Cost Metrics, derived and
   aggregated from routing protocols with different granularity and
   scope, such as BGP-LS,OSPF-TE and ISIS-TE, or from end to end traffic
   management tool.

only the last phrase implies measurement, with the long list of examples:

   We currently define 11 new Performance Metric to
   measure network delay, jitter, packet loss, hop count, and bandwidth.

None of these are new, and they are already defined in great detail or ippm is in the process of doing so. The draft seems to assume that a measurement system exists to supply all the needed measurements with relevant context and scope.

[Qin]:Sure, that's what I underline in the ALTO session, we are not aiming at redefine the metrics. What we try to do in this draft is to derive and aggregate these metrics from various different data source ,e.g., management measurement tool.

I wonder how much all these "new" metrics actually improve alto cost accuracy.

[Qin]: not targeting to improve alto cost accuracy, but Allow applications to determine "where" to connect based on end to end network performance criteria, that's the main motivation to enrich single cost metric (routing cost) defined in ALTO protocol.
Please also refer to Alto Server Network API Use case proposed in RFC7752, section 2.2, this draft is targeting to address that use case and fill the gap.

Al



> -----Original Message-----
> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Joachim Fabini
> Sent: Thursday, July 21, 2016 10:46 AM
> To: Mirja Kühlewind; alto@ietf.org; ippm@ietf.org
> Subject: Re: [ippm] Cost metrics in draft-wu-alto-te-metrics
> 
> 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
> >
> 
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm