From alejandroacostaalamo@gmail.com Fri Nov 2 16:14:23 2012 Return-Path: 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 85F6811E80F5 for ; Fri, 2 Nov 2012 16:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nu-YtfKd474 for ; Fri, 2 Nov 2012 16:14:22 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8E111E80E9 for ; Fri, 2 Nov 2012 16:14:22 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4786527vbb.31 for ; Fri, 02 Nov 2012 16:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8MWyroqng4bE3PhKBeXpRboPmtHq24ekf61ielYFa4Y=; b=Ei2e/Z3FHQtYUU6hFJo2793Whp156Yha7EtIv0zVQ9i3ccMS1ZgwAgxhmt+nFukHfj dw8erjSnCeQEEm1PTvYiXtRl/D5A/CYsNEspnKjKFmUgMJbydp0D4ctXzcq0oxp43d72 qR96jH+4x68a0HVhzoU432qZFChDsXKzbVqGEOFCC1RCCSqr/p88otxrcMRLC/7pYET7 WKhIq150ia68eFFkCERl0vuJZZQg8wtFOiZ2AGkYV7hgIEa/pMomdkEh2mINCpSOmZih TVGyq1hY6rooXjN4jyJK4zgBo/YdWF36TViScyciOCPiTU/qGQEv5aC/2wA7nAr6i/68 AyTQ== MIME-Version: 1.0 Received: by 10.52.77.101 with SMTP id r5mr2905633vdw.25.1351898061947; Fri, 02 Nov 2012 16:14:21 -0700 (PDT) Received: by 10.58.56.100 with HTTP; Fri, 2 Nov 2012 16:14:21 -0700 (PDT) In-Reply-To: <5087973A.3030400@uijterwaal.nl> References: <5087973A.3030400@uijterwaal.nl> Date: Fri, 2 Nov 2012 21:14:21 -0200 Message-ID: From: Alejandro Acosta To: Henk Uijterwaal Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: IETF IPPM WG Subject: Re: [ippm] Draft agenda X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 23:14:23 -0000 Hi All, Sorry if there is something I'm missing. Regarding the agenda at: http://www.ietf.org/proceedings/85/agenda/agenda-85-ippm There is a draft from Yang Cui called: draft-bi-ippm-ipsec-01.txt. I've been only able to find the first version (00). From this mailing list I know that this is a Emily Bi draft that will be presented by Yang Cui. Thanks, Alejandro, On 10/24/12, Henk Uijterwaal wrote: > IPPM group, > > Below is the draft agenda for Atlanta. Comments welcome. Please note th= at > we > have a very full agenda so stick to the assigned times. I'm looking for = a > note-taker. > > Henk > > - - - - - - > > > Draft Agenda for IPPM @ IETF 85. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > 0. Administrativia (5') > > 1. Advanced Stream and Sampling Framework. (10') > Al Morton, Joachim Fabini > draft-morton-ippm-2330-update-00.txt > > 2. Passive and Hybrid Measurements using IPPM Metrics (15') > Brian Trammell > draft-trammell-ippm-hybrid-ps-00.txt > > 3. Model Based Internet Performance Metrics (10') > Matt Mathis > draft-mathis-ippm-model-based-metrics-00.txt > > 4. Curating Internet Measurement Data (10') > Matt Mathis > draft-mathis-ippm-data-curation-00.txt > > 5. Network Performance Measurements for IPsec (10') > Yang Cui > draft-bi-ippm-ipsec-01.txt > > 6. Flow-based Performance Measurement (10') > Yu Fang > draft-sun-ippm-flowbased-pm-00.txt > > 7. Rate Measurement Problem statement draft (5') > Al Morton > draft-=85 > > 8. RFC 2679-bis (10') > Al Morton > > 9. AOB (5') > > Speakers: please submit slides before the meeting. Note that the timeslo= t > includes time for discussion afterwards, that is, if you have 10 minutes, > prepare to speak for about 7 and leave 3 for questions and answers. > -- > -------------------------------------------------------------------------= ----- > Henk Uijterwaal Email: henk(at)uijterwaal.nl > http://www.uijterwaal.nl > Phone: +31.6.55861746 > -------------------------------------------------------------------------= ----- > > Read my blog at http://www.uijterwaal.nl/henks_hands.html > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > From henk@uijterwaal.nl Sat Nov 3 01:50:15 2012 Return-Path: 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 9665921F9CAE for ; Sat, 3 Nov 2012 01:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqCXvXCFi73N for ; Sat, 3 Nov 2012 01:50:14 -0700 (PDT) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6DA21F9CAD for ; Sat, 3 Nov 2012 01:50:14 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id qA38nBMn048112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Nov 2012 09:49:12 +0100 (CET) (envelope-from henk@uijterwaal.nl) Message-ID: <5094DA87.9090805@uijterwaal.nl> Date: Sat, 03 Nov 2012 09:49:11 +0100 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Alejandro Acosta References: <5087973A.3030400@uijterwaal.nl> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: IETF IPPM WG Subject: Re: [ippm] Draft agenda X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 08:50:15 -0000 On 03/11/2012 00:14, Alejandro Acosta wrote: > Hi All, > Sorry if there is something I'm missing. > Regarding the agenda at: > http://www.ietf.org/proceedings/85/agenda/agenda-85-ippm > > There is a draft from Yang Cui called: draft-bi-ippm-ipsec-01.txt. > I've been only able to find the first version (00). From this mailing > list I know that this is a Emily Bi draft that will be presented by > Yang Cui. Yang said that the -00 was updated. Yang, can you please post a pointer to the 01 version? Henk > > Thanks, > > Alejandro, > > > On 10/24/12, Henk Uijterwaal wrote: >> IPPM group, >> >> Below is the draft agenda for Atlanta. Comments welcome. Please note that >> we >> have a very full agenda so stick to the assigned times. I'm looking for a >> note-taker. >> >> Henk >> >> - - - - - - >> >> >> Draft Agenda for IPPM @ IETF 85. >> ================================ >> >> 0. Administrativia (5') >> >> 1. Advanced Stream and Sampling Framework. (10') >> Al Morton, Joachim Fabini >> draft-morton-ippm-2330-update-00.txt >> >> 2. Passive and Hybrid Measurements using IPPM Metrics (15') >> Brian Trammell >> draft-trammell-ippm-hybrid-ps-00.txt >> >> 3. Model Based Internet Performance Metrics (10') >> Matt Mathis >> draft-mathis-ippm-model-based-metrics-00.txt >> >> 4. Curating Internet Measurement Data (10') >> Matt Mathis >> draft-mathis-ippm-data-curation-00.txt >> >> 5. Network Performance Measurements for IPsec (10') >> Yang Cui >> draft-bi-ippm-ipsec-01.txt >> >> 6. Flow-based Performance Measurement (10') >> Yu Fang >> draft-sun-ippm-flowbased-pm-00.txt >> >> 7. Rate Measurement Problem statement draft (5') >> Al Morton >> draft-… >> >> 8. RFC 2679-bis (10') >> Al Morton >> >> 9. AOB (5') >> >> Speakers: please submit slides before the meeting. Note that the timeslot >> includes time for discussion afterwards, that is, if you have 10 minutes, >> prepare to speak for about 7 and leave 3 for questions and answers. >> -- >> ------------------------------------------------------------------------------ >> Henk Uijterwaal Email: henk(at)uijterwaal.nl >> http://www.uijterwaal.nl >> Phone: +31.6.55861746 >> ------------------------------------------------------------------------------ >> >> Read my blog at http://www.uijterwaal.nl/henks_hands.html >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ Read my blog at http://www.uijterwaal.nl/henks_hands.html From acmacm@usa.net Sun Nov 4 07:56:27 2012 Return-Path: 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 9C32021F8667 for ; Sun, 4 Nov 2012 07:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.087 X-Spam-Level: X-Spam-Status: No, score=0.087 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oifHnKIvv+8K for ; Sun, 4 Nov 2012 07:56:26 -0800 (PST) Received: from cmsout01.mbox.net (cmsout01.mbox.net [165.212.64.31]) by ietfa.amsl.com (Postfix) with ESMTP id A790C21F8615 for ; Sun, 4 Nov 2012 07:56:06 -0800 (PST) Received: from co01.mbox.net (localhost [127.0.0.1]) by cmsout01.mbox.net (Postfix) with ESMTP id 9767F6681D4; Sun, 4 Nov 2012 15:56:05 +0000 (UTC) X-USANET-Received: from co01.mbox.net [127.0.0.1] by co01.mbox.net via mtad (C8.MAIN.3.82G) with ESMTP id 021qkDP5B0512M01; Sun, 04 Nov 2012 15:56:01 -0000 X-USANET-Routed: 3 gwsout-vs Q:bmvirus Received: from imap04.cms.usa.net [165.212.11.4] by co01.mbox.net via smtad (C8.MAIN.3.87D) with ESMTP id XID039qkDP5B1905X01; Sun, 04 Nov 2012 15:56:01 -0000 X-USANET-Source: 165.212.11.4 OUT acmacm@usa.net imap04.cms.usa.net X-USANET-MsgId: XID039qkDP5B1905X01 Received: from web04.cms.usa.net [165.212.8.204] by imap04.cms.usa.net (ESMTP/acmacm@usa.net) via mtad (C8.MAIN.3.82G) with ESMTP id 970qkDP5B0992M24; Sun, 04 Nov 2012 15:56:01 -0000 X-USANET-Auth: 165.212.8.204 AUTO acmacm@usa.net web04.cms.usa.net Received: from 65.14.229.26 [65.14.229.26] by web04.cms.usa.net (USANET web-mailer C8.MAIN.3.86Z); Sun, 04 Nov 2012 15:56:01 -0000 Date: Sun, 04 Nov 2012 10:56:01 -0500 From: "Al Morton" To: , X-Mailer: USANET web-mailer (C8.MAIN.3.86Z) Mime-Version: 1.0 Message-ID: <577qkDP4B0240S04.1352044561@web04.cms.usa.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Z-USANET-MsgId: XID970qkDP5B0992X24 X-Mailman-Approved-At: Sun, 04 Nov 2012 08:12:41 -0800 Cc: acmacm@usa.net, Al Morton Subject: [ippm] comments on draft=mathis-ippm-model-based-metrics-00 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 15:56:27 -0000 Hi Matt, I finally made time to read one of your new memos on the way down. I found this new approach for model-based metrics really interesting and encouraging, and it caused me to think of several ideas on related work, so thanks for putting the memo together. I support adoption of thi= s memo in the WG, and we can talk about ways I might be able to help. Comments and questions: Several times you mention progressive loss, I think you mean some form of early discard before drastic tail drop, but not sure. Is this a mandatory property of the measured path? In section 3.3: target_pipe_size =3D target_rate * target_RTT / target_MTU is a unit-less quantity. octets/sec * sec/octets I think I know what you're getting at here, but seems odd. Last, I havent seen any other readers look at this yet, possibly a consequence of the 00 deadline and revised draft deadline overloads, but I encourage others to take a look before IPPM meets. regards, Al (hoping my usa.net account is subscribed...) From matt@internet2.edu Sun Nov 4 08:30:16 2012 Return-Path: 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 E2C2C21F85AA for ; Sun, 4 Nov 2012 08:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5fUw3Q+HtGN for ; Sun, 4 Nov 2012 08:30:16 -0800 (PST) Received: from int-proxy01.merit.edu (int-proxy01.merit.edu [207.75.116.230]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEA121F85A3 for ; Sun, 4 Nov 2012 08:30:16 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-proxy01.merit.edu (Postfix) with ESMTP id 9221E10000A; Sun, 4 Nov 2012 11:30:15 -0500 (EST) X-Virus-Scanned: amavisd-new at int-proxy01.merit.edu Received: from int-proxy01.merit.edu ([127.0.0.1]) by localhost (int-proxy01.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-rL9kipTig8; Sun, 4 Nov 2012 11:30:15 -0500 (EST) Received: from matt.local (ool-18be035a.dyn.optonline.net [24.190.3.90]) by int-proxy01.merit.edu (Postfix) with ESMTPSA id 17523100002; Sun, 4 Nov 2012 11:30:15 -0500 (EST) Message-ID: <50969816.7070805@internet2.edu> Date: Sun, 04 Nov 2012 11:30:14 -0500 From: Matthew J Zekauskas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: IETF IPPM WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPPM Chairs Subject: [ippm] slides for IETF 85, please X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 16:30:17 -0000 If you are scheduled to present, please send the slides to the chairs for posting well before the meeting (because unfortunately we'll both be remote). Thanks, Matt and Henk From jason.weil@twcable.com Sun Nov 4 13:19:23 2012 Return-Path: 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 8257521F88D2; Sun, 4 Nov 2012 13:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.203 X-Spam-Level: X-Spam-Status: No, score=0.203 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_20=-0.74, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+IqIhekSCiv; Sun, 4 Nov 2012 13:19:23 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id B19B421F8914; Sun, 4 Nov 2012 13:19:22 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,711,1344225600"; d="scan'208,217";a="464737276" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 04 Nov 2012 16:18:43 -0500 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.45]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Sun, 4 Nov 2012 16:19:19 -0500 From: "Weil, Jason" To: "lmap@ietf.org" Date: Sun, 4 Nov 2012 16:19:19 -0500 Thread-Topic: LMAP BarBOF Meeting Information - Wednesday, 11.7.12 20:00-21:30 Thread-Index: Ac260g1OOycYzQyqRQqseUwyI/2ZGQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CCBC460C9044jasonweiltwcablecom_" MIME-Version: 1.0 Cc: "ippm@ietf.org" Subject: [ippm] LMAP BarBOF Meeting Information - Wednesday, 11.7.12 20:00-21:30 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 21:19:23 -0000 --_000_CCBC460C9044jasonweiltwcablecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable WHAT: Large-Scale Measurement of Broadband Performance (LMAP) DATE: Wednesday, 11/07/2012 TIME: 20:00 =96 21:30 LOCATION: SALON B A much larger room has been provided capable of holding up to 170 people. F= eel free to bring anyone interested in providing comments on the discussion= . A projector will be available for anyone interested in presenting slides.= Authors of the draft-shuzrinne-lmap-requirements-00 document will help lea= d the discussion and information on work progressing in the Broadband Forum= in this area will be discussed as well. Thank You, Jason ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_CCBC460C9044jasonweiltwcablecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

WHAT: = Large-Scale Measurement of Broadband Performance (LMAP)
DATE: = Wednesday, 11/07/2012
TIME: = 20:00 =96 21:30
LOCATION: SALON B

A much larger room has been provided capable of holding up to 170 peop= le. Feel free to bring anyone interested in providing comments on the discu= ssion. A projector will be available for anyone interested in presenting sl= ides. Authors of the draft-shuzrinne-lmap-requirements-00 document will help lead the discussion and information on work progressing= in the Broadband Forum in this area will be discussed as well.

Thank You,

Jason

This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_CCBC460C9044jasonweiltwcablecom_-- From mattmathis@google.com Mon Nov 5 07:00:34 2012 Return-Path: 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 C309A21F86DA for ; Mon, 5 Nov 2012 07:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.047 X-Spam-Level: X-Spam-Status: No, score=-102.047 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZF008hZZG6L for ; Mon, 5 Nov 2012 07:00:34 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D2B9F21F8493 for ; Mon, 5 Nov 2012 07:00:33 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so2831066wgb.13 for ; Mon, 05 Nov 2012 07:00:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=meI7GiCe1lvmY+RHzAAtvb+oh5VOo34ouVi/IOLlfaw=; b=LGQDDTHx3GHiw77VOWdvVRnVQ9R5GKGi10JV2B/6y2LC5/CNNkefut1z2sWJbVnYNU qE8W3h3ITUvJGSBL8TF+ycWdJ5qkG3pXBntbyu3NCrEWlPUrGzrMakQ3AKFCeZ/7n9q2 XuMe+ThYAqvsWUC6UwaWrRkfu4yTGQd6/bLOCM2hfsFz7TGrTk8EGmBSmWh2JuLNQ7Bd zneUkG1/31d3tOBMOP7GabrNUDq5MfbX5TP7pYSzmVyS5aLHSFRjvC7f2KU5VxEYUbuS toYTGkUYZonZLXk4dPrlUiIsoqmU4y/Cov8RMZEx1qU1+lrb0Uz8Z1NGhx2v83ryq2il umWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=meI7GiCe1lvmY+RHzAAtvb+oh5VOo34ouVi/IOLlfaw=; b=Xm4KvJsiljfkqU7KbUJvroh+FPknwScGBqGrKGk03z+8cuvCGUmOVdGLiiTd3W9cd6 K0LJ+tQm4MOstNcfjaitTjhfrJkSjZrgajKohuSuJZD++VvhV47BXXHKEpvep2PRKj99 aIWllRLJbc+s7LQ46FFnZW27LW/3U8t0cG1cBBN6M+XtN0ImGlh46ZKQayGbYjAp5dom TAnhvHc8gCy6jPX+E5uSL8ORILDMc+8WDFm9sz/CWvHHO1fGMgTtqgtTqm34ZdFlOadk rhXCpqUEgffbb5qINPRJWU4kQguaZ0vuhMaXHMLE0/TBg5P1OpZXuyQSPAJC/CViHZbl guXw== MIME-Version: 1.0 Received: by 10.216.213.28 with SMTP id z28mr3700110weo.47.1352127632931; Mon, 05 Nov 2012 07:00:32 -0800 (PST) Received: by 10.194.56.133 with HTTP; Mon, 5 Nov 2012 07:00:32 -0800 (PST) In-Reply-To: <577qkDP4B0240S04.1352044561@web04.cms.usa.net> References: <577qkDP4B0240S04.1352044561@web04.cms.usa.net> Date: Mon, 5 Nov 2012 07:00:32 -0800 Message-ID: From: Matt Mathis To: Al Morton Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlL8TjoStH4E3hW32UeLnaC77Jv18WQZF8jezjco9hKyvXyurTBbwLEkfNiACAQtC9EKqCI8WjbEy26qNJ/FUkb/R3wqKk2yuTHn/p8UaukZIV4EmkcbNVNAu4vPV4LYMknslrF1kuxtUrCY+nfW+9sm+KhE9mr9k642YoKAnJFzRce2eitxaQWl9pkaH0+ibCzDHpO Cc: Al Morton , ippm@ietf.org Subject: Re: [ippm] comments on draft=mathis-ippm-model-based-metrics-00 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:00:34 -0000 Inline On Sun, Nov 4, 2012 at 7:56 AM, Al Morton wrote: > Hi Matt, > > I finally made time to read one of your new memos on the way down. > > I found this new approach for model-based metrics really interesting > and encouraging, and it caused me to think of several ideas on related > work, so thanks for putting the memo together. I support adoption of this > memo in the WG, and we can talk about ways I might be able to help. > > Comments and questions: > > Several times you mention progressive loss, I think you mean > some form of early discard before drastic tail drop, but not sure. > Is this a mandatory property of the measured path? It should be (will be). The dots haven't been connected yet. The problem was described in RFC 2309, the most egregious symptoms described in Jim Getty's talks an buffer bloat, and a much better solution published here http://queue.acm.org/detail.cfm?id=2209336. Modern applications function rather poorly on droptail. Part of the reason that the "derating" language in in the document is to provide a phase in strategy when approximately 0% of the gear will be fully compliant on day 1. > In section 3.3: > > target_pipe_size = target_rate * target_RTT / target_MTU > > is a unit-less quantity. octets/sec * sec/octets > > I think I know what you're getting at here, but seems odd. If you make MTU "bytes per packet" then target_pipe_size has units packets. > Last, I havent seen any other readers look at this yet, possibly a > consequence of the 00 deadline and revised draft deadline overloads, > but I encourage others to take a look before IPPM meets. Thanks! I'll see you in IPPM if not sooner. --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. From matt@internet2.edu Tue Nov 6 10:20:48 2012 Return-Path: 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 7805A21F8A6B for ; Tue, 6 Nov 2012 10:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4nnwhwOpWM9 for ; Tue, 6 Nov 2012 10:20:42 -0800 (PST) Received: from int-proxy01.merit.edu (int-proxy01.merit.edu [207.75.116.230]) by ietfa.amsl.com (Postfix) with ESMTP id 851DD21F8A6E for ; Tue, 6 Nov 2012 10:20:42 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-proxy01.merit.edu (Postfix) with ESMTP id 326D8100013 for ; Tue, 6 Nov 2012 13:20:42 -0500 (EST) X-Virus-Scanned: amavisd-new at int-proxy01.merit.edu Received: from int-proxy01.merit.edu ([127.0.0.1]) by localhost (int-proxy01.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuLRpgUitei7 for ; Tue, 6 Nov 2012 13:20:41 -0500 (EST) Received: from matt.home (pool-173-68-195-35.nycmny.fios.verizon.net [173.68.195.35]) by int-proxy01.merit.edu (Postfix) with ESMTPSA id 9B8D810000D for ; Tue, 6 Nov 2012 13:20:41 -0500 (EST) Message-ID: <509954F9.40800@internet2.edu> Date: Tue, 06 Nov 2012 13:20:41 -0500 From: Matthew J Zekauskas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: IETF IPPM WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ippm] Remote participation for IPPM at IETF 85 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 18:20:48 -0000 IPPM session at IETF-85 November 6, 2012 1700-1830 Eastern Standard Time Agenda and Slides that have been posted appear here: Audio CH 4 Jabber details can be found here: From trammell@tik.ee.ethz.ch Tue Nov 20 08:59:28 2012 Return-Path: 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 3589721F878C; Tue, 20 Nov 2012 08:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.716 X-Spam-Level: X-Spam-Status: No, score=-6.716 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zTIN0IRuHeO; Tue, 20 Nov 2012 08:59:27 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBBA21F877B; Tue, 20 Nov 2012 08:59:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E96FAD9309; Tue, 20 Nov 2012 17:59:25 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7FcRR0nuFUNV; Tue, 20 Nov 2012 17:59:25 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id B6AAED9307; Tue, 20 Nov 2012 17:59:25 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <52C5FD9F-E083-4075-AE24-763306DBBFA7@icsi.berkeley.edu> Date: Tue, 20 Nov 2012 17:59:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <887F51A4-05F2-44F1-8F29-5F49D35DF447@tik.ee.ethz.ch> References: <2D09D61DDFA73D4C884805CC7865E6112F5DD2D9@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6112F5DD81F@GAALPA1MSGUSR9L.ITServices.sbc.com> <52C5FD9F-E083-4075-AE24-763306DBBFA7@icsi.berkeley.edu> To: Nicholas Weaver X-Mailer: Apple Mail (2.1283) Cc: ippm@ietf.org, lmap@ietf.org Subject: Re: [ippm] [lmap] Focus on Tests, Not Architectures... X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 16:59:28 -0000 Hi, Nick, (Copying this over to IPPM as well, as the focus-on-metrics discussion = will be interesting there too). On 20 Nov 2012, at 17:01 , Nicholas Weaver wrote: > I've said it once, I'll say it one final time: >=20 > This focus on architecture is deeply misguided. As someone who's = built one such architecture (Netalyzr), working on two others (Fathom, a = browser extension, and techniques using GuruPlugs/Raspberry Pis), the = architecture is the easy part. >=20 > In all this work, having some "standard" way to communicate between my = measurement clients and servers is useless. I just use HTTP, HTTPS, or = SSH depending on whether quick & easy or server side or mutual = authentication is required, with whatever load-balancing is needed = handled by random assignment of remote test node. =20 >=20 > The internal data store is whatever is appropriate for the project = (eg. for Netalyzr its python pickled objects for storage on our web = server, data in a Postgress database for analysis). =20 >=20 > Updates are handled appropriately (Netalyzr is updateless, its an = applet so its always up-to-date. Our android version will just use the = app store update mechanism. Fathom we use Firefox's update mechanism. = The plugs are a hack using SSH, but its a fair amount of custom goop, = and they update nightly). =20 >=20 > And all three end up having rather different architectural = requirements. Architectures, I would submit (and as I've said here before), are useful = to hang terminology off of: you need boxes and lines so everyone = understands (roughly) the same thing when you say "client" and "server" = and "controller" with reference to a set of measurements you define. But yes, specifying a way to specify a measurement is largely arbitrary. = I'd even advocate separating the representation from the transport, = especially as the general problem of measurement interoperability has = data sources operating and wildly different scales, but as you say = deciding this is the easy part. > The hard part is developing the test metrics and measurements, both in = the abstract and within the API constraints of the target platform. = E.g. why I like the GuruPlugs and Raspberry Pi is that I can run Java, = so therefore I can just "Run Netalyzr" for all Netalyzr tests. But the = same isn't the case for the Ripe Atlas or Bismark platform. >=20 > And Marc's list is actually just a start: you also have generic proxy = presence & location detection, application specific proxy detection and = analysis, packet injection detection, differential application behavior = detection, application agnostic traffic shaping detection, DNSSEC = support, DNS manipulation detection, path MTU, IPv6 for all of the = previous, and a ton of others. Netalyzr is currently composed of >100 = distinct tests. And this amount just continues to grow. >=20 >=20 > If the IETF actually wants to have an impact in this area, don't = bother focusing on protocols for communication, focus on tests with = given attributes. Because people like me who actually build these = things are going to ignore an architectural focus because that has no = value. But having ACCEPTED STANDARD tests would be very valuable. =20 + 1e. Stated another way, the protocol gives you the = grammar. What you need to make this at all interoperable is the = vocabulary.=20 IPPM has defined a several of these at a low level, with a focus on = active measurement methods that produce comparable results. There = appears to be interest in IPPM both in adding passive methods for the = existing metrics (see draft-trammell-ippm-hybrid-ps) as well as adding = definitions of more complex metrics based in part on the simple ones = (see draft-mathis-ippm-model-based-metrics). > E.g. a good, standard latency-under-load test that can be written in = Flash (so TCP/UDP connections only to cooperating servers) would be = great. Our current one in Netalyzr is only OK: we believe that one = could do a lot better. >=20 > If you could then figure out WHERE the bottleneck is (using a server = that can also do simultaneous traceroutes), this would be even more = valuable. (This seems to make the assumption that traceroute-measurable latency is = strongly correlated with application latency at a given hop, but I get = your point...) The efforts of IPPM to date have been focused on simply describable, = easily repeatable metrics... there's not a lot of specification of = arbitrarily complex or unknown preconditions (as would be useful in the = latency-under-load example you give), because these tend to be counter = to the goals of maximizing repeatability and minimizing uncertainty. = There's also a focus on active measurement for the same reason. On the = other hand, a lot of work in distributed measurement systems is focused = on measuring the network as it is, with implicit or explicit passive = components (again, returning to "latency under load", the load traffic = will be made up of generated as well as existing background load).=20 So, what might be useful would be to open another line of work within = IPPM on interoperable descriptions of some of these existing tests as = empirically specified metrics, perhaps with relaxed compliance with the = IPPM framework as appropriate. This could be used to provide a more = complex vocabulary to LMAP, but could also be useful independently -- if = LMAP is eventually defined to apply only to a restricted set of use = cases (i.e. specifically mandated tests for regulatory compliance, but = not research or troubleshooting), comparable metrics with incompatible = architecture and protocols could still lead to wider interoperability in = the measurement space, the need for protocol shims (which are after all = easy to write if the number inside has the same meaning) aside. Best regards, Brian= From ken.ko@adtran.com Tue Nov 20 09:53:57 2012 Return-Path: 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 AB65B21F86D2; Tue, 20 Nov 2012 09:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGTkU847y4u2; Tue, 20 Nov 2012 09:53:55 -0800 (PST) Received: from p02c12o147.mxlogic.net (p02c12o147.mxlogic.net [208.65.145.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8FF21F8685; Tue, 20 Nov 2012 09:53:50 -0800 (PST) Received: from unknown [76.164.174.81] (EHLO p02c12o147.mxlogic.net) by p02c12o147.mxlogic.net(mxl_mta-6.16.0-0) with ESMTP id fa3cba05.7b256940.130268.00-2464.322329.p02c12o147.mxlogic.net (envelope-from ); Tue, 20 Nov 2012 10:53:51 -0700 (MST) X-MXL-Hash: 50abc3af450e353e-3b629b84a2528c555fae729e0516e192692cd925 Received: from unknown [76.164.174.81] by p02c12o147.mxlogic.net(mxl_mta-6.16.0-0) with SMTP id ba3cba05.0.129991.00-2297.322245.p02c12o147.mxlogic.net (envelope-from ); Tue, 20 Nov 2012 10:53:48 -0700 (MST) X-MXL-Hash: 50abc3ac178a042e-c92e3fed749881c402abc50985266b19d8200731 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%14]) with mapi id 14.01.0339.001; Tue, 20 Nov 2012 11:53:19 -0600 From: KEN KO To: "STARK, BARBARA H" , Nicholas Weaver Thread-Topic: Focus on Tests, Not Architectures... Thread-Index: AQHNx0GXMS9obShxv0GLr9dkQIvHk5fy/ykA Date: Tue, 20 Nov 2012 17:53:19 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E6112F5DD2D9@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6112F5DD81F@GAALPA1MSGUSR9L.ITServices.sbc.com> <52C5FD9F-E083-4075-AE24-763306DBBFA7@icsi.berkeley.edu> <2D09D61DDFA73D4C884805CC7865E6112F5DD96D@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6112F5DD96D@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=YoS4sfkX c=1 sm=1 a=0XgpNN2/4a34ymu16SVwsQ==:17 a] X-AnalysisOut: [=CB9cjBeVwSIA:10 a=XV3CA8akORcA:10 a=qZHQZMT3apYA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpio] X-AnalysisOut: [GAAAA:8 a=h5VdO6nhOuIA:10 a=O0DK09EvJxzNftSsNEoA:9 a=CjuIK] X-AnalysisOut: [1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] X-Mailman-Approved-At: Wed, 21 Nov 2012 10:36:51 -0800 Cc: "ippm@ietf.org" , "lmap@ietf.org" Subject: Re: [ippm] Focus on Tests, Not Architectures... X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 17:53:57 -0000 >Since client and controller are deployed by the same entity, it should be = up to that entity to figure out their control architecture, and that entity= should have full say in how to do their own control architecture. I don't think it's a universally held assumption that the client and contro= ller are deployed by the same entity. For instance, a regulator use case sp= anning multiple operators could use a controller function (and, a data coll= ection function) that communicates with clients deployed by each of those o= perators. So I don't think we should ignore architecture. That said, I do believe that focusing on tests is an excellent idea and tha= t that work could progress in ippm while other lmap issues are still being = discussed. From wwwrun@rfc-editor.org Fri Nov 23 09:50:36 2012 Return-Path: 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 7636F21F8582; Fri, 23 Nov 2012 09:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdYWpwrRVySZ; Fri, 23 Nov 2012 09:50:31 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 59AEF21F89AF; Fri, 23 Nov 2012 09:50:30 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 54340B1E006; Fri, 23 Nov 2012 09:42:58 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121123174258.54340B1E006@rfc-editor.org> Date: Fri, 23 Nov 2012 09:42:58 -0800 (PST) Cc: ippm@ietf.org, rfc-editor@rfc-editor.org Subject: [ippm] RFC 6802 on Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 17:50:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6802 Title: Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets Author: S. Baillargeon, C. Flinta, A. Johnsson Status: Informational Stream: IETF Date: November 2012 Mailbox: steve.baillargeon@ericsson.com, christofer.flinta@ericsson.com, andreas.a.johnsson@ericsson.com Pages: 15 Characters: 37309 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ippm-twamp-value-added-octets-09.txt URL: http://www.rfc-editor.org/rfc/rfc6802.txt This memo describes an extension to the Two-Way Active Measurement Protocol (TWAMP). Specifically, it extends the TWAMP-Test protocol, which identifies and manages packet trains, in order to measure capacity metrics like the available path capacity, tight section capacity, and UDP delivery rate in the forward and reverse path directions. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IP Performance Metrics Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wes@mti-systems.com Fri Nov 23 19:17:45 2012 Return-Path: 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 F41D221F858A for ; Fri, 23 Nov 2012 19:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9FIlUjQlgxY for ; Fri, 23 Nov 2012 19:17:44 -0800 (PST) Received: from atl4mhob15.myregisteredsite.com (atl4mhob15.myregisteredsite.com [209.17.115.53]) by ietfa.amsl.com (Postfix) with ESMTP id D5AF121F8487 for ; Fri, 23 Nov 2012 19:17:43 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob15.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAO3Hh8K015354 for ; Fri, 23 Nov 2012 22:17:43 -0500 Received: (qmail 28582 invoked by uid 0); 24 Nov 2012 03:17:43 -0000 Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.143.209) by 0 with ESMTPA; 24 Nov 2012 03:17:43 -0000 Message-ID: <50B03C51.5030105@mti-systems.com> Date: Fri, 23 Nov 2012 22:17:37 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: IETF IPPM WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bill Cerveny Subject: [ippm] new co-chairs X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 03:17:45 -0000 Thanks to Henk and Matt for their efforts over the last few years in helping the IPPM WG to complete several useful items. Even through a number of challenges, they got the job done, and did a quality job. Due to the increased interest in IPPM and new proposals coming in, we have decided to install new chairs. I've asked Bill Cerveny and Brian Trammell (on cc) to be the new co-chairs, and they should be showing up on the webpages and aliases like ippm-chairs@tools.ietf.org soon. Please welcome them and begin directing any IPPM chair correspondence to them. -- Wes Eddy MTI Systems From acmorton@att.com Sun Nov 25 06:21:15 2012 Return-Path: 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 5462021F8461; Sun, 25 Nov 2012 06:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.46 X-Spam-Level: X-Spam-Status: No, score=-105.46 tagged_above=-999 required=5 tests=[AWL=-0.783, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB31=0.464, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADndwNkjL50t; Sun, 25 Nov 2012 06:21:11 -0800 (PST) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADFB21F8465; Sun, 25 Nov 2012 06:21:03 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id b4922b05.0.24520.00-489.64368.nbfkord-smmo08.seg.att.com (envelope-from ); Sun, 25 Nov 2012 14:21:08 +0000 (UTC) X-MXL-Hash: 50b229543d1d382f-42ac44bc3616803a49e9031e439d84aa26548599 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qAPEKxkj011567; Sun, 25 Nov 2012 09:20:59 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qAPEKogZ011539; Sun, 25 Nov 2012 09:20:55 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qAPEEoVK001791; Sun, 25 Nov 2012 09:14:50 -0500 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qAPEEio8001744; Sun, 25 Nov 2012 09:14:45 -0500 Received: from lt-hp1044652.att.com (vpn-135-70-161-25.vpn.mwst.att.com[135.70.161.25](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121125141442gw100632iqe>; Sun, 25 Nov 2012 14:14:50 +0000 X-Originating-IP: [135.70.161.25] Message-Id: <7.0.1.0.0.20121125083420.085ee458@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 25 Nov 2012 09:12:36 -0500 To: Brian Trammell , Nicholas Weaver From: Al Morton Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=TspRckrh c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=xm6Tbr5ENoQA:10 a=2xSh8RXx3toA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=glbQQ1A4] X-AnalysisOut: [_rkA:10 a=48vgC7mUAAAA:8 a=n8IGn1O_320mK60UEwYA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=_W_S_7VecoQA:10 a=lZB815dzVvQA:10 a=zWZLj9ytA2] X-AnalysisOut: [irFZkr:21 a=XMF_64RsddoOS0_M:21 a=h7Qxi_pJRNgTow2r:21] Cc: lmap@ietf.org, ippm@ietf.org Subject: Re: [ippm] [lmap] Focus on Tests, Not Architectures... X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 14:21:15 -0000 LMAP and IPPM,

After catching-up on many messages, I would like to add a key
consideration and area for discussion and agreement for
development of standardized tests:

- For each test we eventually specify, it's necessary to specify
  the equivalent measurement points along the user's packet transfer
  path/architecture of each different access technology.

This effort certainly needs folks with standards experience in all of the
access architectures to complete the task, because working out
measurement point details will be a critical aspect of conducting comparable
measurements. So, for anyone who read Nick's and Brian's messages
below (which I mostly agree with) and was about to un-subscribe or add "lmap"
to your spam filter, don't.  There's plenty to do here that's
architecture-related. The various measurement points needed depend
on the list of tests of course, and that list needs discussion, too.

As an example needing some discussion:
All packet-transfer services have a demarcation point where the customer
connects their own equipment to the network. It is valuable from both the
diagnostic and service verification points of view to have a measurement
point very close to the demarcation point. But direct access to this
point is often impossible for a measurement agent - where can we agree
are the functionally equivalent alternatives in each access architecture?
(don't forget wireless access)

regards,
Al

At 11:59 AM 11/20/2012, Brian Trammell wrote:
Hi, Nick,

(Copying this over to IPPM as well, as the focus-on-metrics discussion will be interesting there too).

On 20 Nov 2012, at 17:01 , Nicholas Weaver wrote:

> I've said it once, I'll say it one final time:
>
> This focus on architecture is deeply misguided.  As someone who's built one such architecture (Netalyzr), working on two others (Fathom, a browser extension, and techniques using GuruPlugs/Raspberry Pis), the architecture is the easy part.
>
> In all this work, having some "standard" way to communicate between my measurement clients and servers is useless.  I just use HTTP, HTTPS, or SSH depending on whether quick & easy or server side or mutual authentication is required, with whatever load-balancing is needed handled by random assignment of remote test node.  
>
> The internal data store is whatever is appropriate for the project (eg. for Netalyzr its python pickled objects for storage on our web server, data in a Postgress database for analysis). 
>
> Updates are handled appropriately (Netalyzr is updateless, its an applet so its always up-to-date.  Our android version will just use the app store update mechanism.  Fathom we use Firefox's update mechanism.  The plugs are a hack using SSH, but its a fair amount of custom goop, and they update nightly). 
>
> And all three end up having rather different architectural requirements.

Architectures, I would submit (and as I've said here before), are useful to hang terminology off of: you need boxes and lines so everyone understands (roughly) the same thing when you say "client" and "server" and "controller" with reference to a set of measurements you define.

But yes, specifying a way to specify a measurement is largely arbitrary. I'd even advocate separating the representation from the transport, especially as the general problem of measurement interoperability has data sources operating and wildly different scales, but as you say deciding this is the easy part.

> The hard part is developing the test metrics and measurements, both in the abstract and within the API constraints of the target platform.  E.g. why I like the GuruPlugs and Raspberry Pi is that I can run Java, so therefore I can just "Run Netalyzr" for all Netalyzr tests.  But the same isn't the case for the Ripe Atlas or Bismark platform.
>
> And Marc's list is actually just a start: you also have generic proxy presence & location detection, application specific proxy detection and analysis, packet injection detection, differential application behavior detection, application agnostic traffic shaping detection, DNSSEC support, DNS manipulation detection, path MTU, IPv6 for all of the previous, and a ton of others.  Netalyzr is currently composed of >100 distinct tests.  And this amount just continues to grow.
>
>
> If the IETF actually wants to have an impact in this area, don't bother focusing on protocols for communication, focus on tests with given attributes.  Because people like me who actually build these things are going to ignore an architectural focus because that has no value.  But having ACCEPTED STANDARD tests would be very valuable. 

+ 1e<large number>. Stated another way, the protocol gives you the grammar. What you need to make this at all interoperable is the vocabulary.

IPPM has defined a several of these at a low level, with a focus on active measurement methods that produce comparable results. There appears to be interest in IPPM both in adding passive methods for the existing metrics (see draft-trammell-ippm-hybrid-ps) as well as adding definitions of more complex metrics based in part on the simple ones (see draft-mathis-ippm-model-based-metrics).

> E.g. a good, standard latency-under-load test that can be written in Flash (so TCP/UDP connections only to cooperating servers) would be great.  Our current one in Netalyzr is only OK: we believe that one could do a lot better.
>
> If you could then figure out WHERE the bottleneck is (using a server that can also do simultaneous traceroutes), this would be even more valuable.

(This seems to make the assumption that traceroute-measurable latency is strongly correlated with application latency at a given hop, but I get your point...)

The efforts of IPPM to date have been focused on simply describable, easily repeatable metrics... there's not a lot of specification of arbitrarily complex or unknown preconditions (as would be useful in the latency-under-load example you give), because these tend to be counter to the goals of maximizing repeatability and minimizing uncertainty. There's also a focus on active measurement for the same reason. On the other hand, a lot of work in distributed measurement systems is focused on measuring the network as it is, with implicit or explicit passive components (again, returning to "latency under load", the load traffic will be made up of generated as well as existing background load).

So, what might be useful would be to open another line of work within IPPM on interoperable descriptions of some of these existing tests as empirically specified metrics, perhaps with relaxed compliance with the IPPM framework as appropriate. This could be used to provide a more complex vocabulary to LMAP, but could also be useful independently -- if LMAP is eventually defined to apply only to a restricted set of use cases (i.e. specifically mandated tests for regulatory compliance, but not research or troubleshooting), comparable metrics with incompatible architecture and protocols could still lead to wider interoperability in the measurement space, the need for protocol shims (which are after all easy to write if the number inside has the same meaning) aside.

Best regards,

Brian
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
From mattmathis@google.com Sun Nov 25 13:20:54 2012 Return-Path: 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 34D6521F8442 for ; Sun, 25 Nov 2012 13:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.055 X-Spam-Level: X-Spam-Status: No, score=-103.055 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_UNSUB31=0.464, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6i+n2p2oT+p for ; Sun, 25 Nov 2012 13:20:52 -0800 (PST) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id DE21021F843E for ; Sun, 25 Nov 2012 13:20:51 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq7so2439633wib.1 for ; Sun, 25 Nov 2012 13:20:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U+6EAnArwL2485LEb/QF/nUGekUh7Ht5xC+FKYuagOw=; b=MCAOInBxXeSJs+vh77qyYGjv2eTCzwan1hmTyEuEXQ53Psy7+/7eA1K8iSShliTQ0q iIVs1qIMT06m0Umt+5ttUzNjos6tBWZqoPAPwVeKZDLLiTwlFPx++3MPQ2QzpJL990wy 7pCK+RBhUNZFU4RDK1ZglTm3ykEo1MneU05/4VhWkyVErvjOTTo9bF6gR9T6j4np8kVr w8a8q0MWJZ8TUQyeRfRv29NebM4E3tIRlGVOZhAC5Z+GjhGrfKCUb4SMxKSyWWH0l/0P jRajvbYuI6PKCbfIJvtc66sQeJmTf1M+64x5lmN5VM5AAb/nU0qJyrKF2IYw6cs7fVBa uqFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=U+6EAnArwL2485LEb/QF/nUGekUh7Ht5xC+FKYuagOw=; b=R7XGm0yjfpy+BGGblC/LHzfemad6KtIT15LCHjqpteK2zcc2ZO+1S5sZhaRlH9Jcdf e0E9EX972XQGKqv2odcvKV61COrHg3V/948kEH52QlZVGLVE/qT/WaRq+x3H1Mr/xI9y PAwTzSnLf7da1lvL4caSIHdbVH1aDmvymqC9kzLO2xxU9LRIOITy++D1rJt5zyO9UD3s ir6H/fCksO5/uXS/WigT7LqXu5xPH/MojiTk4E/rWg50/DNxBHM/uu8nfWKJg4HerYWL CkcvHJRj5fi/3uTMHvXfUJw9ae588JgEsZ9dV2htduv4r4FG5AjkKcfllKOXllNcKc81 310g== MIME-Version: 1.0 Received: by 10.180.100.132 with SMTP id ey4mr17844864wib.9.1353878450502; Sun, 25 Nov 2012 13:20:50 -0800 (PST) Received: by 10.227.9.71 with HTTP; Sun, 25 Nov 2012 13:20:50 -0800 (PST) In-Reply-To: <7.0.1.0.0.20121125083420.085ee458@att.com> References: <7.0.1.0.0.20121125083420.085ee458@att.com> Date: Sun, 25 Nov 2012 13:20:50 -0800 Message-ID: From: Matt Mathis To: Al Morton Content-Type: multipart/alternative; boundary=f46d0444ec311c7ea904cf58646f X-Gm-Message-State: ALoCoQm30o4RpYhF5SOIErYp7NJkNVTbEFDkCcf0i+sYjKgaDZu5uD83dF5eDOFKXBN67tBMeEKl77kk6NtWiBVrbFzZp+w6vJnW1UatI32q8Kjc8MhiZRo/NjKWu/2d5lSeuq0y9ERvlG3z8WMTRWMDj1IeTT1LUf/A3v6YChNmnD/QM9VC2t/asaFlkZ+k1TzzysBYfbkt Cc: lmap@ietf.org, ippm@ietf.org Subject: Re: [ippm] [lmap] Focus on Tests, Not Architectures... X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 21:20:54 -0000 --f46d0444ec311c7ea904cf58646f Content-Type: text/plain; charset=ISO-8859-1 I would like to disagree here. Another missing requirement from 2330 is that measurement vantage point should not matter. Consider the standards for milk: milk fat is a parameter that anybody can measure (producer, consumer, independent lab, school classroom, etc). It can be process controlled by the manufacturer (tweaking centrifuge settings), and is useful to the consumer. As an extremely robust metric it stabilizes the industry and brings sanity to the marketplace. A metric that can only be measured by the producer and does not agree with the users intuition as to the value they are getting for their money will always be perceived as crooked, even if it is not. lmap is a logical step down this path..... What we really need are better metrics. The Model Based Metrics ID is my first attempt here, although the words in the draft fall far short of telling the right story. I have started a "Model Based Metrics working doc" at https://docs.google.com/document/d/1KDJMuZ2cWfXbnWjgwNDpN4w5smvZLfCL-gTk6Xgx1mI/edit# I believe that the "Sustained burst test" at the bottom is (close to) the metric that we need. It has (is expected to have) a whole list of cool properties, including actionable by the ISPs, useful to the users, RTT insensitivity, and consequently vantage insensitivity. BTW: I enable "public comment" on the doc, so all of you can add margin notes. I would like to request an extended slot in IPPM, to present this. It should be in a proper ID by that time. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Sun, Nov 25, 2012 at 6:12 AM, Al Morton wrote: > LMAP and IPPM, > > After catching-up on many messages, I would like to add a key > consideration and area for discussion and agreement for > development of standardized tests: > > - For each test we eventually specify, it's necessary to specify > the equivalent measurement points along the user's packet transfer > path/architecture of each different access technology. > > This effort certainly needs folks with standards experience in all of the > access architectures to complete the task, because working out > measurement point details will be a critical aspect of conducting > comparable > measurements. So, for anyone who read Nick's and Brian's messages > below (which I mostly agree with) and was about to un-subscribe or add > "lmap" > to your spam filter, don't. There's plenty to do here that's > architecture-related. The various measurement points needed depend > on the list of tests of course, and that list needs discussion, too. > > As an example needing some discussion: > All packet-transfer services have a demarcation point where the customer > connects their own equipment to the network. It is valuable from both the > diagnostic and service verification points of view to have a measurement > point very close to the demarcation point. But direct access to this > point is often impossible for a measurement agent - where can we agree > are the functionally equivalent alternatives in each access architecture? > (don't forget wireless access) > > regards, > Al > > > At 11:59 AM 11/20/2012, Brian Trammell wrote: > > Hi, Nick, > > (Copying this over to IPPM as well, as the focus-on-metrics discussion > will be interesting there too). > > On 20 Nov 2012, at 17:01 , Nicholas Weaver wrote: > > > I've said it once, I'll say it one final time: > > > > This focus on architecture is deeply misguided. As someone who's built > one such architecture (Netalyzr), working on two others (Fathom, a browser > extension, and techniques using GuruPlugs/Raspberry Pis), the architecture > is the easy part. > > > > In all this work, having some "standard" way to communicate between my > measurement clients and servers is useless. I just use HTTP, HTTPS, or SSH > depending on whether quick & easy or server side or mutual authentication > is required, with whatever load-balancing is needed handled by random > assignment of remote test node. > > > > The internal data store is whatever is appropriate for the project (eg. > for Netalyzr its python pickled objects for storage on our web server, data > in a Postgress database for analysis). > > > > Updates are handled appropriately (Netalyzr is updateless, its an applet > so its always up-to-date. Our android version will just use the app store > update mechanism. Fathom we use Firefox's update mechanism. The plugs are > a hack using SSH, but its a fair amount of custom goop, and they update > nightly). > > > > And all three end up having rather different architectural requirements. > > Architectures, I would submit (and as I've said here before), are useful > to hang terminology off of: you need boxes and lines so everyone > understands (roughly) the same thing when you say "client" and "server" and > "controller" with reference to a set of measurements you define. > > *But yes, specifying a way to specify a measurement is largely arbitrary. > I'd even advocate separating the representation from the transport, > especially as the general problem of measurement interoperability has data > sources operating and wildly different scales, but as you say deciding this > is the easy part. > * > > The hard part is developing the test metrics and measurements, both in > the abstract and within the API constraints of the target platform. E.g. > why I like the GuruPlugs and Raspberry Pi is that I can run Java, so > therefore I can just "Run Netalyzr" for all Netalyzr tests. But the same > isn't the case for the Ripe Atlas or Bismark platform. > > > > And Marc's list is actually just a start: you also have generic proxy > presence & location detection, application specific proxy detection and > analysis, packet injection detection, differential application behavior > detection, application agnostic traffic shaping detection, DNSSEC support, > DNS manipulation detection, path MTU, IPv6 for all of the previous, and a > ton of others. Netalyzr is currently composed of >100 distinct tests. And > this amount just continues to grow. > > > > > > If the IETF actually wants to have an impact in this area, don't bother > focusing on protocols for communication, focus on tests with given > attributes. Because people like me who actually build these things are > going to ignore an architectural focus because that has no value. But > having ACCEPTED STANDARD tests would be very valuable. > > + 1e. Stated another way, the protocol gives you the > grammar. What you need to make this at all interoperable is the vocabulary. > > IPPM has defined a several of these at a low level, with a focus on active > measurement methods that produce comparable results. There appears to be > interest in IPPM both in adding passive methods for the existing metrics > (see draft-trammell-ippm-hybrid-ps) as well as adding definitions of more > complex metrics based in part on the simple ones (see > draft-mathis-ippm-model-based-metrics). > > > E.g. a good, standard latency-under-load test that can be written in > Flash (so TCP/UDP connections only to cooperating servers) would be great. > Our current one in Netalyzr is only OK: we believe that one could do a lot > better. > > > > If you could then figure out WHERE the bottleneck is (using a server > that can also do simultaneous traceroutes), this would be even more > valuable. > > (This seems to make the assumption that traceroute-measurable latency is > strongly correlated with application latency at a given hop, but I get your > point...) > > The efforts of IPPM to date have been focused on simply describable, > easily repeatable metrics... there's not a lot of specification of > arbitrarily complex or unknown preconditions (as would be useful in the > latency-under-load example you give), because these tend to be counter to > the goals of maximizing repeatability and minimizing uncertainty. There's > also a focus on active measurement for the same reason. *On the other > hand, a lot of work in distributed measurement systems is focused on > measuring the network as it is, with implicit or explicit passive > components (again, returning to "latency under load", the load traffic will > be made up of generated as well as existing background load). > * > *So, what might be useful would be to open another line of work within > IPPM on interoperable descriptions of some of these existing tests as > empirically specified metrics, perhaps with relaxed compliance with the > IPPM framework as appropriate.* This could be used to provide a more > complex vocabulary to LMAP, but could also be useful independently -- *if > LMAP is eventually defined to apply only to a restricted set of use cases > (i.e. specifically mandated tests for regulatory compliance, but not > research or troubleshooting), comparable metrics with incompatible > architecture and protocols could still lead to wider interoperability in > the measurement space*, the need for protocol shims (which are after all > easy to write if the number inside has the same meaning) aside. > > Best regards, > > Brian > _______________________________________________ > 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 > > --f46d0444ec311c7ea904cf58646f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I= would like to disagree here. =A0 Another missing requirement from 2330 is = that measurement vantage=A0point=A0should not matter. =A0 Consider the stan= dards for milk: milk fat is a parameter that anybody can measure (producer,= consumer, independent lab, school classroom, etc). =A0It can be process co= ntrolled by the=A0manufacturer (tweaking centrifuge settings), and is usefu= l to the consumer. =A0As an extremely robust metric it=A0stabilizes=A0the i= ndustry and brings sanity to the marketplace.

A metric that can only be measured by the producer and does = not agree with the users intuition as to the value they are=A0getting for t= heir money will always be=A0perceived=A0as crooked, even if it is not. =A0 = lmap is a logical step down this path.....

What we really need are better metrics.

<= /div>
The Model Based Metrics ID is my first attempt here, although the= words in the draft fall far short of telling the right story. =A0 I have s= tarted a "Model Based Metrics working doc" at=A0https://docs.google.com/document/d/1KDJMuZ2cWfXbnWj= gwNDpN4w5smvZLfCL-gTk6Xgx1mI/edit#=A0 =A0 I believe that the "Sust= ained burst test" at the bottom is (close to) the metric that we need.= =A0It has (is expected to have) a whole list of cool properties, including= actionable by the ISPs, useful to the users, RTT=A0insensitivity, and cons= equently vantage insensitivity.

BTW: I enable "public comment" on the doc, so= all of you can add margin notes.

I would like to = request =A0an extended slot in IPPM, to present this. =A0It should be in a = proper ID by that time.

Thanks,
--MM--
The best way to pred= ict the future is to create it. =A0- Alan Kay

Privacy matters! =A0We= know from recent events that people are using our services to speak in def= iance of unjust governments. =A0 We treat privacy and security as matters o= f life and death, because for some users, they are.


On Sun, Nov 25, 2012 at 6:12 AM, Al Mort= on <acmorton@att.com> wrote:
Hi, Nick,

(Copying this over to IPPM as well, as the focus-on-metrics discussion will be interesting there too).

On 20 Nov 2012, at 17:01 , Nicholas Weaver wrote:

> I've said it once, I'll say it one final time:
>
> This focus on architecture is deeply misguided.=A0 As someone who's built one such architecture (Netalyzr), working on two others (Fathom, a browser extension, and techniques using GuruPlugs/Raspberry Pis), the architecture is the easy part.
>
> In all this work, having some "standard" way to communicate between my measurement clients and servers is useless.=A0 I just use HTTP, HTTPS, or SSH depending on whether quick & easy or server side or mutual authentication is required, with whatever load-balancing is needed handled by random assignment of remote test node.=A0=A0
>
> The internal data store is whatever is appropriate for the project (eg. for Netalyzr its python pickled objects for storage on our web server, data in a Postgress database for analysis).=A0
>
> Updates are handled appropriately (Netalyzr is updateless, its an applet so its always up-to-date.=A0 Our android version will just use the app store update mechanism.=A0 Fathom we use Firefox's update mechanism.=A0 The plugs are a hack using SSH, but its a fair amount of custom goop, and they update nightly).=A0
>
> And all three end up having rather different architectural requirements.

Architectures, I would submit (and as I've said here before), are usefu= l to hang terminology off of: you need boxes and lines so everyone understands (roughly) the same thing when you say "client" and "server" and "controller" with reference to a set of measurements you define.

But yes, specifying a way to specify a measurement is largely arbitrary. I'd even advocate separating the representation from the transport, especially as the general problem of measurement interoperability has data sources operating and wildly different scales, but as you say deciding this is the easy part.

> The hard part is developing the test metrics and measurements, both in the abstract and within the API constraints of the target platform.=A0 E.g. why I like the GuruPlugs and Raspberry Pi is that I can run Java, so therefore I can just "Run Netalyzr" for all Netalyzr tests.=A0 But the same isn't the case for the Ripe Atlas or Bismark platform.
>
> And Marc's list is actually just a start: you also have generic proxy presence & location detection, application specific proxy detection and analysis, packet injection detection, differential application behavior detection, application agnostic traffic shaping detection, DNSSEC support, DNS manipulation detection, path MTU, IPv6 for all of the previous, and a ton of others.=A0 Netalyzr is currently composed of >100 distinct tests.=A0 And this amount just continues to grow.
>
>
> If the IETF actually wants to have an impact in this area, don't bother focusing on protocols for communication, focus on tests with given attributes.=A0 Because people like me who actually build these things are going to ignore an architectural focus because that has no value.=A0 But having ACCEPTED STANDARD tests would be very valuable.=A0

+ 1e<large number>. Stated another way, the protocol gives you the grammar. What you need to make this at all interoperable is the vocabulary.

IPPM has defined a several of these at a low level, with a focus on active measurement methods that produce comparable results. There appears to be interest in IPPM both in adding passive methods for the existing metrics (see draft-trammell-ippm-hybrid-ps) as well as adding definitions of more complex metrics based in part on the simple ones (see draft-mathis-ippm-model-based-metrics).

> E.g. a good, standard latency-under-load test that can be written in Flash (so TCP/UDP connections only to cooperating servers) would be great.=A0 Our current one in Netalyzr is only OK: we believe that one could do a lot better.
>
> If you could then figure out WHERE the bottleneck is (using a server that can also do simultaneous traceroutes), this would be even more valuable.

(This seems to make the assumption that traceroute-measurable latency is strongly correlated with application latency at a given hop, but I get your point...)

The efforts of IPPM to date have been focused on simply describable, easily repeatable metrics... there's not a lot of specification of arbitrarily complex or unknown preconditions (as would be useful in the latency-under-load example you give), because these tend to be counter to the goals of maximizing repeatability and minimizing uncertainty. There'= ;s also a focus on active measurement for the same reason. On the other hand, a lot of work in distributed measurement systems is focused on measuring the network as it is, with implicit or explicit passive components (again, returning to "latency under load", the load traffic will be made up of generated as well as existing background load).

So, what might be useful would be to open another line of work within IPPM on interoperable descriptions of some of these existing tests as empirically specified metrics, perhaps with relaxed compliance with the IPPM framework as appropriate. This could be used to provide a more complex vocabulary to LMAP, but could also be useful independently -- if LMAP is eventually defined to apply only to a restricted set of use cases (i.e. specifically mandated tests for regulatory compliance, but not research or troubleshooting), comparable metrics with incompatible architecture and protocols could still lead to wider interoperability in the measurement space, the need for protocol shims (which are after all easy to write if the number inside has the same meaning) aside.

Best regards,

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

_______________________________________________
ippm mailing list
ippm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ippm


--f46d0444ec311c7ea904cf58646f-- From acmorton@att.com Sun Nov 25 21:23:24 2012 Return-Path: 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 4A64621F85CB; Sun, 25 Nov 2012 21:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.077 X-Spam-Level: X-Spam-Status: No, score=-102.077 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB31=0.464, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjJRBFvCecMA; Sun, 25 Nov 2012 21:23:21 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 7F16821F85C2; Sun, 25 Nov 2012 21:23:17 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 4ccf2b05.0.136702.00-494.369389.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 26 Nov 2012 05:23:20 +0000 (UTC) X-MXL-Hash: 50b2fcc87d2c1681-9513ecd829a305884c75a3faa518ebc1bb83ea57 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qAQ5NGAT015038; Mon, 26 Nov 2012 00:23:16 -0500 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qAQ5NDDU015030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2012 00:23:13 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor); Mon, 26 Nov 2012 00:22:57 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qAQ5MvZd012596; Mon, 26 Nov 2012 00:22:57 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qAQ5Mmjc012511; Mon, 26 Nov 2012 00:22:53 -0500 Received: from lt-hp1044652.att.com (vpn-135-70-161-25.vpn.mwst.att.com[135.70.161.25](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121126052250gw100632ive>; Mon, 26 Nov 2012 05:22:51 +0000 X-Originating-IP: [135.70.161.25] Message-Id: <7.0.1.0.0.20121125225022.085ee310@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 26 Nov 2012 00:20:44 -0500 To: Matt Mathis From: Al Morton In-Reply-To: References: <7.0.1.0.0.20121125083420.085ee458@att.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=AMgvexcp c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=xm6Tbr5ENoQA:10 a=2xSh8RXx3toA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=glbQQ1A4] X-AnalysisOut: [_rkA:10 a=hZG83p_yAAAA:8 a=B6KMzFptAAAA:20 a=48vgC7mUAAAA:] X-AnalysisOut: [8 a=oz9-V9JTie3uQvoq9_oA:9 a=CjuIK1q_8ugA:10 a=_W_S_7VecoQ] X-AnalysisOut: [A:10 a=Hz7IrDYlS0cA:10 a=lZB815dzVvQA:10 a=ALAIfxRDjUGEzYC] X-AnalysisOut: [9:21 a=Ar26coLjBKrL5sK-:21 a=oJVC8dsoSXraIRNQ:21] Cc: lmap@ietf.org, ippm@ietf.org Subject: Re: [ippm] [lmap] Focus on Tests, Not Architectures... X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 05:23:24 -0000 Matt,

I think we agree that better metrics are needed for LMAP,
and that ideally a metric can be applied at any point or pair of points.

RFC 2330 and most IPPM metrics have a decidedly Source-to-Destination
host construction. Frankly, we did a better job with arbitrary
measurement points in Rec Y.1540. It's worth a look:
http://www.itu.int/rec/T-REC-Y.1540/en

There are many goals the new metrics could serve:
 - externally observable
 - measurable by users
 - easily related to user application performance
 - service verification
 - support consumer choice of ???
 - etc.
We need to agree on the set that are needed.

While there may be some information in a measurement that covers
a combination of networks, measuring more than one network
is only useful when the combined network path delivers
the target performance - the sunny day outcome. Otherwise,
they are inconclusive, as you said in your memo. Some target
performance levels only apply in the scope where they are offered.

We don't really have the milk fat scenario here, unless the producer,
the truck driver, the convenience store, and your home refrigerator
can all add some unknown amount of fat to the milk. ;-) 

When considering this problem, I've been thinking of the fuel
efficiency ratings provided for new cars in the US and Europe (at least).
The specs illustrate very well that the quantity measured is variable
depending on the conditions of the measurement (in the US, the miles per
gallon for city and highway driving), and they imply the
range of values that normal users can experience (a fairly wide range).
These are some aspects that would be useful to reproduce in our
metrics, I think.

regards, and YMMV,
Al


At 04:20 PM 11/25/2012, Matt Mathis wrote:
I would like to disagree here.   Another missing requirement from 2330 is that measurement vantage point should not matter.   Consider the standards for milk: milk fat is a parameter that anybody can measure (producer, consumer, independent lab, school classroom, etc).  It can be process controlled by the manufacturer (tweaking centrifuge settings), and is useful to the consumer.  As an extremely robust metric it stabilizes the industry and brings sanity to the marketplace.

A metric that can only be measured by the producer and does not agree with the users intuition as to the value they are getting for their money will always be perceived as crooked, even if it is not.   lmap is a logical step down this path.....

What we really need are better metrics.

The Model Based Metrics ID is my first attempt here, although the words in the draft fall far short of telling the right story.   I have started a "Model Based Metrics working doc" at https://docs.google.com/document/d/1KDJMuZ2cWfXbnWjgwNDpN4w5smvZLfCL-gTk6Xgx1mI/edit#     I believe that the "Sustained burst test" at the bottom is (close to) the metric that we need.  It has (is expected to have) a whole list of cool properties, including actionable by the ISPs, useful to the users, RTT insensitivity, and consequently vantage insensitivity.

BTW: I enable "public comment" on the doc, so all of you can add margin notes.

I would like to request  an extended slot in IPPM, to present this.  It should be in a proper ID by that time.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our services to speak in defiance of unjust governments.   We treat privacy and security as matters of life and death, because for some users, they are.


On Sun, Nov 25, 2012 at 6:12 AM, Al Morton <acmorton@att.com> wrote:
LMAP and IPPM,

After catching-up on many messages, I would like to add a key
consideration and area for discussion and agreement for
development of standardized tests:

- For each test we eventually specify, it's necessary to specify
  the equivalent measurement points along the user's packet transfer
  path/architecture of each different access technology.

This effort certainly needs folks with standards experience in all of the
access architectures to complete the task, because working out
measurement point details will be a critical aspect of conducting comparable
measurements. So, for anyone who read Nick's and Brian's messages
below (which I mostly agree with) and was about to un-subscribe or add "lmap"
to your spam filter, don't.  There's plenty to do here that's
architecture-related. The various measurement points needed depend
on the list of tests of course, and that list needs discussion, too.

As an example needing some discussion:
All packet-transfer services have a demarcation point where the customer
connects their own equipment to the network. It is valuable from both the
diagnostic and service verification points of view to have a measurement
point very close to the demarcation point. But direct access to this
point is often impossible for a measurement agent - where can we agree
are the functionally equivalent alternatives in each access architecture?
(don't forget wireless access)

regards,
Al


At 11:59 AM 11/20/2012, Brian Trammell wrote:
Hi, Nick,

(Copying this over to IPPM as well, as the focus-on-metrics discussion will be interesting there too).

On 20 Nov 2012, at 17:01 , Nicholas Weaver wrote:

> I've said it once, I'll say it one final time:
>
> This focus on architecture is deeply misguided.  As someone who's built one such architecture (Netalyzr), working on two others (Fathom, a browser extension, and techniques using GuruPlugs/Raspberry Pis), the architecture is the easy part.
>
> In all this work, having some "standard" way to communicate between my measurement clients and servers is useless.  I just use HTTP, HTTPS, or SSH depending on whether quick & easy or server side or mutual authentication is required, with whatever load-balancing is needed handled by random assignment of remote test node.  
>
> The internal data store is whatever is appropriate for the project (eg. for Netalyzr its python pickled objects for storage on our web server, data in a Postgress database for analysis). 
>
> Updates are handled appropriately (Netalyzr is updateless, its an applet so its always up-to-date.  Our android version will just use the app store update mechanism.  Fathom we use Firefox's update mechanism.  The plugs are a hack using SSH, but its a fair amount of custom goop, and they update nightly). 
>
> And all three end up having rather different architectural requirements.

Architectures, I would submit (and as I've said here before), are useful to hang terminology off of: you need boxes and lines so everyone understands (roughly) the same thing when you say "client" and "server" and "controller" with reference to a set of measurements you define.

But yes, specifying a way to specify a measurement is largely arbitrary. I'd even advocate separating the representation from the transport, especially as the general problem of measurement interoperability has data sources operating and wildly different scales, but as you say deciding this is the easy part.

> The hard part is developing the test metrics and measurements, both in the abstract and within the API constraints of the target platform.  E.g. why I like the GuruPlugs and Raspberry Pi is that I can run Java, so therefore I can just "Run Netalyzr" for all Netalyzr tests.  But the same isn't the case for the Ripe Atlas or Bismark platform.
>
> And Marc's list is actually just a start: you also have generic proxy presence & location detection, application specific proxy detection and analysis, packet injection detection, differential application behavior detection, application agnostic traffic shaping detection, DNSSEC support, DNS manipulation detection, path MTU, IPv6 for all of the previous, and a ton of others.  Netalyzr is currently composed of >100 distinct tests.  And this amount just continues to grow.
>
>
> If the IETF actually wants to have an impact in this area, don't bother focusing on protocols for communication, focus on tests with given attributes.  Because people like me who actually build these things are going to ignore an architectural focus because that has no value.  But having ACCEPTED STANDARD tests would be very valuable. 

+ 1e<large number>. Stated another way, the protocol gives you the grammar. What you need to make this at all interoperable is the vocabulary.

IPPM has defined a several of these at a low level, with a focus on active measurement methods that produce comparable results. There appears to be interest in IPPM both in adding passive methods for the existing metrics (see draft-trammell-ippm-hybrid-ps) as well as adding definitions of more complex metrics based in part on the simple ones (see draft-mathis-ippm-model-based-metrics).

> E.g. a good, standard latency-under-load test that can be written in Flash (so TCP/UDP connections only to cooperating servers) would be great.  Our current one in Netalyzr is only OK: we believe that one could do a lot better.
>
> If you could then figure out WHERE the bottleneck is (using a server that can also do simultaneous traceroutes), this would be even more valuable.

(This seems to make the assumption that traceroute-measurable latency is strongly correlated with application latency at a given hop, but I get your point...)

The efforts of IPPM to date have been focused on simply describable, easily repeatable metrics... there's not a lot of specification of arbitrarily complex or unknown preconditions (as would be useful in the latency-under-load example you give), because these tend to be counter to the goals of maximizing repeatability and minimizing uncertainty. There's also a focus on active measurement for the same reason. On the other hand, a lot of work in distributed measurement systems is focused on measuring the network as it is, with implicit or explicit passive components (again, returning to "latency under load", the load traffic will be made up of generated as well as existing background load).

So, what might be useful would be to open another line of work within IPPM on interoperable descriptions of some of these existing tests as empirically specified metrics, perhaps with relaxed compliance with the IPPM framework as appropriate. This could be used to provide a more complex vocabulary to LMAP, but could also be useful independently -- if LMAP is eventually defined to apply only to a restricted set of use cases (i.e. specifically mandated tests for regulatory compliance, but not research or troubleshooting), comparable metrics with incompatible architecture and protocols could still lead to wider interoperability in the measurement space, the need for protocol shims (which are after all easy to write if the number inside has the same meaning) aside.

Best regards,

Brian
_______________________________________________
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

From Ruediger.Geib@telekom.de Mon Nov 26 01:26:31 2012 Return-Path: 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 2B9F021F869D; Mon, 26 Nov 2012 01:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.017 X-Spam-Level: X-Spam-Status: No, score=-3.017 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_UNSUB31=0.464] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F164jGUh+t5m; Mon, 26 Nov 2012 01:26:29 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id B599321F8564; Mon, 26 Nov 2012 01:26:26 -0800 (PST) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 26 Nov 2012 10:26:24 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 26 Nov 2012 10:26:24 +0100 From: To: , Date: Mon, 26 Nov 2012 10:26:22 +0100 Thread-Topic: [ippm] [lmap] Focus on Tests, Not Architectures... Thread-Index: Ac3LUstbSzAZ8HWIRfKli94Z55UZBQAYrXgg Message-ID: References: <7.0.1.0.0.20121125083420.085ee458@att.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CA7A7C64CC4ADB458B74477EA99DF6F5A2873CCFHE111643EMEA1CD_" MIME-Version: 1.0 Cc: ippm@ietf.org, lmap@ietf.org Subject: Re: [ippm] [lmap] Focus on Tests, Not Architectures... X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 09:26:31 -0000 --_000_CA7A7C64CC4ADB458B74477EA99DF6F5A2873CCFHE111643EMEA1CD_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Matt, Al, one can measure accross a terminal device, home gateway, provider access sy= stem, provider policy management node, provider gateway, central lmap capture sys= tem. >From what I've seen and done, an undesired measurement result only tells me= , I have a problem. But it doesn't explain a black box, it doesn't explain, w= hether and why a reference I compare an actual result against is relevant, what ar= e the differences and so on. I doubt that all issues can be solved by a better metric alone. Regards, R=FCdiger ________________________________ From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Mat= t Mathis Sent: Sunday, November 25, 2012 10:21 PM To: Al Morton Cc: lmap@ietf.org; ippm@ietf.org Subject: Re: [ippm] [lmap] Focus on Tests, Not Architectures... I would like to disagree here. Another missing requirement from 2330 is t= hat measurement vantage point should not matter. Consider the standards f= or milk: milk fat is a parameter that anybody can measure (producer, consum= er, independent lab, school classroom, etc). It can be process controlled = by the manufacturer (tweaking centrifuge settings), and is useful to the co= nsumer. As an extremely robust metric it stabilizes the industry and bring= s sanity to the marketplace. A metric that can only be measured by the producer and does not agree with = the users intuition as to the value they are getting for their money will a= lways be perceived as crooked, even if it is not. lmap is a logical step = down this path..... What we really need are better metrics. The Model Based Metrics ID is my first attempt here, although the words in = the draft fall far short of telling the right story. I have started a "Mo= del Based Metrics working doc" at https://docs.google.com/document/d/1KDJMu= Z2cWfXbnWjgwNDpN4w5smvZLfCL-gTk6Xgx1mI/edit# I believe that the "Sustain= ed burst test" at the bottom is (close to) the metric that we need. It has= (is expected to have) a whole list of cool properties, including actionabl= e by the ISPs, useful to the users, RTT insensitivity, and consequently van= tage insensitivity. BTW: I enable "public comment" on the doc, so all of you can add margin not= es. I would like to request an extended slot in IPPM, to present this. It sho= uld be in a proper ID by that time. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our serv= ices to speak in defiance of unjust governments. We treat privacy and sec= urity as matters of life and death, because for some users, they are. On Sun, Nov 25, 2012 at 6:12 AM, Al Morton > wrote: LMAP and IPPM, After catching-up on many messages, I would like to add a key consideration and area for discussion and agreement for development of standardized tests: - For each test we eventually specify, it's necessary to specify the equivalent measurement points along the user's packet transfer path/architecture of each different access technology. This effort certainly needs folks with standards experience in all of the access architectures to complete the task, because working out measurement point details will be a critical aspect of conducting comparabl= e measurements. So, for anyone who read Nick's and Brian's messages below (which I mostly agree with) and was about to un-subscribe or add "lma= p" to your spam filter, don't. There's plenty to do here that's architecture-related. The various measurement points needed depend on the list of tests of course, and that list needs discussion, too. As an example needing some discussion: All packet-transfer services have a demarcation point where the customer connects their own equipment to the network. It is valuable from both the diagnostic and service verification points of view to have a measurement point very close to the demarcation point. But direct access to this point is often impossible for a measurement agent - where can we agree are the functionally equivalent alternatives in each access architecture? (don't forget wireless access) regards, Al At 11:59 AM 11/20/2012, Brian Trammell wrote: Hi, Nick, (Copying this over to IPPM as well, as the focus-on-metrics discussion will= be interesting there too). On 20 Nov 2012, at 17:01 , Nicholas Weaver wrote: > I've said it once, I'll say it one final time: > > This focus on architecture is deeply misguided. As someone who's built o= ne such architecture (Netalyzr), working on two others (Fathom, a browser e= xtension, and techniques using GuruPlugs/Raspberry Pis), the architecture i= s the easy part. > > In all this work, having some "standard" way to communicate between my me= asurement clients and servers is useless. I just use HTTP, HTTPS, or SSH d= epending on whether quick & easy or server side or mutual authentication is= required, with whatever load-balancing is needed handled by random assignm= ent of remote test node. > > The internal data store is whatever is appropriate for the project (eg. f= or Netalyzr its python pickled objects for storage on our web server, data = in a Postgress database for analysis). > > Updates are handled appropriately (Netalyzr is updateless, its an applet = so its always up-to-date. Our android version will just use the app store = update mechanism. Fathom we use Firefox's update mechanism. The plugs are= a hack using SSH, but its a fair amount of custom goop, and they update ni= ghtly). > > And all three end up having rather different architectural requirements. Architectures, I would submit (and as I've said here before), are useful to= hang terminology off of: you need boxes and lines so everyone understands = (roughly) the same thing when you say "client" and "server" and "controller= " with reference to a set of measurements you define. But yes, specifying a way to specify a measurement is largely arbitrary. I'= d even advocate separating the representation from the transport, especiall= y as the general problem of measurement interoperability has data sources o= perating and wildly different scales, but as you say deciding this is the e= asy part. > The hard part is developing the test metrics and measurements, both in th= e abstract and within the API constraints of the target platform. E.g. why= I like the GuruPlugs and Raspberry Pi is that I can run Java, so therefore= I can just "Run Netalyzr" for all Netalyzr tests. But the same isn't the = case for the Ripe Atlas or Bismark platform. > > And Marc's list is actually just a start: you also have generic proxy pre= sence & location detection, application specific proxy detection and analys= is, packet injection detection, differential application behavior detection= , application agnostic traffic shaping detection, DNSSEC support, DNS manip= ulation detection, path MTU, IPv6 for all of the previous, and a ton of oth= ers. Netalyzr is currently composed of >100 distinct tests. And this amou= nt just continues to grow. > > > If the IETF actually wants to have an impact in this area, don't bother f= ocusing on protocols for communication, focus on tests with given attribute= s. Because people like me who actually build these things are going to ign= ore an architectural focus because that has no value. But having ACCEPTED = STANDARD tests would be very valuable. + 1e. Stated another way, the protocol gives you the grammar.= What you need to make this at all interoperable is the vocabulary. IPPM has defined a several of these at a low level, with a focus on active = measurement methods that produce comparable results. There appears to be in= terest in IPPM both in adding passive methods for the existing metrics (see= draft-trammell-ippm-hybrid-ps) as well as adding definitions of more compl= ex metrics based in part on the simple ones (see draft-mathis-ippm-model-ba= sed-metrics). > E.g. a good, standard latency-under-load test that can be written in Flas= h (so TCP/UDP connections only to cooperating servers) would be great. Our= current one in Netalyzr is only OK: we believe that one could do a lot bet= ter. > > If you could then figure out WHERE the bottleneck is (using a server that= can also do simultaneous traceroutes), this would be even more valuable. (This seems to make the assumption that traceroute-measurable latency is st= rongly correlated with application latency at a given hop, but I get your p= oint...) The efforts of IPPM to date have been focused on simply describable, easily= repeatable metrics... there's not a lot of specification of arbitrarily co= mplex or unknown preconditions (as would be useful in the latency-under-loa= d example you give), because these tend to be counter to the goals of maxim= izing repeatability and minimizing uncertainty. There's also a focus on act= ive measurement for the same reason. On the other hand, a lot of work in di= stributed measurement systems is focused on measuring the network as it is,= with implicit or explicit passive components (again, returning to "latency= under load", the load traffic will be made up of generated as well as exis= ting background load). So, what might be useful would be to open another line of work within IPPM = on interoperable descriptions of some of these existing tests as empiricall= y specified metrics, perhaps with relaxed compliance with the IPPM framewor= k as appropriate. This could be used to provide a more complex vocabulary t= o LMAP, but could also be useful independently -- if LMAP is eventually def= ined to apply only to a restricted set of use cases (i.e. specifically mand= ated tests for regulatory compliance, but not research or troubleshooting),= comparable metrics with incompatible architecture and protocols could stil= l lead to wider interoperability in the measurement space, the need for pro= tocol shims (which are after all easy to write if the number inside has the= same meaning) aside. Best regards, Brian _______________________________________________ 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 --_000_CA7A7C64CC4ADB458B74477EA99DF6F5A2873CCFHE111643EMEA1CD_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Matt, Al,
 
one can measure accross a terminal device, home gatew= ay,=20 provider access system,
provider policy management node, provider gateway, ce= ntral=20 lmap capture system.
 
From what I've seen and done, an undesired measuremen= t result=20 only tells me,
I have a problem. But it doesn't explain a black box,= it=20 doesn't explain, whether
and why a reference I compare an actual result a= gainst=20 is relevant, what are
the differences and so=20 on.
 
I doubt that all issues can be solved by a better met= ric=20 alone.
 
Regards,
 
R=FCdiger
 
 
From:=20 ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Ma= tt=20 Mathis
Sent: Sunday, November 25, 2012 10:21 PM
To: Al= =20 Morton
Cc: lmap@ietf.org; ippm@ietf.org
Subject: Re: [i= ppm]=20 [lmap] Focus on Tests, Not Architectures...

I= would=20 like to disagree here.   Another missing requirement from 2330 is that= =20 measurement vantage point should not matter.   Consider the= =20 standards for milk: milk fat is a parameter that anybody can measure (produ= cer,=20 consumer, independent lab, school classroom, etc).  It can be process= =20 controlled by the manufacturer (tweaking centrifuge settings), and is= =20 useful to the consumer.  As an extremely robust metric=20 it stabilizes the industry and brings sanity to the marketplace.

A metric that can only be measured by the producer and does not agree = with=20 the users intuition as to the value they are getting for their money w= ill=20 always be perceived as crooked, even if it is not.   lmap is= a=20 logical step down this path.....

What we really need are better metrics.

The Model Based Metrics ID is my first attempt here, although the word= s in=20 the draft fall far short of telling the right story.   I have started = a=20 "Model Based Metrics working doc" at https://docs.google.com/document/d/1KDJMuZ2cWfXbnWjgwNDpN4w= 5smvZLfCL-gTk6Xgx1mI/edit# =20   I believe that the "Sustained burst test" at the bottom is (close to= ) the=20 metric that we need.  It has (is expected to have) a whole list of coo= l=20 properties, including actionable by the ISPs, useful to the users,=20 RTT insensitivity, and consequently vantage insensitivity.

BTW: I enable "public comment" on the doc, so all of you can add margi= n=20 notes.

I would like to request  an extended slot in IPPM, to present thi= s.=20  It should be in a proper ID by that time.

Thanks,
--MM--
The best way to predict the future is= to=20 create it.  - Alan Kay

Privacy matters!  We know from rece= nt=20 events that people are using our services to speak in defiance of unjust=20 governments.   We treat privacy and security as matters of life and de= ath,=20 because for some users, they are.


On Sun, Nov 25, 2012 at 6:12 AM, Al Morton <acmorton@att.com> wrote:
LMAP and IPPM,

After catching-up on many messages, I would li= ke to=20 add a key
consideration and area for discussion and agreement=20 for
development of standardized tests:

- For each test we event= ually=20 specify, it's necessary to specify
  the equivalent measurement p= oints=20 along the user's packet transfer
  path/architecture of each diff= erent=20 access technology.

This effort certainly needs folks with standard= s=20 experience in all of the
access architectures to complete the task, be= cause=20 working out
measurement point details will be a critical aspect of=20 conducting comparable
measurements. So, for anyone who read Nick's and= =20 Brian's messages
below (which I mostly agree with) and was about to=20 un-subscribe or add "lmap"
to your spam filter, don't.  There's p= lenty=20 to do here that's
architecture-related. The various measurement point= s=20 needed depend
on the list of tests of course, and that list needs=20 discussion, too.

As an example needing some discussion:
All=20 packet-transfer services have a demarcation point where the=20 customer
connects their own equipment to the network. It is valuable f= rom=20 both the
diagnostic and service verification points of view to have a= =20 measurement
point very close to the demarcation point. But direct acce= ss to=20 this
point is often impossible for a measurement agent - where can we = agree=20
are the functionally equivalent alternatives in each access=20 architecture?
(don't forget wireless access)

regards,
Al


At 11:59 AM 11/20/2012, Brian Trammell wrote:
Hi, Nick,

(Copying this over to IPPM as well, as the=20 focus-on-metrics discussion will be interesting there too).

On 2= 0 Nov=20 2012, at 17:01 , Nicholas Weaver wrote:

> I've said it once, I'll say it one final time:
>
&g= t;=20 This focus on architecture is deeply misguided.  As someone who's = built=20 one such architecture (Netalyzr), working on two others (Fathom, a brow= ser=20 extension, and techniques using GuruPlugs/Raspberry Pis), the architect= ure=20 is the easy part.
>
> In all this work, having some "stand= ard"=20 way to communicate between my measurement clients and servers is=20 useless.  I just use HTTP, HTTPS, or SSH depending on whether quic= k=20 & easy or server side or mutual authentication is required, with=20 whatever load-balancing is needed handled by random assignment of remot= e=20 test node.  
>
> The internal data store is wha= tever=20 is appropriate for the project (eg. for Netalyzr its python pickled obj= ects=20 for storage on our web server, data in a Postgress database for=20 analysis). 
>
> Updates are handled appropriately=20 (Netalyzr is updateless, its an applet so its always up-to-date.  = Our=20 android version will just use the app store update mechanism.  Fat= hom=20 we use Firefox's update mechanism.  The plugs are a hack using SSH= , but=20 its a fair amount of custom goop, and they update nightly). 
&= gt;=20
> And all three end up having rather different architectural=20 requirements.

Architectures, I would submit (and as I've said here before), are= =20 useful to hang terminology off of: you need boxes and lines so everyone= =20 understands (roughly) the same thing when you say "client" and "server"= and=20 "controller" with reference to a set of measurements you=20 define.

But yes, specifying a way to specify a measurement is= =20 largely arbitrary. I'd even advocate separating the representation from= the=20 transport, especially as the general problem of measurement interoperab= ility=20 has data sources operating and wildly different scales, but as you say= =20 deciding this is the easy part.

> The hard part is developing the test metrics and measurements= ,=20 both in the abstract and within the API constraints of the target=20 platform.  E.g. why I like the GuruPlugs and Raspberry Pi is that = I can=20 run Java, so therefore I can just "Run Netalyzr" for all Netalyzr=20 tests.  But the same isn't the case for the Ripe Atlas or Bismark= =20 platform.
>
> And Marc's list is actually just a start: yo= u=20 also have generic proxy presence & location detection, application= =20 specific proxy detection and analysis, packet injection detection,=20 differential application behavior detection, application agnostic traff= ic=20 shaping detection, DNSSEC support, DNS manipulation detection, path MTU= ,=20 IPv6 for all of the previous, and a ton of others.  Netalyzr is=20 currently composed of >100 distinct tests.  And this amount jus= t=20 continues to grow.
>
>
> If the IETF actually wants= to=20 have an impact in this area, don't bother focusing on protocols for=20 communication, focus on tests with given attributes.  Because peop= le=20 like me who actually build these things are going to ignore an architec= tural=20 focus because that has no value.  But having ACCEPTED STANDARD tes= ts=20 would be very valuable. 

+ 1e<large number>. Stated another way, the protocol gives y= ou=20 the grammar. What you need to make this at all interoperable is the=20 vocabulary.

IPPM has defined a several of these at a low level,= with=20 a focus on active measurement methods that produce comparable results. = There=20 appears to be interest in IPPM both in adding passive methods for the=20 existing metrics (see draft-trammell-ippm-hybrid-ps) as well as adding= =20 definitions of more complex metrics based in part on the simple ones (s= ee=20 draft-mathis-ippm-model-based-metrics).

> E.g. a good, standard latency-under-load test that can be wri= tten=20 in Flash (so TCP/UDP connections only to cooperating servers) would be= =20 great.  Our current one in Netalyzr is only OK: we believe that on= e=20 could do a lot better.
>
> If you could then figure out WH= ERE=20 the bottleneck is (using a server that can also do simultaneous=20 traceroutes), this would be even more valuable.

(This seems to make the assumption that traceroute-measurable late= ncy=20 is strongly correlated with application latency at a given hop, but I g= et=20 your point...)

The efforts of IPPM to date have been focused on= =20 simply describable, easily repeatable metrics... there's not a lot of=20 specification of arbitrarily complex or unknown preconditions (as would= be=20 useful in the latency-under-load example you give), because these tend = to be=20 counter to the goals of maximizing repeatability and minimizing uncerta= inty.=20 There's also a focus on active measurement for the same reason. On t= he=20 other hand, a lot of work in distributed measurement systems is focused= on=20 measuring the network as it is, with implicit or explicit passive compo= nents=20 (again, returning to "latency under load", the load traffic will be mad= e up=20 of generated as well as existing background load).

So, w= hat=20 might be useful would be to open another line of work within IPPM on=20 interoperable descriptions of some of these existing tests as empirical= ly=20 specified metrics, perhaps with relaxed compliance with the IPPM framew= ork=20 as appropriate. This could be used to provide a more complex vocabu= lary=20 to LMAP, but could also be useful independently -- if LMAP is eventu= ally=20 defined to apply only to a restricted set of use cases (i.e. specifical= ly=20 mandated tests for regulatory compliance, but not research or=20 troubleshooting), comparable metrics with incompatible architecture and= =20 protocols could still lead to wider interoperability in the measurement= =20 space, the need for protocol shims (which are after all easy to wri= te if=20 the number inside has the same meaning) aside.

Best=20 regards,

Brian
______________________________________________= _
ippm=20 mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm=20

____________________________________________= ___
ippm=20 mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm


--_000_CA7A7C64CC4ADB458B74477EA99DF6F5A2873CCFHE111643EMEA1CD_-- From henk.uijterwaal@gmail.com Mon Nov 26 12:09:49 2012 Return-Path: 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 35DE621F8595 for ; Mon, 26 Nov 2012 12:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Df8-lnFO5-nr for ; Mon, 26 Nov 2012 12:09:48 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 196B821F8540 for ; Mon, 26 Nov 2012 12:09:47 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so5505953bku.31 for ; Mon, 26 Nov 2012 12:09:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+X3mf1IYbMLKEh7N+JcCMwTJS/05n0lBn4WtA9VdlYY=; b=I68QgcrGwJFC+yps5igDIXSofQwwrvTsWGuhQftrugJ2yrehveDglFE9pwLvSEEXd0 897VfdXFr8QDGGFfaCTlJWY5YaH15ivekSFIE28QqKUFObYOZNOaEZ4Uid+eF45mVTkf didkFT4xqdBmkhXXIlC1Aj4kFZA+LeMmc7qiLD/e+7OboZtC05qHm/mD7LrOA2aCFT6c Xpg9iGd9jCjvhWlmv3KYIoNRX6aGgoV1MD4bYaaRrItQoBXtU1R5b2qpM8+dPolsyGMS epOhmHUAAOFkwiJ1RBYAlXBTOqnUEBl2NOkCePfiLwtSLa8ZoSuXi37WVN1pI59WtgX2 24dA== Received: by 10.204.130.210 with SMTP id u18mr3754359bks.129.1353960587078; Mon, 26 Nov 2012 12:09:47 -0800 (PST) Received: from geir.local ([2001:980:1203:1:78b7:a44d:794f:7df6]) by mx.google.com with ESMTPS id e22sm8992690bke.14.2012.11.26.12.09.45 (version=SSLv3 cipher=OTHER); Mon, 26 Nov 2012 12:09:46 -0800 (PST) Message-ID: <50B3AC05.8090108@gmail.com> Date: Mon, 26 Nov 2012 18:51:01 +0100 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: ippm@ietf.org References: <50B03C51.5030105@mti-systems.com> In-Reply-To: <50B03C51.5030105@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [ippm] new co-chairs X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: henk@uijterwaal.nl List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 20:09:49 -0000 On 24/11/2012 04:17, Wesley Eddy wrote: > Thanks to Henk and Matt for their efforts over the last few > years in helping the IPPM WG to complete several useful items. > Even through a number of challenges, they got the job done, and > did a quality job. As most of you know, I have left the measurements field and I'm currently working in a slightly different field. That is actually quite fun even though my day-time job does give me any cycles for IETF work and my time outside work is limited. As you will also have noticed, the IPPM group ended up with a lot of potential new work at the Atlanta meeting. This requires co-chairs who can give the group the necessary attention. So, after 10 years, I have decided to stop as a chair of the IPPM working group. Bill and Brian have voluntered to take over, best of luck to them. I will remain on the list and contribute to the discussions. Feel free to contact me on IPPM related business (or whatever). Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ Read my blog at http://www.uijterwaal.nl/henks_hands.html From mattmathis@google.com Mon Nov 26 12:13:40 2012 Return-Path: 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 AF2FF21F8524 for ; Mon, 26 Nov 2012 12:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGIO+OWrUzSa for ; Mon, 26 Nov 2012 12:13:39 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 60E0421F846D for ; Mon, 26 Nov 2012 12:13:39 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so3335081wey.31 for ; Mon, 26 Nov 2012 12:13:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lCxsZFPD7FbQbE74rrsornsUpAr1wCgay1prY5P+OBQ=; b=nT46WLDoB8L62sXWZIEwI7NROnSQZnxwHPe8XEm3Gj33m3s4pIgKOZGF81JIf5DaNc wq1ZMDWczRUB2JQUp67F9KNWqk4lIMov1rbAHuXxev16VMTJ0VPwypyYbMJHWbTG/3/6 zK8Cyb9Xe8rPfFh3zpvy288tqvBMtcDwbbMw+gQBS/G6L8tuLJ+P3oI8f0w1jp6aLH0z vlJsM2n8AEBY/9q+sYyk9CCR1Ex7DrUWOXQ2LHAfSxDcJwEJOelfxmuSUU8jkvSm0K+B o1k7aCF8SSKMUHoLYmuepLO3vvtGkiJ4vIQA9gtXzgevUyqARGx4S94Ktss39rgvYijb KIoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=lCxsZFPD7FbQbE74rrsornsUpAr1wCgay1prY5P+OBQ=; b=C98tqza/SQC9uC3g9jjakDscBEQTWtTC8D9pxBuIH51/Nz10/ioYzQnYHWkOnXfibt plHTH38gP2TM1A9tRjEa2mSpsAjm/6rqV6CLju982lTYMrOSJSzhx75fcEl+5PgnbL6B E/9a0lC/DqxMJrdxDyaZTwoCLE4QQwMHH5kfoG0Qzubox8xIIGSQjyFRlEJ418/Igk3c c9PT2jNaI/hdG25nA1YkBd1oCEImzaozwElisb0w5Mx7GzDSeSMRyP078ONQOY1lVnza JssgaE3BlmlMpBYw6UJkGA27f48N9I4O5rWwlPbCocE+BgbQbdDg2EutNwQTuxpsPnAX flmQ== MIME-Version: 1.0 Received: by 10.216.140.29 with SMTP id d29mr5370678wej.23.1353960818342; Mon, 26 Nov 2012 12:13:38 -0800 (PST) Received: by 10.227.9.71 with HTTP; Mon, 26 Nov 2012 12:13:38 -0800 (PST) In-Reply-To: <50B3AC05.8090108@gmail.com> References: <50B03C51.5030105@mti-systems.com> <50B3AC05.8090108@gmail.com> Date: Mon, 26 Nov 2012 12:13:38 -0800 Message-ID: From: Matt Mathis To: henk@uijterwaal.nl Content-Type: multipart/alternative; boundary=00504502b6539dfba804cf6b913f X-Gm-Message-State: ALoCoQnIiRJ4HrkwbNyrOAmHjD0/FDS5e8viE5ZMG8j26kQzD5+QM67WgQNjI0eW6bSpOo+MwXvmG/IRGbkRBIloKSGtWnaKUgVg6sxooF+p+Bh0zpQ2k17zQ6Ox+YKcFV9HLeftLr+IyhAQkO/Jz38fVWiDPuVaUG29gJR2FLkDHrUmDwwpVbNnZRMILt7jKDrAvM5vnwX6 Cc: ippm@ietf.org Subject: Re: [ippm] new co-chairs X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 20:13:40 -0000 --00504502b6539dfba804cf6b913f Content-Type: text/plain; charset=ISO-8859-1 Thanks you for all the years of service! --MM-- The best way to predict the future is to create it. - Alan Kay On Mon, Nov 26, 2012 at 9:51 AM, Henk Uijterwaal wrote: > On 24/11/2012 04:17, Wesley Eddy wrote: > > Thanks to Henk and Matt for their efforts over the last few > > years in helping the IPPM WG to complete several useful items. > > Even through a number of challenges, they got the job done, and > > did a quality job. > > As most of you know, I have left the measurements field and I'm currently > working in a slightly different field. That is actually quite fun even > though my day-time job does give me any cycles for IETF work and my time > outside work is limited. > > As you will also have noticed, the IPPM group ended up with a lot of > potential new work at the Atlanta meeting. This requires co-chairs > who can give the group the necessary attention. > > So, after 10 years, I have decided to stop as a chair of the IPPM working > group. > > Bill and Brian have voluntered to take over, best of luck to them. > > I will remain on the list and contribute to the discussions. Feel > free to contact me on IPPM related business (or whatever). > > Henk > > -- > > ------------------------------------------------------------------------------ > Henk Uijterwaal Email: henk(at)uijterwaal.nl > http://www.uijterwaal.nl > Phone: +31.6.55861746 > > ------------------------------------------------------------------------------ > > Read my blog at http://www.uijterwaal.nl/henks_hands.html > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --00504502b6539dfba804cf6b913f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
T= hanks you for all the years of service!
--MM--
The best way to predi= ct the future is to create it. =A0- Alan Kay


On Mon, Nov 26, 2012 at 9:51 AM, Henk Uijterwaal <henk.uijterwaal@= gmail.com> wrote:
On 24/11/2012 04:17, Wesley Eddy wrote:
> Thanks to Henk and Matt for their efforts over the last few
> years in helping the IPPM WG to complete several useful items.
> Even through a number of challenges, they got the job done, and
> did a quality job.

As most of you know, I have left the measurements field and I'm c= urrently
working in a slightly different field. =A0That is actually quite fun even though my day-time job does give me any cycles for IETF work and my time outside work is limited.

As you will also have noticed, the IPPM group ended up with a lot of
potential new work at the Atlanta meeting. =A0This requires co-chairs
who can give the group the necessary attention.

So, after 10 years, I have decided to stop as a chair of the IPPM working group.

Bill and Brian have voluntered to take over, best of luck to them.

I will remain on the list and contribute to the discussions. =A0Feel
free to contact me on IPPM related business (or whatever).

Henk

--
---------------------------------------------------------------------------= ---
Henk Uijterwaal =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Email: = henk(at)uijterwaal.nl
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 http://www.= uijterwaal.nl
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 Phone: +31= .6.55861746
---------------------------------------------------------------------------= ---

Read my blog at http://www.uijterwaal.nl/henks_hands.html
_____________________= __________________________
ippm mailing list
ippm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ippm

--00504502b6539dfba804cf6b913f-- From acmorton@att.com Mon Nov 26 12:21:21 2012 Return-Path: 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 7090F21F851B for ; Mon, 26 Nov 2012 12:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.141 X-Spam-Level: X-Spam-Status: No, score=-105.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odRJy3RW9KMO for ; Mon, 26 Nov 2012 12:21:20 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2E121F852A for ; Mon, 26 Nov 2012 12:21:20 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id d3fc3b05.0.377744.00-452.1054567.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 26 Nov 2012 20:21:20 +0000 (UTC) X-MXL-Hash: 50b3cf40422ecc87-a5a52db121bd8e61f0fcc6d957a9aefc2085b466 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qAQKLGRC017553 for ; Mon, 26 Nov 2012 15:21:17 -0500 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qAQKL7CR017511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Nov 2012 15:21:11 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Mon, 26 Nov 2012 15:21:00 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qAQKKvgr022709 for ; Mon, 26 Nov 2012 15:20:57 -0500 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qAQKKqi5022567 for ; Mon, 26 Nov 2012 15:20:53 -0500 Received: from lt-hp1044652.att.com (dn135-16-251-78.dhcpn.ugn.att.com[135.16.251.78](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121126202054gw100632jpe>; Mon, 26 Nov 2012 20:20:55 +0000 X-Originating-IP: [135.16.251.78] Message-Id: <7.0.1.0.0.20121126151702.014bc398@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 26 Nov 2012 15:18:45 -0500 To: Matt Mathis , henk@uijterwaal.nl From: Al Morton In-Reply-To: References: <50B03C51.5030105@mti-systems.com> <50B3AC05.8090108@gmail.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=bfTcppzB c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=DwyFDWaKD4wA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=HRaYpaLxXLoA:10 a=PE_ijasn] X-AnalysisOut: [rvims61Vr8gA:9 a=CjuIK1q_8ugA:10 a=_W_S_7VecoQA:10] Cc: ippm@ietf.org Subject: Re: [ippm] new co-chairs X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 20:21:22 -0000 At 03:13 PM 11/26/2012, Matt Mathis wrote:
Thanks you for all the years of service!
--MM--
+1, and for taking care of a very important topic at IETF,
something many have come to realize again...

Al


From steve.baillargeon@ericsson.com Mon Nov 26 12:28:56 2012 Return-Path: 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 EFC7921F880A for ; Mon, 26 Nov 2012 12:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgVLU5+qgXGA for ; Mon, 26 Nov 2012 12:28:55 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 29DC221F8781 for ; Mon, 26 Nov 2012 12:28:55 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qAQKadJ3008167; Mon, 26 Nov 2012 14:36:57 -0600 Received: from EUSAAHC003.ericsson.se (147.117.188.81) by eusaamw0712.eamcs.ericsson.se (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 26 Nov 2012 15:28:44 -0500 Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.001; Mon, 26 Nov 2012 15:28:44 -0500 From: Steve Baillargeon To: "henk@uijterwaal.nl" , Matthew J Zekauskas Thread-Topic: [ippm] new co-chairs Thread-Index: AQHNzBIGG5lnL0DQEEC0ygYPjhkinZf8jtyw Date: Mon, 26 Nov 2012 20:28:44 +0000 Message-ID: References: <50B03C51.5030105@mti-systems.com> <50B3AC05.8090108@gmail.com> In-Reply-To: <50B3AC05.8090108@gmail.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ippm@ietf.org" Subject: Re: [ippm] new co-chairs X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 20:28:56 -0000 Hi Henk, Hi Matt It was fun working with both of you. Best of luck! -Steve -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Hen= k Uijterwaal Sent: November-26-12 12:51 PM To: ippm@ietf.org Subject: Re: [ippm] new co-chairs On 24/11/2012 04:17, Wesley Eddy wrote: > Thanks to Henk and Matt for their efforts over the last few years in=20 > helping the IPPM WG to complete several useful items. > Even through a number of challenges, they got the job done, and did a=20 > quality job. As most of you know, I have left the measurements field and I'm currently w= orking in a slightly different field. That is actually quite fun even thou= gh my day-time job does give me any cycles for IETF work and my time outsid= e work is limited. As you will also have noticed, the IPPM group ended up with a lot of potent= ial new work at the Atlanta meeting. This requires co-chairs who can give = the group the necessary attention. So, after 10 years, I have decided to stop as a chair of the IPPM working g= roup. Bill and Brian have voluntered to take over, best of luck to them. I will remain on the list and contribute to the discussions. Feel free to = contact me on IPPM related business (or whatever). Henk -- ---------------------------------------------------------------------------= --- Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ---------------------------------------------------------------------------= --- Read my blog at http://www.uijterwaal.nl/henks_hands.html _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From Barry.Constantine@jdsu.com Mon Nov 26 12:34:41 2012 Return-Path: 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 4294821F86E4 for ; Mon, 26 Nov 2012 12:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7qRJU1a++tx for ; Mon, 26 Nov 2012 12:34:40 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 81E9021F8467 for ; Mon, 26 Nov 2012 12:34:27 -0800 (PST) Received: from mx5.jdsu.com ([209.36.247.247]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKULPSUCONQG4LZPaFHD4Lj6beBzJO6QHg@postini.com; Mon, 26 Nov 2012 12:34:29 PST Received: from AMEXHTCA03.ds.jdsu.net (192.168.10.43) by mx5.jdsu.com (192.168.10.247) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 26 Nov 2012 12:34:04 -0800 Received: from AMEXMB01.ds.jdsu.net ([fe80::9402:2c4c:29f3:a264]) by AMEXHTCA03.ds.jdsu.net ([fe80::24df:4228:5274:253d%14]) with mapi id 14.02.0318.004; Mon, 26 Nov 2012 12:34:23 -0800 From: Barry Constantine To: Al Morton , Matt Mathis , "henk@uijterwaal.nl" Thread-Topic: [ippm] new co-chairs Thread-Index: AQHNyfJItJEa0pGw8ECsnT0VkJUiCZf8k1L1gAADA+A= Date: Mon, 26 Nov 2012 20:34:23 +0000 Message-ID: References: <50B03C51.5030105@mti-systems.com> <50B3AC05.8090108@gmail.com> <7.0.1.0.0.20121126151702.014bc398@att.com> In-Reply-To: <7.0.1.0.0.20121126151702.014bc398@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.234.234.5] Content-Type: multipart/alternative; boundary="_000_DE2AAE0A8826CF4ABC3A6CCB756356EB096EABAMEXMB01dsjdsunet_" MIME-Version: 1.0 Cc: "ippm@ietf.org" Subject: Re: [ippm] new co-chairs X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 20:34:41 -0000 --_000_DE2AAE0A8826CF4ABC3A6CCB756356EB096EABAMEXMB01dsjdsunet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Henk and Matt, Being a newbie to the IETF a few years ago, I really appreciated all the he= lp to get started. You two are really devoted folks and all around great guys. Best of luck. Barry Constantine From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Al = Morton Sent: Monday, November 26, 2012 3:19 PM To: Matt Mathis; henk@uijterwaal.nl Cc: ippm@ietf.org Subject: Re: [ippm] new co-chairs At 03:13 PM 11/26/2012, Matt Mathis wrote: Thanks you for all the years of service! --MM-- +1, and for taking care of a very important topic at IETF, something many have come to realize again... Al --_000_DE2AAE0A8826CF4ABC3A6CCB756356EB096EABAMEXMB01dsjdsunet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Henk and Matt,=

 <= /p>

Being a newbie to the IET= F a few years ago, I really appreciated all the help to get started.

 <= /p>

You two are really devote= d folks and all around great guys.

 <= /p>

Best of luck.<= /span>

 <= /p>

Barry Constantine

 <= /p>

From: ippm-bou= nces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Al Morton
Sent: Monday, November 26, 2012 3:19 PM
To: Matt Mathis; henk@uijterwaal.nl
Cc: ippm@ietf.org
Subject: Re: [ippm] new co-chairs

 

At 03:13 PM 11/26/2012, Matt Mathis wrote:

Thanks you for all the ye= ars of service!

--MM--

+1, and for takin= g care of a very important topic at IETF,
something many have come to realize again...

Al

--_000_DE2AAE0A8826CF4ABC3A6CCB756356EB096EABAMEXMB01dsjdsunet_-- From mattmathis@google.com Mon Nov 26 12:49:40 2012 Return-Path: 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 F103621F866B for ; Mon, 26 Nov 2012 12:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjVQ5SY4NFBM for ; Mon, 26 Nov 2012 12:49:40 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 93E8E21F8651 for ; Mon, 26 Nov 2012 12:49:39 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so3269447wib.13 for ; Mon, 26 Nov 2012 12:49:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zYEtqce4YyiEp/SPHBIOl30u5DSxGtp8fUlTcauzunI=; b=ezpvUKe1vQS1ETVRNuvyf/muEkOJR17RK2x+T+cuDFxxKXxvgFpIm6JvJM84J0L2ms WotoT5ECBSIu2MhMndRoaA57wkTmwSKZ7AXeIbh3TwYeuEYJ3Ir7FEbgKbAxbolnO6Aw 0VUuGFF/5ehZD3P6yE3ch/WA6rGktmsYu3ECJ4UY7deXnZj5zNfnqn5fS3z29oQ4OnvO 9SBNPTjCSJBVQxBc3YF7t8Jn79TVFaCAIQaEM4ubARVaWe7jMgR0EV3Z+Ht7xEdzsqfS Is6B4tolPCW1Q+kyudI35U7/rnQMI+n7X22IMg+1U6sUiJq0VqaE0bSnnnBf6c8XLfSJ Z7tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=zYEtqce4YyiEp/SPHBIOl30u5DSxGtp8fUlTcauzunI=; b=dHAuc5PiHSC9L7MNWHyMS5Dw1QN9o+k/PfD5oTC20smAq92kHKknEhq3gwzkabHXST p0VFPBKHIMJ8qidAFYB7gs94WJhum1f3luA2MVJTaK4gMMSjlI18/cTKHFw/uy4K0o0G 0kNQGxg3H1mdiGxaASz4chaeHu1qeAaqUwJB8T8Wcec7hXlR6XCQGgAXxm5Jb3rtH0jL 8pYIgpMM7Na0sQIRCaEAvFSj0T2TY9pAY3lGkNaGuch5QI+ZOrdxCJfH06QhW67Pmfss oL7RGapKnHFWqGzL509skRpIbs23C3TePYLDJ5zVfsBLik59q55n72o0lm0ERxSsBavg /xHQ== MIME-Version: 1.0 Received: by 10.216.133.75 with SMTP id p53mr5133414wei.127.1353962978596; Mon, 26 Nov 2012 12:49:38 -0800 (PST) Received: by 10.227.9.71 with HTTP; Mon, 26 Nov 2012 12:49:38 -0800 (PST) In-Reply-To: References: <50B03C51.5030105@mti-systems.com> <50B3AC05.8090108@gmail.com> <7.0.1.0.0.20121126151702.014bc398@att.com> Date: Mon, 26 Nov 2012 12:49:38 -0800 Message-ID: From: Matt Mathis To: Barry Constantine , Matt Zekauskas Content-Type: multipart/alternative; boundary=0016e6dd8a9160d7a304cf6c12eb X-Gm-Message-State: ALoCoQkyG4iMGxBvfPuogZ7ej5kUWgLxDP4WrMKirzyk7TPwQ8wUiH55W+iir5qTwrQtzFpo3ZbFMrIaKTLRhM/P6ccdUKEW8O0frvMONiz869rF/lIr2STwSjxwOQYoEZ+Y3P/47erY+eUyc+A+rzHA+A/rqt0f+yPQXAbV7BvWZK4UmMbaGmiZHsAMliQAaKvoWdYWirP6 Cc: Al Morton , "ippm@ietf.org" Subject: Re: [ippm] new co-chairs X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 20:49:41 -0000 --0016e6dd8a9160d7a304cf6c12eb Content-Type: text/plain; charset=ISO-8859-1 Oops, time to invoke an old joke: Matt Zekauskas and I used to call ourselves the "anycast Matt's," because we often ended up handling or redirecting each other's requests. MattZ is not retiring from IPPM (as far as I know). After being very low profile in IPPM for more than a decade, I am back into measurement nearly full time. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Mon, Nov 26, 2012 at 12:34 PM, Barry Constantine < Barry.Constantine@jdsu.com> wrote: > Henk and Matt,**** > > ** ** > > Being a newbie to the IETF a few years ago, I really appreciated all the > help to get started.**** > > ** ** > > You two are really devoted folks and all around great guys.**** > > ** ** > > Best of luck.**** > > ** ** > > Barry Constantine**** > > ** ** > > *From:* ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] *On Behalf > Of *Al Morton > *Sent:* Monday, November 26, 2012 3:19 PM > *To:* Matt Mathis; henk@uijterwaal.nl > *Cc:* ippm@ietf.org > > *Subject:* Re: [ippm] new co-chairs**** > > ** ** > > At 03:13 PM 11/26/2012, Matt Mathis wrote:**** > > Thanks you for all the years of service! **** > > --MM--**** > > +1, and for taking care of a very important topic at IETF, > something many have come to realize again... > > Al > > **** > --0016e6dd8a9160d7a304cf6c12eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
O= ops, time to invoke an old joke: =A0Matt=A0Zekauskas and I used to call our= selves the "anycast Matt's,"=A0because we often ended up hand= ling or redirecting each other's requests.

MattZ is not=A0retiring=A0from IPPM (as far as I know).

After being very low=A0profile=A0in IPPM for more than= a decade, I am back into measurement nearly full time.

Thanks,
--MM--
The best way to predict the future is to= create it. =A0- Alan Kay

Privacy matters! =A0We know from recent ev= ents that people are using our services to speak in defiance of unjust gove= rnments. =A0 We treat privacy and security as matters of life and death, be= cause for some users, they are.


On Mon, Nov 26, 2012 at 12:34 PM, Barry = Constantine <Barry.Constantine@jdsu.com> wrote:
=

Henk and Matt,<= /u>

=A0<= /p>

Being a newbie to the IET= F a few years ago, I really appreciated all the help to get started.=

=A0<= /p>

You two are really devote= d folks and all around great guys.

=A0<= /p>

Best of luck.

=A0<= /p>

Barry Constantine<= u>

=A0<= /p>

From: ippm-bounces@ietf.org [mailto:ippm-= bounces@ietf.org] On Behalf Of Al Morton
Sent: Monday, November 26, 2012 3:19 PM
To: Matt Mathis; henk@uijterwaal.nl
Cc: ippm@ietf.org=


Subject: Re: [ippm] new co-chairs

=A0

At 03:13 PM 11/26/2012, Matt Mathis wrote:=

Thanks you for all the ye= ars of service!

--MM--

+1, and for taking ca= re of a very important topic at IETF,
something many have come to realize again...

Al


--0016e6dd8a9160d7a304cf6c12eb-- From shane@castlepoint.net Mon Nov 26 20:40:07 2012 Return-Path: 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 550F721F8442 for ; Mon, 26 Nov 2012 20:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnoTV99scNpn for ; Mon, 26 Nov 2012 20:40:06 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 45F3321F84C7 for ; Mon, 26 Nov 2012 20:40:06 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id B7CD521C1 for ; Tue, 27 Nov 2012 04:40:05 +0000 (UTC) Received: from mbp.castlepoint.net (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id C42EF21B7; Mon, 26 Nov 2012 21:40:03 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: Date: Mon, 26 Nov 2012 21:40:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6112F5DD2D9@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6112F5DD81F@GAALPA1MSGUSR9L.ITServices.sbc.com> <52C5FD9F-E083-4075-AE24-763306DBBFA7@icsi.berkeley.edu> <2D09D61DDFA73D4C884805CC7865E6112F5DD96D@GAALPA1MSGUSR9L.ITServices.sbc.com> To: KEN KO X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Nov 26 21:40:05 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 50b44425199636789612040 X-DSPAM-Factors: 27, inform+#+of, 0.40000, paragraph+#+#+#+interested, 0.40000, Measurement+#+#+scientific, 0.40000, should+#+#+to, 0.40000, 2nd+#+I, 0.40000, interested+#+#+#+not, 0.40000, metrics+#+#+#+we, 0.40000, repeatability+#+#+#+There's, 0.40000, be+#+#+#+extremely, 0.40000, KO+adtran, 0.40000, his+e, 0.40000, figure+#+their, 0.40000, or+#+#+as, 0.40000, basic+#+#+the, 0.40000, assumption+#+the, 0.40000, and+#+#+#+have, 0.40000, could+progress, 0.40000, the+#+end, 0.40000, the+#+#+as, 0.40000, at+#+#+#+KEN, 0.40000, Subject*on+Tests, 0.40000, only+#+new, 0.40000, complex+or, 0.40000, a+#+#+#+LMAP, 0.40000, be+gleaned, 0.40000, focused+#+simply, 0.40000, the+#+I, 0.40000 X-Mailman-Approved-At: Mon, 26 Nov 2012 22:39:56 -0800 Cc: "lmap@ietf.org" , "STARK, BARBARA H" , "ippm@ietf.org" Subject: Re: [ippm] [lmap] Focus on Tests, Not Architectures... X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 04:40:07 -0000 On Nov 20, 2012, at 10:53 AM, KEN KO wrote: >> Since client and controller are deployed by the same entity, it = should be up to that entity to figure out their control architecture, = and that entity should have full say in how to do their own control = architecture. >=20 > I don't think it's a universally held assumption that the client and = controller are deployed by the same entity. +1. > For instance, a regulator use case spanning multiple operators could = use a controller function (and, a data collection function) that = communicates with clients deployed by each of those operators. So I = don't think we should ignore architecture. Agreed. I also want to stress that there are other applicable, = non-regulatory use cases, as well, where (for example) a single = controller speaks to LMAP measurement clients deployed across a = multitude of operators. > That said, I do believe that focusing on tests is an excellent idea = and that that work could progress in ippm while other lmap issues are = still being discussed. Agreed. I'd also add that there may be two solution spaces emerging wrt = "metrics" (in IPPM) that we discover. First, as Brian Trammell pointed = out in his e-mail on this thread: > The efforts of IPPM to date have been focused on simply describable, = easily repeatable metrics... there's not a lot of specification of = arbitrarily complex or unknown preconditions (as would be = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^ > useful in the latency-under-load example you give), because these tend = to be counter to the goals = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > of maximizing repeatability and minimizing uncertainty. There's also a = focus on active measurement ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > for the same reason. ... these may be applicable for an extremely large number of (or, all?) = "LMAP Measurement Clients" and provide 'basic' measurement capabilities, = e.g.: UDP packet loss, UDP latency, etc. On the other end of the spectrum, I think this is where the research = community is still (?) in the midst of exploring + defining "new" = metrics that can then be used in small to medium-size experiments, = (e.g.: on a smaller base of "LMAP Measurement Clients"), whose = scientific results can ultimately inform which of these tests may get = formalized into standards by the IETF and, if appropriate, incorporated = as "new" tests or replace one or more existing tests (completely). = Obviously, how those tests ultimately get rolled out to the field = (potentially through firmware updates or only when new generations of HW = + firmware are shipped), will be determined by the extent of the change, = etc. While I have an interest in following the new(er) metrics being = explored, in the 2nd paragraph, I am more interested in and do not want = us to lose sight of those basic metrics, in the first paragraph, as I = believe a lot of valuable data can still be gleaned from them, today. -shane= From Ruediger.Geib@telekom.de Tue Nov 27 00:06:47 2012 Return-Path: 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 4729021F85A3 for ; Tue, 27 Nov 2012 00:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.171 X-Spam-Level: X-Spam-Status: No, score=-3.171 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoTyvQCJXHjw for ; Tue, 27 Nov 2012 00:06:46 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id CB85621F84DC for ; Tue, 27 Nov 2012 00:06:45 -0800 (PST) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 27 Nov 2012 09:06:42 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Tue, 27 Nov 2012 09:06:42 +0100 From: To: Date: Tue, 27 Nov 2012 09:06:40 +0100 Thread-Topic: [ippm] new co-chairs Thread-Index: Ac3MEg0iLCFXK6NvTyGVIkco8xIkrwAYnShg Message-ID: References: <50B03C51.5030105@mti-systems.com> <50B3AC05.8090108@gmail.com> In-Reply-To: <50B3AC05.8090108@gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ippm@ietf.org Subject: Re: [ippm] new co-chairs X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 08:06:47 -0000 Hello Henk, thanks for chairing the workgroup and for your support of my efforts within IPPM. Wishing you all the best for life and job, R=FCdiger -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Hen= k Uijterwaal Sent: Monday, November 26, 2012 6:51 PM To: ippm@ietf.org Subject: Re: [ippm] new co-chairs On 24/11/2012 04:17, Wesley Eddy wrote: > Thanks to Henk and Matt for their efforts over the last few > years in helping the IPPM WG to complete several useful items. > Even through a number of challenges, they got the job done, and > did a quality job. As most of you know, I have left the measurements field and I'm currently working in a slightly different field. That is actually quite fun even though my day-time job does give me any cycles for IETF work and my time outside work is limited. As you will also have noticed, the IPPM group ended up with a lot of potential new work at the Atlanta meeting. This requires co-chairs who can give the group the necessary attention. So, after 10 years, I have decided to stop as a chair of the IPPM working group. Bill and Brian have voluntered to take over, best of luck to them. I will remain on the list and contribute to the discussions. Feel free to contact me on IPPM related business (or whatever). Henk -- ---------------------------------------------------------------------------= --- Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ---------------------------------------------------------------------------= --- Read my blog at http://www.uijterwaal.nl/henks_hands.html _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From emile.stephan@orange.com Wed Nov 28 01:14:34 2012 Return-Path: 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 87F1821F8513 for ; Wed, 28 Nov 2012 01:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epZD9sn48YTu for ; Wed, 28 Nov 2012 01:14:34 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D86EF21F84D5 for ; Wed, 28 Nov 2012 01:14:31 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 9DAAE298116; Wed, 28 Nov 2012 10:14:29 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 79EC0238055; Wed, 28 Nov 2012 10:14:29 +0100 (CET) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Wed, 28 Nov 2012 10:14:29 +0100 From: To: IETF IPPM WG , "henk@uijterwaal.nl" , Matthew J Zekauskas Thread-Topic: [ippm] new co-chairs Thread-Index: AQHNyfJMI+mfpj3ppECi676wVXVQr5f9f5NA Date: Wed, 28 Nov 2012 09:14:28 +0000 Message-ID: <12217_1354094069_50B5D5F5_12217_564_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB9092B11@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <50B03C51.5030105@mti-systems.com> In-Reply-To: <50B03C51.5030105@mti-systems.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: Bill Cerveny Subject: Re: [ippm] new co-chairs X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 09:14:34 -0000 Hi Henk and Matt, Thanks for the work done during these years.=20 Cheers Emile -----Message d'origine----- De=A0: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part de W= esley Eddy Envoy=E9=A0: samedi 24 novembre 2012 04:18 =C0=A0: IETF IPPM WG Cc=A0: Bill Cerveny Objet=A0: [ippm] new co-chairs Thanks to Henk and Matt for their efforts over the last few years in helpin= g the IPPM WG to complete several useful items. Even through a number of challenges, they got the job done, and did a quali= ty job. Due to the increased interest in IPPM and new proposals coming in, we have = decided to install new chairs. I've asked Bill Cerveny and Brian Trammell = (on cc) to be the new co-chairs, and they should be showing up on the webpa= ges and aliases like ippm-chairs@tools.ietf.org soon. Please welcome them = and begin directing any IPPM chair correspondence to them. -- Wes Eddy MTI Systems _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From trammell@tik.ee.ethz.ch Wed Nov 28 03:43:16 2012 Return-Path: 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 252CB21F87AC for ; Wed, 28 Nov 2012 03:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMEbYfpXJJNy for ; Wed, 28 Nov 2012 03:43:15 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 81AEB21F850A for ; Wed, 28 Nov 2012 03:43:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 32C62D9305 for ; Wed, 28 Nov 2012 12:43:14 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TZOz5E0-eYBp for ; Wed, 28 Nov 2012 12:43:13 +0100 (MET) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E6168D9304 for ; Wed, 28 Nov 2012 12:43:13 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Nov 2012 12:43:13 +0100 Message-Id: <57F3D156-42D4-40B5-8A35-3D4FE21D43C4@tik.ee.ethz.ch> To: ippm@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [ippm] New IEEE Project P802.16.3 on Mobile Broadband Network Performance Measurements X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 11:43:16 -0000 Greetings, all, For your information, we received a liaison statement on 24 September = from the IEEE about a new project P802.16.3 on Mobile Broadband Network = Performance Measurements; an internal working document assumes =93The = standard should reference metrics specified by IETF (particularly from = the IP Performance Metrics (IPPM) Working Group) whenever feasible.=94 The full liaison statement is available at = https://datatracker.ietf.org/liaison/1195/ Best regards, Brian= From trammell@tik.ee.ethz.ch Wed Nov 28 22:38:27 2012 Return-Path: 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 3C06421F8A08 for ; Wed, 28 Nov 2012 22:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LskM2eyga5q for ; Wed, 28 Nov 2012 22:38:26 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC8021F8A29 for ; Wed, 28 Nov 2012 22:38:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9CA6AD9308 for ; Thu, 29 Nov 2012 07:38:23 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id x6dcF1DebahU for ; Thu, 29 Nov 2012 07:38:23 +0100 (MET) Received: from [10.0.27.113] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 68A46D9305 for ; Thu, 29 Nov 2012 07:38:23 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4598A0B1-6C7C-4FD3-AECA-AC57C002D8EC@tik.ee.ethz.ch> Date: Thu, 29 Nov 2012 07:38:22 +0100 To: ippm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [ippm] Draft minutes from IETF 85 in Atlanta X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 06:38:27 -0000 Greetings, all, I've posted the draft minutes for IETF 85 in Atlanta at: http://www.ietf.org/proceedings/85/minutes/minutes-85-ippm If you believe there's something missing or not quite right there, = please let us know at ippm-chairs@tools.ietf.org within the next week. Best regards, Brian=