From trammell@tik.ee.ethz.ch Wed Oct 2 02:20:45 2013 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 1653221E82BA for ; Wed, 2 Oct 2013 02:20:45 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+2yyPsYDskK for ; Wed, 2 Oct 2013 02:20:32 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFC521E8254 for ; Wed, 2 Oct 2013 02:20:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C1CB8D9308 for ; Wed, 2 Oct 2013 11:20:21 +0200 (MEST) 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 zBRVwonFL3MU for ; Wed, 2 Oct 2013 11:20:21 +0200 (MEST) 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 7307BD9300 for ; Wed, 2 Oct 2013 11:20:21 +0200 (MEST) From: Brian Trammell Content-Type: multipart/signed; boundary="Apple-Mail=_A786CDAB-CE8D-4A0C-B316-A793A81554D6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: Date: Wed, 2 Oct 2013 11:20:20 +0200 To: "ippm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [ippm] Call for agenda slots, IPPM 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, 02 Oct 2013 09:20:45 -0000 --Apple-Mail=_A786CDAB-CE8D-4A0C-B316-A793A81554D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, Please send requests for agenda slots in Vancouver to = ippm-chairs@tools.ietf.org by Friday, October 18. We'd like to have slots for: - each of the current working group drafts,=20 - a continuation of the discussion on a metrics registry, - as well as any new work fitting in our new charter. Many thanks, best regards, Brian --Apple-Mail=_A786CDAB-CE8D-4A0C-B316-A793A81554D6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSS+VUAAoJENt3nsOmbNJcyyMH/05xP61De6V0ToDE1uSe9926 zrpIBxq7WIPV1+Xyeut2JS3vyJ8tCWbjGtVNQhK3n6pXmr36/zbZVuX5tVwpG+/W Y9TXrPXZzRqGtYpzOoghIBaRZ0NndyMloQRs0AY+rrMQXP354S1T+44vmAd3aoAk 4qTZ/GSh5Xyb544VjYmTZuxpZ/zYw0TFWbZcmGf4rFTZhSBaztv05yiTmYeuslhO soY0+I09Au8euBIuJp8o5+dclSOIWec8DbUNl6uNrOvZZe4jJvwm30i5SluIGWJ7 V1xvh5PVIwLl0fs/uoXtKYi2jB1FapWo/iiT04GpyyGGR7M1o9GbSi/htkShW4E= =lFHB -----END PGP SIGNATURE----- --Apple-Mail=_A786CDAB-CE8D-4A0C-B316-A793A81554D6-- From trammell@tik.ee.ethz.ch Thu Oct 3 00:32:36 2013 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 43E9A21F9433 for ; Thu, 3 Oct 2013 00:32:36 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Le65Ib6jJpbc for ; Thu, 3 Oct 2013 00:32:24 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA5521F90AF for ; Thu, 3 Oct 2013 00:32:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id DBE8DD9308 for ; Thu, 3 Oct 2013 09:32:11 +0200 (MEST) 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 28GwgqF2c9vM for ; Thu, 3 Oct 2013 09:32:11 +0200 (MEST) 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 97107D9303 for ; Thu, 3 Oct 2013 09:32:11 +0200 (MEST) From: Brian Trammell Content-Type: multipart/signed; boundary="Apple-Mail=_A257207B-845E-42F2-B055-DE53D89AF86D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <202A7446-2F22-4F9B-9378-C6554249C6BB@tik.ee.ethz.ch> Date: Thu, 3 Oct 2013 09:32:10 +0200 To: "ippm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [ippm] WGLC announcement for draft-ietf-ippm-testplan-rfc2680 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, 03 Oct 2013 07:32:36 -0000 --Apple-Mail=_A257207B-845E-42F2-B055-DE53D89AF86D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, As discussed in Berlin, "Test Plan and Results for Advancing RFC 2680 on = the Standards Track", draft-ietf-ippm-testplan-rfc2680, is ready for = Working Group Last Call (WGLC); this message begins that last call. = Please direct any final comments on this draft to the ippm@ietf.org = mailing list by Friday 18 October 2013. Many thanks, best regards, Brian --Apple-Mail=_A257207B-845E-42F2-B055-DE53D89AF86D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSTR16AAoJENt3nsOmbNJcNcIIAM/kjamhoHBeUtO2Hw3sPRTW kUQIy9VO0GIkHzwSHKyqHywNZZlw8WAl1bE183WiW1hRBOQ4Sw1jbpgyZQRG7oqb zQsNcviYEGLp5lbef+/6jk9pDu0w+ZDQYdpk7UKZ9jEapxeEQboLYOsuVJhAfLVF qCdJl8rBwbB3dlIZmsS5Qc0iqMpgc5aXB1eZ0Kn1axLiRfVk636WTXd/dSjkhxUL WGIRtV8fbxBJBt2ASpLZ6xJYvVHI5aqHParGVYfrjQ6ct1V7dR9kk4369GIfc3rH x9eeom4RR8ZLdIT2OA0leyFGuutd81hTQEVwE9uPF4uMdufvulW9XPfizXnF8kE= =P/q0 -----END PGP SIGNATURE----- --Apple-Mail=_A257207B-845E-42F2-B055-DE53D89AF86D-- From skikuchi@jp.fujitsu.com Thu Oct 3 01:36:01 2013 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 6B67F21F9E96 for ; Thu, 3 Oct 2013 01:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Joh9xxAT27O for ; Thu, 3 Oct 2013 01:35:51 -0700 (PDT) Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ietfa.amsl.com (Postfix) with ESMTP id E18EA21F935A for ; Thu, 3 Oct 2013 01:35:03 -0700 (PDT) Received: from m4.gw.fujitsu.co.jp (unknown [10.0.50.74]) by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id D63503EE0AE for ; Thu, 3 Oct 2013 17:35:01 +0900 (JST) Received: from smail (m4 [127.0.0.1]) by outgoing.m4.gw.fujitsu.co.jp (Postfix) with ESMTP id C52D845DE50 for ; Thu, 3 Oct 2013 17:35:01 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (s4.gw.fujitsu.co.jp [10.0.50.94]) by m4.gw.fujitsu.co.jp (Postfix) with ESMTP id AB03745DE4E for ; Thu, 3 Oct 2013 17:35:01 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 9EEC21DB8041 for ; Thu, 3 Oct 2013 17:35:01 +0900 (JST) Received: from g01jpfmpwkw02.exch.g01.fujitsu.local (g01jpfmpwkw02.exch.g01.fujitsu.local [10.0.193.56]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 50F081DB803B for ; Thu, 3 Oct 2013 17:35:01 +0900 (JST) Received: from localhost.localdomain (localhost [127.0.0.1]) by g01jpfmpwkw02.exch.g01.fujitsu.local (Postfix) with ESMTP id 4534032866D for ; Thu, 3 Oct 2013 17:35:01 +0900 (JST) Received: from g01jpexchkw35.g01.fujitsu.local (unknown [10.0.193.4]) by g01jpfmpwkw02.exch.g01.fujitsu.local (Postfix) with ESMTP id AD72F3285A2 for ; Thu, 3 Oct 2013 17:34:59 +0900 (JST) Received: from G01JPEXMBKW24.g01.fujitsu.local ([10.0.193.132]) by g01jpexchkw35 ([10.0.193.50]) with mapi id 14.03.0146.002; Thu, 3 Oct 2013 17:34:57 +0900 From: "Kikuchi, Shinji" To: "ippm@ietf.org" Thread-Topic: IEEE CloudNet 2013: Call for Participation Thread-Index: Ac7AEwNCHlhROKX0T6aep88ThfQPlQ== Date: Thu, 3 Oct 2013 08:34:59 +0000 Message-ID: <44D5947A9C7ADF429D48E9F4F55AD6C834BD0A34@g01jpexmbkw24> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-securitypolicycheck: OK by SHieldMailChecker v1.8.4 x-originating-ip: [10.25.245.211] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SecurityPolicyCheck-GC: OK by FENCE-Mail Subject: [ippm] IEEE CloudNet 2013: Call for Participation 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, 03 Oct 2013 08:36:01 -0000 We apologize for possible cross postings. -- 2nd IEEE International Conference on Cloud Networking IEEE CloudNet 2013 November 11-13, 2013 | San Francisco, USA http://www.ieee-cloudnet.org/ supported by IEEE Cloud Computing Initiative Keynote speakers: Dave Ward, Cisco Victor Bahl, Microsoft Bruce Davie, VMware This single track conference features seven technical sessions and an invited industry-track session. The conference program is available at: http://www.ieee-cloudnet.org/index.php?page=3Dprogram Early bird registration deadline: October 15, 2013 https://register.comsoc.org/ieee-cloudnet-2013 Hotel registration deadline: October 21, 2013 http://bit.ly/18sca9l From nalini.elkins@insidethestack.com Fri Oct 4 06:21:15 2013 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 6D6D021F9C9B for ; Fri, 4 Oct 2013 06:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bh2jfn7nNDi6 for ; Fri, 4 Oct 2013 06:21:03 -0700 (PDT) Received: from nm11-vm9.access.bullet.mail.bf1.yahoo.com (nm11-vm9.access.bullet.mail.bf1.yahoo.com [216.109.114.232]) by ietfa.amsl.com (Postfix) with ESMTP id 8E93021F9D12 for ; Fri, 4 Oct 2013 06:10:28 -0700 (PDT) Received: from [66.196.81.155] by nm11.access.bullet.mail.bf1.yahoo.com with NNFMP; 04 Oct 2013 13:10:28 -0000 Received: from [66.196.81.130] by tm1.access.bullet.mail.bf1.yahoo.com with NNFMP; 04 Oct 2013 13:10:28 -0000 Received: from [127.0.0.1] by omp1006.access.mail.bf1.yahoo.com with NNFMP; 04 Oct 2013 13:10:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 70645.90808.bm@omp1006.access.mail.bf1.yahoo.com Received: (qmail 95265 invoked by uid 60001); 4 Oct 2013 13:10:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380892227; bh=fGwGyFKWNrkAC9bp4LoU06ni1pokIRQ3q2sC8GwQR2Q=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bukK02xBhaw21ncpciCQV98nHYRJo0kzW/SG5ZcTu8dtizqn1RdgAgT9eGUJ/2FrmAUkYqE2MdEtgkItW+f91V5oGwNXBwvhHUYsRIV42Dd/Fz0Rfe3PWiT5fb0iH3j3kIPG3w77pOV5KF9XXjKayAAyzfPVUHnq5FaRvgrONWs= X-YMail-OSG: BU4VMsYVM1l.PM9E_dXxBjdCBiUriVFJuo8ad5LfRLssNiA FoM9I2aTaZnHhizWEAcHn9mXRDr5GiP_Xz9bmp8Uw5ngnNYbd7O4Gk7clo7s ecCZrUA4a.ZIGcVjAYuVFU_e2KHX8ZZgYNNf8DXqCg_FqiyUbiRckOdlXr5w H2qOZA7Gtce3rfpWvFAEaRzAYwQJdibTqZXox6keqolHQ5VNe9TeMRogjD5M 3AlvmvlEw_n6826WVFNNYZEB5Z6IcDPe7acO_79clriLfl0g0K.qqtd1nyJv kLjPra0cj3mPJJb9_Jl8GiL7U8WSgoOSUdV3Fi_HuQnWEy7XUuc5_KCDWNMd RCHMS8bUXJHY3NvjRnOXqp00Y3iJIiXfJrlDhLeBr6SD3fHeCFM1FyyWYUCZ 1nw9uYmMkNuV.ywtEdepH3w2fQcGyF7UyzGrmUOs62TSWlDOY.iQvPyb0qij c32iP.7wS1EpbbqtUI46ktCh32oz8eEYO6vU0iemxvqBHc0UTTTL7d0nIcN3 SlTHAgV2bEnviX5Wk9tT5k8wpLyaDqvUbZ3i3tEnTiagVWA.uh9S0FLs19WP R0Vj6dIARxZiofqiKdAxsb0m6MUGYy1_zPnN4nP9g.SCirZ3obB06UoODshy jDBBGkxPQWiDHZgU.KF1_k7xbUep5nvXN0vSlk5YtzlYoZT8sAuwg22OfTi4 fFDe_dagEzAAUM07JuJk.eKCWEj_hDNVAYeeuRaSGiBXt Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Fri, 04 Oct 2013 06:10:27 PDT X-Rocket-MIMEInfo: 002.001, CgpXZSBoYXZlIHN1Ym1pdHRlZCBhIG51bWJlciBvZiBkcmFmdHMuIMKgU29tZSBhcmUgbmV3IGFuZCBzb21lIGFyZSB1cGRhdGVzIHRvIG91ciBleGlzdGluZyBQRE0gcHJvcG9zYWwuIMKgV2Ugd291bGQgYXBwcmVjaWF0ZSBhbnkgY29tbWVudHMsIHF1ZXN0aW9ucywgYW5kIGNvcnJlY3Rpb25zIGZyb20gdGhlIGxpc3RzLgoKClRoZSBuZXcgb25lcyBhcmU6CgoxLiDCoEluIElQUE06CgpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1lbGtpbnMtaXBwbS1wZG0tbWV0cmljcy0wMC4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131004030407.30291.83858.idtracker@ietfa.amsl.com> Message-ID: <1380892227.93952.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Fri, 4 Oct 2013 06:10:27 -0700 (PDT) From: Nalini Elkins To: "WG \(v6ops@ietf.org\)" , 6man WG , "ippm@ietf.org" In-Reply-To: <20131004030407.30291.83858.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-585868665-1380892227=:93952" Cc: Sigfrido Perdomo , "keven.haining@usbank.com" , Bill Jouris , Ackermann Michael Subject: [ippm] Fw: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 13:21:15 -0000 --1619178251-585868665-1380892227=:93952 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0AWe have submitted a number of drafts. =A0Some are new and some are up= dates to our existing PDM proposal. =A0We would appreciate any comments, qu= estions, and corrections from the lists.=0A=0A=0AThe new ones are:=0A=0A1. = =A0In IPPM:=0A=0Ahttp://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-= metrics-00.txt=0A=0AThis describes the base and derived metrics which can b= e obtained from the IPv6 PDM DO Extension Header.=0A=0A=0A2. =A0In TicToc:= =0A=0Ahttp://www.ietf.org/internet-drafts/draft-ackermann-tictoc-pdm-ntp-us= age-00.txt=0A=0A=0AThis describes how NTP may be implemented to support PDM= .=0A=0A=0AThe updates are as follows=0A=0A1. =A0In=A06man:=0A=0Ahttp://www.= ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt=0A=0A=0AThis = is the layout of the PDM DO header.=0A=0A=0A2. =A0In v6ops:=0A=0Ahttp://www= .ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-packet-sequence-needed-01= .txt=0A=0A=0Ahttp://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-pd= m-recommended-usage-01.txt=0A=0A=0Ahttp://www.ietf.org/internet-drafts/draf= t-elkins-v6ops-ipv6-end-to-end-rt-needed-01.txt=0A=0A=0AThese are=A0backgro= und for the proposal.=0A=0A=A0=0AThanks,=0A=0ANalini Elkins=0AInside Produc= ts, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A----- Forwarded = Message -----=0AFrom: "internet-drafts@ietf.org" = =0ATo: Nalini Elkins ; William Jouris =0ASent: Thursday, October 3, 2013 8:04 PM=0A= Subject: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt= =0A =0A=0A=0AA new version of I-D, draft-elkins-ippm-pdm-metrics-00.txt=0Ah= as been successfully submitted by Nalini Elkins and posted to the=0AIETF re= pository.=0A=0AFilename:=A0=A0=A0 draft-elkins-ippm-pdm-metrics=0ARevision= :=A0=A0=A0 00=0ATitle:=A0=A0=A0 =A0=A0=A0 IPPM Considerations for the IPv= 6 PDM Extension Header=0ACreation date:=A0=A0=A0 2013-10-03=0AGroup:=A0=A0= =A0 =A0=A0=A0 Individual Submission=0ANumber of pages: 14=0AURL:=A0 =A0 = =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-= metrics-00.txt=0AStatus:=A0 =A0 =A0 =A0 =A0 http://datatracker.ietf.org/doc= /draft-elkins-ippm-pdm-metrics=0AHtmlized:=A0 =A0 =A0 =A0 http://tools.ietf= .org/html/draft-elkins-ippm-pdm-metrics-00=0A=0A=0AAbstract:=0A=A0 To diag= nose performance and connectivity problems, metrics on real=0A=A0 (non-syn= thetic) transmission are critical for timely end-to-end=0A=A0 problem reso= lution. Such diagnostics may be real-time or after the=0A=A0 fact, but mus= t not impact an operational production network. These=0A=A0 metrics are de= fined in the IPv6 Performance and Diagnostic Metrics=0A=A0 Destination Opt= ion (PDM). The base metrics are: packet sequence=0A=A0 number and packet t= imestamp. Other metrics may be derived from these=0A=A0 for use in diagnos= tics.=A0 This document specifies such metrics, their=0A=A0 calculation, an= d usage.=0A=0A=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A=0A=0APlease note that it may take a co= uple of minutes from the time of submission=0Auntil the htmlized version an= d diff are available at tools.ietf.org.=0A=0AThe IETF Secretariat --1619178251-585868665-1380892227=:93952 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

We hav= e submitted a number of drafts.  Some are new and some are updates to = our existing PDM proposal.  We would appreciate any comments, question= s, and corrections from the lists.


<= /span>
The new ones are:

1.  In= IPPM:

http://www.ietf.org/internet-draf= ts/draft-elkins-ippm-pdm-metrics-00.txt

This describes the base and derived metrics which can be obtained from = the IPv6 PDM DO Extension Header.


2.  In TicToc:

http://www.ietf.org/in= ternet-drafts/draft-ackermann-tictoc-pdm-ntp-usage-00.txt
<= div style=3D"background-color: transparent; color: rgb(0, 0, 0); font-size:= 16px; font-family: arial, helvetica, sans-serif; font-style: normal;">
This describes how NTP may be implemented to support = PDM.


T= he updates are as follows

1.  In 6man:

http://ww= w.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt
<= /div>

This is the layout of the PDM DO header.


2.  In v6ops:

http://www.ietf.org/int= ernet-drafts/draft-elkins-v6ops-ipv6-packet-sequence-needed-01.txt

http://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-pdm= -recommended-usage-01.txt
=
http://www.ietf.org/internet-drafts/dra= ft-elkins-v6ops-ipv6-end-to-end-rt-needed-01.txt

These = are background for the = proposal.

 
Thanks,

=
= Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethest= ack.com

----- Forwarded M= essage -----
From: "internet-drafts@ietf.org" <internet-draft= s@ietf.org>
To: Nal= ini Elkins <nalini.elkins@insidethestack.com>; William Jouris <bill.jouris@i= nsidethestack.com>
Sent: Thursday, October 3, 2013 8:04 PM
Subject: New Version Notification for draft-elkins-ippm-= pdm-metrics-00.txt

= =0A
A new version of I-D, draft-elkins-ippm-pdm-metrics-00.txt
has be= en successfully submitted by Nalini Elkins and posted to the
IETF reposi= tory.

Filename:    draft-elkins-ippm-pdm-metrics
= Revision:    00
Title:      &nb= sp; IPPM Considerations for the IPv6 PDM Extension Header
Creation date= :    2013-10-03
Group:      &nb= sp; Individual Submission
Number of pages: 14
URL:    &nbs= p;       http://www.ietf.org/internet-drafts/draft-elkins-i= ppm-pdm-metrics-00.txt
Status:          http://= datatracker.ietf.org/doc/draft-elkins-ippm-pdm-metrics
Htmlized:  &= nbsp;     http://tools.ietf.org/html/draft-elkins-ippm-pdm-metric= s-00


Abstract:
  To diagnose performance and connectivi= ty problems, metrics on real
  (non-synthetic) transmission are critical for timely end-to-end
  problem resolution. Such dia= gnostics may be real-time or after the
  fact, but must not impact= an operational production network. These
  metrics are defined in= the IPv6 Performance and Diagnostic Metrics
  Destination Option = (PDM). The base metrics are: packet sequence
  number and packet t= imestamp. Other metrics may be derived from these
  for use in dia= gnostics.  This document specifies such metrics, their
  calc= ulation, and usage.


            &n= bsp;                     =                      = ;                     &nb= sp;    


Please note that it may take a couple of minu= tes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--1619178251-585868665-1380892227=:93952-- From bclaise@cisco.com Fri Oct 4 07:49:10 2013 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 B25F721F9A70 for ; Fri, 4 Oct 2013 07:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRIr33IEOLSa for ; Fri, 4 Oct 2013 07:48:59 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1604521F9DC7 for ; Fri, 4 Oct 2013 07:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1110; q=dns/txt; s=iport; t=1380897902; x=1382107502; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=xqgzAR9li4zswmzb0yK3kRDq3QEZws5dBEl/JNODDD4=; b=lrAvrDz/kPW0U+KJ0LAAhnDOqeOI5j6Bc4vY+Fil36qlKtIIdg5xEP4V Ufg8jCMK3jlm5VLKHgMluRYszToonKRkR46dt7KG3Idrph2gEXOgvK2CS rUMSu6avZSdOe8UNAu+iorcyfLLKSPySd0o24SKjCcG5gEaW+FB8hpx/y 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAETTTlKQ/khL/2dsb2JhbABZgwfDbBZ0gmRAPRYYAwIBAgFLDQgBAYgCmjOhR5N7A5gBhjWLSoMmOg X-IronPort-AV: E=Sophos;i="4.90,1033,1371081600"; d="scan'208";a="160344950" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 04 Oct 2013 14:44:59 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r94EitlE010020 for ; Fri, 4 Oct 2013 14:44:57 GMT Message-ID: <524ED467.4090704@cisco.com> Date: Fri, 04 Oct 2013 16:44:55 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: IETF IPPM WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ippm] New version of the Performance Metrics Registry draft 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, 04 Oct 2013 14:49:10 -0000 Dear all, I posted a new version of the Performance Metrics Registry draft. Performance Metrics Registry draft-claise-ippm-perf-metric-registry-01.txt Abstract This document specifies an IANA registry for Performance Metrics, for both active monitoring and passive monitoring, along with the initial content. This document also gives a set of guidelines for Performance Metrics requesters and reviewers. What we need is a new performance metrics registry. There are actually 3 different tasks: Task 1: IANA registry setup Task 2: Performance metric guidelines for requester and reviewers Task 3: Initial content for the registry Task 3.1 perf metrics that are already compliant with the RFC 6390 template Task 3.2 selection of operationally relevant IPPM performance metrics 3.2 is out of scope of this document, for now. This draft provides an experiment on how to map IPDV into the RFC 6390 template (this is a first attempt). Please provide your feedback. Regards, Benoit From acmorton@att.com Mon Oct 7 06:11:18 2013 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 7323021E80A5 for ; Mon, 7 Oct 2013 06:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnsVYARPWi1H for ; Mon, 7 Oct 2013 06:11:13 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 93F2A21E80A3 for ; Mon, 7 Oct 2013 06:11:12 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id D6DA9120789; Mon, 7 Oct 2013 09:11:08 -0400 (EDT) Received: from njfpsrvexg1.research.att.com (njfpsrvexg1.research.att.com [135.207.177.20]) by mail-green.research.att.com (Postfix) with ESMTP id 1C4ADE018A; Mon, 7 Oct 2013 09:10:57 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg1.research.att.com ([fe80::58ce:ca01:5d18:db01%13]) with mapi; Mon, 7 Oct 2013 09:11:12 -0400 From: "MORTON, ALFRED C (AL)" To: "Matt Mathis (mattmathis@google.com)" , "ippm@ietf.org" Date: Mon, 7 Oct 2013 09:11:09 -0400 Thread-Topic: Metric requirements posed in Model-based-metrics Thread-Index: Ac7DWMofXimZbnh1Rza0nPuu6Madig== Message-ID: <2845723087023D4CB5114223779FA9C8AB0419A4@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ippm] Metric requirements posed in Model-based-metrics 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, 07 Oct 2013 13:11:18 -0000 Hi Matt, While we (Joachim and I) were developing revisions to the RFC2330 update dr= aft, we considered the metric requirements you wrote in section 3 of the MBM dra= ft: http://tools.ietf.org/html/draft-ietf-ippm-model-based-metrics-00#section-3 We've had several exchanges about the three new requirements for metrics: - Metrics must be actionable (test, repair, verify) - Metrics must be vantage point-invariant - Metrics must be repeatable by multiple parties and felt this would be a topic to open-up with you and on the list. All three are great ideals to have, but given the flexibility with which IPPM metrics are usually specified it seems that these requirements are more applicable to specific instances of metrics that are "ready to measure= ", with a single methodology and a very clear purpose. =20 IOW,=20 s/Metrics/Measurements/ We also note some interactions between these requirements. For example, a measurement which is "actionable" may only possess this property=20 at a sub-set of vantage points. Also, some of the most meaningful=20 vantage points will not necessarily be accessible by all parties. Some specific comments on the three points (excerpts from our discussion)=20 below. We'll be glad to provide more details as necessary. regards, Joachim and Al Actionable:=20 Although this correctly mentions ISPs, it is perfectly valid and possibly more important for *users* who test to get information they can use for identifying the cause and direct repairs or other mitigations. Vantage point invariant:=20 An example scenario which very likely does not fulfill this requirement is a series of time-slotted networks. Just think about Time-Slotted Randomness Cancellation in a mobile-to-mobile test or round-trip measurements from a mobile with uplink and downlink being time-slotted paths. Abstracting from one of these paths makes simplifying assumptions which are not acceptable in the general case (as demonstrated by Joachim's IEEE TIM paper, ref available,=20 more detail in http://tools.ietf.org/html/draft-ietf-ippm-2330-update-00#se= ction-3.4 ). The requirement to consider the remainder of the network path as being ideal is very, very hard in this context. The requirements for an "ideal sub-path" requires study that can likely only be completed when one understands the specific measurement being made. So again we have a concept which appears to apply to particular measurements, not metric definitions applicable to a wide range of measurement scenarios. Metrics must be repeatable by multiple parties: As noted above, it's difficult to rely on the "ideal sub-path"=20 concept to attain this feature. Alternatives, including remote control with user-initiated measurements may be sufficient, and the reality is that everyone needs a (remote) testing=20 partner for active measurements. From talmi@marvell.com Tue Oct 8 02:21:24 2013 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 9CC2621E818F for ; Tue, 8 Oct 2013 02:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccVAwHicyCVU for ; Tue, 8 Oct 2013 02:21:18 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6D21321E81B6 for ; Tue, 8 Oct 2013 02:21:12 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id r989LAPx017506 for ; Tue, 8 Oct 2013 02:21:10 -0700 Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0b-0016f401.pphosted.com with ESMTP id 1fbyum443a-7 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 08 Oct 2013 02:21:10 -0700 Received: from YK-HUB02.marvell.com (10.4.102.52) by sc-owa01.marvell.com (10.93.76.21) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 8 Oct 2013 02:21:08 -0700 Received: from IL-MB01.marvell.com ([10.4.102.53]) by YK-HUB02.marvell.com ([10.4.102.52]) with mapi; Tue, 8 Oct 2013 11:21:05 +0200 From: Tal Mizrahi To: "ippm@ietf.org" Date: Tue, 8 Oct 2013 12:21:04 +0200 Thread-Topic: Requesting comments on draft-mizrahi-owamp-twamp-checksum-trailer-01 Thread-Index: AQHOxAe2ZvPSxF/YJkijl+TkAdFeSA== Message-ID: <74470498B659FA4687F0B0018C19A89C01B87D1AAF04@IL-MB01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89C01B87D1AAF04ILMB01marve_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-08_04:2013-10-08, 2013-10-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1310080014 Subject: [ippm] Requesting comments on draft-mizrahi-owamp-twamp-checksum-trailer-01 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, 08 Oct 2013 09:21:24 -0000 --_000_74470498B659FA4687F0B0018C19A89C01B87D1AAF04ILMB01marve_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Draft 00 was submitted in July, and received comments from Greg and Steve. = Draft 01 addresses these comments, and a couple of additional issues, as sp= ecified below. http://tools.ietf.org/html/draft-mizrahi-owamp-twamp-checksum-trailer-01 Changes since draft 00: - Added clarifications about using the checksum trailer when the features i= n RFC 6038 are enabled. - Increased the minimal padding size from 2 octets to 29 octets. - Rewrote section 3.4 and the "Security Considerations" section; in the cur= rent draft checksum trailers should only be used in unauthenticated mode. - Several typo fixes / clarifications. Comments will be appreciated. Thanks, Tal Mizrahi. --_000_74470498B659FA4687F0B0018C19A89C01B87D1AAF04ILMB01marve_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Draft 0= 0 was submitted in July, and received comments from Greg and Steve. Draft 0= 1 addresses these comments, and a couple of additional issues, as= specified below.
=  
 
Changes= since draft 00:
- Added clarifications about using the checksum trailer when the features i= n RFC 6038 are enabled.
- Increased the minimal padding size from 2 octets to 29 octets.
- Rewrote section 3.4 and the "Security Considerations" section; = in the current draft checksum trailers should only be used in unauthenticat= ed mode.
- Several typo fixes / clarifications.

Comments will be appreciated.
 
Thanks,
Tal Mizrahi.
--_000_74470498B659FA4687F0B0018C19A89C01B87D1AAF04ILMB01marve_-- From acmorton@att.com Sun Oct 13 06:15:24 2013 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 7246D21F9C33 for ; Sun, 13 Oct 2013 06:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QxIYxrWl4qV for ; Sun, 13 Oct 2013 06:15:08 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 35BC121F92E7 for ; Sun, 13 Oct 2013 06:14:49 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 28FDA120F77; Sun, 13 Oct 2013 09:14:48 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.160.21]) by mail-azure.research.att.com (Postfix) with ESMTP id 6FFA5E5227; Sun, 13 Oct 2013 09:14:48 -0400 (EDT) Received: from concierge.research.att.com (135.207.255.39) by njfpsrvexg2.research.att.com (135.207.160.21) with Microsoft SMTP Server (TLS) id 8.3.327.1; Sun, 13 Oct 2013 09:14:37 -0400 Received: from NJFPSRVEXG8.research.att.com ([fe80:0000:0000:0000:cdea:b3f6:62.250.24.65]) by concierge.research.att.com ([135.207.24.83]) with mapi; Fri, 11 Oct 2013 14:38:33 -0400 From: "MORTON, ALFRED C (AL)" To: Nalini Elkins , "ippm@ietf.org" Date: Fri, 11 Oct 2013 14:38:31 -0400 Thread-Topic: [ippm] Fw: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt Thread-Index: Ac7BBKRY3zWtDB5OSc6uf+ENIO1l3AFoF6my Message-ID: <2845723087023D4CB5114223779FA9C8AAD39FC2@njfpsrvexg8.research.att.com> References: <20131004030407.30291.83858.idtracker@ietfa.amsl.com>, <1380892227.93952.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> In-Reply-To: <1380892227.93952.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Sigfrido Perdomo , Bill Jouris , Ackermann Michael Subject: Re: [ippm] Fw: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt 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, 13 Oct 2013 13:15:24 -0000 Hi Nalini and all, Here are a few comments on your IPPM draft. I've looked at some of the background stuff previously, but some of those details may be foggy = now. Hopefully the questions below are clar. regards, Al Early in the Intro, the various time/number fields are referred to as "base= metrics" themselves. I know you'll want to clarify that (they are just fields). In section 1.2: in addition to time and seq number for current packet: PSNLR : Packet Sequence Number Last Received TSLR : Timestamp Last Received the device supplying the header appears to need to maintain flow state to a= dd these "last packet" fields. A very strong justification is probably needed.= =20 Later, I see that the Server host essentially has to store the fields acros= s=20 request-response pairs. Lower and higher layers need to work together, somehow. In Section 3.1 and 3.2, it's not clear which PDM time-stamps support the (r= ound-trip delay and server delay) metrics. When you look at RFC2681, it should be fairly c= lear where=20 the time stamps are applied, and that needs to carry though here (though I = see it later in the example). Looking at the example in section 4, there can be a significant delay betwe= en when the application layer transfers packets to TCP's send buffer and when the p= ackets are actually sent "on the wire" (as we say in IPPM), which happens after the IP= header is applied (or most of the header, in some cases). How would accuracy be maint= ained across all the different layers?=20 Maybe another way to phrase the question is this: How does the process that adds the PDM header (with last Seq number 25) kno= w=20 which packet to add it to?=20 I note that there is IPR declared on this draft, and licensing is not clear= . ________________________________________ From: ippm-bounces@ietf.org [ippm-bounces@ietf.org] On Behalf Of Nalini Elk= ins [nalini.elkins@insidethestack.com] Sent: Friday, October 04, 2013 9:10 AM To: WG (v6ops@ietf.org); 6man WG; ippm@ietf.org Cc: Sigfrido Perdomo; keven.haining@usbank.com; Bill Jouris; Ackermann Mich= ael Subject: [ippm] Fw: New Version Notification for draft-elkins-ippm-p= dm-metrics-00.txt We have submitted a number of drafts. Some are new and some are updates to= our existing PDM proposal. We would appreciate any comments, questions, a= nd corrections from the lists. The new ones are: 1. In IPPM: http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt This describes the base and derived metrics which can be obtained from the = IPv6 PDM DO Extension Header. 2. In TicToc: http://www.ietf.org/internet-drafts/draft-ackermann-tictoc-pdm-ntp-usage-00= .txt This describes how NTP may be implemented to support PDM. The updates are as follows 1. In 6man: http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt This is the layout of the PDM DO header. 2. In v6ops: http://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-packet-sequence= -needed-01.txt http://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-pdm-recommended= -usage-01.txt http://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-end-to-end-rt-n= eeded-01.txt These are background for the proposal. Thanks, Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com ----- Forwarded Message ----- From: "internet-drafts@ietf.org" To: Nalini Elkins ; William Jouris Sent: Thursday, October 3, 2013 8:04 PM Subject: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt A new version of I-D, draft-elkins-ippm-pdm-metrics-00.txt has been successfully submitted by Nalini Elkins and posted to the IETF repository. Filename: draft-elkins-ippm-pdm-metrics Revision: 00 Title: IPPM Considerations for the IPv6 PDM Extension Header Creation date: 2013-10-03 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-m= etrics-00.txt Status: http://datatracker.ietf.org/doc/draft-elkins-ippm-pdm-metr= ics Htmlized: http://tools.ietf.org/html/draft-elkins-ippm-pdm-metrics-0= 0 Abstract: To diagnose performance and connectivity problems, metrics on real (non-synthetic) transmission are critical for timely end-to-end problem resolution. Such diagnostics may be real-time or after the fact, but must not impact an operational production network. These metrics are defined in the IPv6 Performance and Diagnostic Metrics Destination Option (PDM). The base metrics are: packet sequence number and packet timestamp. Other metrics may be derived from these for use in diagnostics. This document specifies such metrics, their calculation, and usage. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From ippm@wjcerveny.com Mon Oct 14 06:28:14 2013 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 08FDD21F9AB4 for ; Mon, 14 Oct 2013 06:28:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XghCWqYCcRLp for ; Mon, 14 Oct 2013 06:28:08 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id E94DB21F9AD2 for ; Mon, 14 Oct 2013 06:28:07 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B11E121B47 for ; Mon, 14 Oct 2013 09:28:06 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute3.internal (MEProxy); Mon, 14 Oct 2013 09:28:06 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date; s=smtpout; bh=U7RRt1exWq+2DHIqc/9YiJnsGoI=; b=OWhKM8zCZGDmVTjKlS+TaiRi7Kmw LDxNg+U5wrph71Nvu6tEfxfnZjppHKWlsg3x0Yx/Ne8RLlLmRSzOkyznqZazzmAm Dg+lUM47GeoQVGRZ6cBCOtoQeFsbGZk+VsCrGCpzs/WcTgUC/iTqFAHFojlNPZNn U8aL39amCHzB4bA= Received: by web4.nyi.mail.srv.osa (Postfix, from userid 99) id 220E2101AD2; Mon, 14 Oct 2013 09:28:06 -0400 (EDT) Message-Id: <1381757286.8567.33770121.08E74A73@webmail.messagingengine.com> X-Sasl-Enc: Hbk341PO8p9ZqGs2/8sPf5Nkz7F3NUCgamqCkfR5DBb7 1381757286 From: William Cerveny To: ippm@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-ce174988 Date: Mon, 14 Oct 2013 09:28:06 -0400 Subject: [ippm] My comments on draft-ietf-ippm-testplan-rfc2680-03 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, 14 Oct 2013 13:28:14 -0000 [Not sure if I need to say that my comments are with my IPPM co-chair hat off, but if yes, I'm saying it :-) ] Ann Cerveny and I are sending more detailed comments and suggestions (mostly grammatical) directly to the authors, but my most significant comments on the draft are: 1) For "One-way Loss, ADK Sample Comparison", there is a sentence that starts, "The common parameters used for tests in this section are:", but no parameters follow. 2) In some of the examples, "public" IP addresses are used (as far as I can tell). Should these addresses be published in an RFC? 3) I think the paragraph beginning with "There is consensus ..." might need some clarification. 4) I thought the formatting of the IF AND THEN statements for the text in section 2 was a little unusual. 5) I would clarify what "Imp" in figure 1 refers to although I figured out (I think) that it refers to "implementation". Bill Cerveny From nalini.elkins@insidethestack.com Tue Oct 15 06:43:49 2013 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 55C9221E80BF for ; Tue, 15 Oct 2013 06:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgcPV2Yh22lX for ; Tue, 15 Oct 2013 06:43:44 -0700 (PDT) Received: from nm11-vm6.access.bullet.mail.gq1.yahoo.com (nm11-vm6.access.bullet.mail.gq1.yahoo.com [216.39.63.159]) by ietfa.amsl.com (Postfix) with ESMTP id DDB6A21E809A for ; Tue, 15 Oct 2013 06:43:43 -0700 (PDT) Received: from [216.39.60.170] by nm11.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Oct 2013 13:43:43 -0000 Received: from [216.39.60.253] by tm6.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Oct 2013 13:43:43 -0000 Received: from [127.0.0.1] by omp1024.access.mail.gq1.yahoo.com with NNFMP; 15 Oct 2013 13:43:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 375691.74155.bm@omp1024.access.mail.gq1.yahoo.com Received: (qmail 99036 invoked by uid 60001); 15 Oct 2013 13:43:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1381844622; bh=7N+wPao/pVksO2K0ggNLhwptpdbWDXE7tF904kPgLdE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=DjeOEFcWrlgm4Csxhr5DDsxquTGLHagxOUpiZ+WawA6jiTgaLvYEGVF2jD0WOSQ4V4oA6KPKT/ZZZHu2CRQQDdfQsYvs65uBBcFF2kJXb2/NI4mOzcEuGOjwKcB0OoC1FYpN9jZIeshvDwuZWZDHBAApPWt13NkzJPlLlEDtiBg= X-YMail-OSG: QjyUqhYVM1lBusGzY2hRGWkC..SeV7xDdb.XFcthk0xei6S KHBcb0FEtg4Jo88Nt65J4RQunow9MZt0vXgvkmpL421o3zswNdgcabW5RSwZ 2EIgaFhth7togrjHeDMLp0NNtOd7p6i6dcLY2sbGzqtfvtAcjYeyltSYtqUv i_BfkoNNa20iJ.xKRiT7R4SXKAnRoBKTdFEht9uRDt7kGqNBx71S8fzLmNQX IoU4fGXoOcR0uiNKyizo.qcpA79OygCe5NRW4oNBqaERbGNpWgYWBJcahE.1 rHR7v9CDzwvgTabLDWT13EsEKaxXCQ2E9zrG0FLSiQ4ot0GSOvgW1CD2sKqK 8_NlOoUy7ZltNIvHswVNNI7XpCN1jRLW9rbdyEm3yNrSz1NKWGjaCSh8SwJ5 MVGXDbWgAHjK6Pzp6OJ5Ia45D9DOd3Fl01AObQ.s80trUZUPNGCovybgVvjy 4mL77nLwtcajiR9hjHugfFW5KlWUhJMwTzNiNxD8u4Y8N.02_KUttOjFRURG Odrm_Rd8PG1HjxqNlMTjI3beULqaXkV.9x1.K0qYHGob0tOF2z6D6TKpwqcb 3hPiLBhK3HXBp6vn98UVknrXFUZNBmCfB8VcN38N1Pvl2AyWw0g21WqIZ0IC 2HbwKiq7YArLClQVZRQFXsJ3irbATw_Lmv0L06aVtcQAFqmfHz6R8arsr._D 8ZWKwc5FK1nN42lJ5YV40Y3SyuElxBhXikmWaSzSs_ekiAK67.JEQOHC._ne hLA_lUc87DIgdfSxUzXLUHo5c4eyJU9dzaDZLSpMxONcPHXqNIZELEllfQuQ FIQjHOc5e_Y8XM_DAqbj6_7ibsrx46ZU- Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Tue, 15 Oct 2013 06:43:42 PDT X-Rocket-MIMEInfo: 002.001, QWwsCgpUaGFua3MgZm9yIHlvdXIgdGhvcm91Z2ggZXhhbWluYXRpb24gYW5kIGdyZWF0IGNvbW1lbnRzLiDCoE15IHJlc3BvbnNlcyBhcmUgaW5saW5lLiDCoCBBbHNvLCBpZiB5b3UgaGF2ZSB0aW1lIGluIFZhbmNvdXZlciwgTWlrZSAmIEkgd291bGQgbGlrZSB0byBhc2sgeW91IHRvIGhhdmUgbHVuY2ggb3IgZGlubmVyIG9uIHVzLiDCoCBJdCBpcyB0aGUgbGVhc3Qgd2UgY2FuIGRvIGZvciBhbGwgeW91ciBoZWxwISDCoFBsZWFzZSBsZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBhIGZyZWUgZGF5LgoKCj5FYXIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131004030407.30291.83858.idtracker@ietfa.amsl.com>, <1380892227.93952.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2845723087023D4CB5114223779FA9C8AAD39FC2@njfpsrvexg8.research.att.com> Message-ID: <1381844622.97264.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Tue, 15 Oct 2013 06:43:42 -0700 (PDT) From: Nalini Elkins To: "MORTON, ALFRED C \(AL\)" , "ippm@ietf.org" In-Reply-To: <2845723087023D4CB5114223779FA9C8AAD39FC2@njfpsrvexg8.research.att.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-2085762115-1381844622=:97264" Cc: Sigfrido Perdomo , Bill Jouris , Ackermann Michael Subject: Re: [ippm] Fw: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 13:43:49 -0000 ---1551098171-2085762115-1381844622=:97264 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Al,=0A=0AThanks for your thorough examination and great comments. =A0My res= ponses are inline. =A0 Also, if you have time in Vancouver, Mike & I would = like to ask you to have lunch or dinner on us. =A0 It is the least we can d= o for all your help! =A0Please let us know if you have a free day.=0A=0A=0A= >Early in the Intro, the various time/number fields are referred to as "bas= e metrics" themselves.=0A>I know you'll want to clarify that (they are just= fields).=0A=0ASure.=0A=0A>In section 1.2: in addition to time and seq numb= er for current packet:=0A=0A=A0> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PSNLR : Pac= ket Sequence Number Last Received=0A=A0> =A0 =A0 =A0 =A0 =A0 =A0 =A0 TSLR= =A0 : Timestamp Last Received=0A=0A>the device supplying the header appears= to need to maintain flow state to add=0A>these "last packet" fields. A ver= y strong justification is probably needed. =0A>Later, I see that the Server= host essentially has to store the fields across =0A>request-response pairs= . Lower and higher layers need to work together,=0A>somehow.=0A=0AThe Desti= nation Options Header is created only by the OS's at the end points. =A0Tha= t is, the Microsofts, linuxes, and IBM's of the world. =A0The OS at the end= point already maintains state. =A0 If you think of TCP TimeWait status for= example. =A0 The connection is in TimeWait status for 2 * MSL. =A0So, obvi= ously state is being maintained. =A0Anyway, all the OS's have control block= s associated with each active connection.=0A=0ANow, there is going to be so= me discussion by the OS vendors about non-TCP protocols! =A0I have particip= ated in those discussions with IBM in a former life (when they OEMed a prod= uct of mine & I wanted them to do something!) =A0but I believe that they ar= e persuadable. =A0 I am guessing that this information is already being mai= ntained. =A0All we are asking for is for it to be exposed.=0A=0AOur header = is not for middle boxes. =A0We are not asking for router, etc. to maintain = state in this way.=0A=0A=0A>In Section 3.1 and 3.2, it's not clear which PD= M time-stamps support the (round-trip delay=0A>and server delay) metrics. W= hen you look at=A0 RFC2681, it should be fairly clear where =0A>the time st= amps are applied, and that needs to carry though here (though I see it late= r=0A>in the example).=0A=0AI will clarify.=0A=0A>Looking at the example in = section 4, there can be a significant delay between when=0A>the application= layer transfers packets to TCP's send buffer and when the packets are=0A>a= ctually sent "on the wire" (as we say in IPPM), which happens after the IP = header is=0A>applied (or most of the header, in some cases). How would accu= racy be maintained=0A>across all the different layers? =0A=0A>Maybe another= way to phrase the question is this:=0A>How does the process that adds the = PDM header (with last Seq number 25) know =0A>which packet to add it to?=A0= =0A=0AThere are 2 questions here. =A0First, it will be the IP layer adding = the times. =A0Yes, I know that it is a "gross" measurement comprising of a = number of components. =A0But, then so is one-way delay. =A0That is, =A0ther= e are multiple components within the path. =A0 The purpose of our measureme= nts is to allow the diagnostician to do very quick triage. =A0That is, to s= ay, is the problem in the network or the server? =A0Then, we hand the probl= em off to the right group who can runmore detailed diagnostic tests. =A0=A0= =0A=0AIn our experience, this is a very valuable kind of measurement to hav= e. =A0A great deal of time, effort and money is spent at large end user sit= es to determine just this. =A0 Anecdotal evidence tells me that this is tru= e for home users of the Internet also. =A0 My working life has been spent a= t large data centers, so that I can answer to without any hesitation.=0A=0A= >=A0I note that there is IPR declared on this draft, and licensing is not c= lear.=0A=0AYes, we do have IPR. =A0I hope I have declared it properly! =A0P= lease let me know if I have not. =A0We have not decided on the exact nature= of the licensing but it will be very reasonable. =A0We want the technology= adopted. =A0 =A0There are=0Amore advanced metrics which can be created fro= m these which is the primary reason for the IPR.=0A=0ABTW, we are starting = to engage in discussions also with folks looking at a new WG.=A0https://sit= es.google.com/site/transportprotocolservices/home/charter-proposal-before-b= of=0AWe feel our metrics / header can help with a unified Simple Congestion= Control (SCC) and Inter-Layer Communication (ILC). =A0 That is some of our= other work. =A0=A0The above group seems to feel that work would fit in wit= h their efforts! =A0I feel that the fields we propose are simple yet very p= owerful. =A0Many uses can be made of them. =A0 I can tell you more on this,= if you have interest.=0A=0A=0A________________________________________=0AF= rom: ippm-bounces@ietf.org [ippm-bounces@ietf.org] On Behalf Of Nalini Elki= ns [nalini.elkins@insidethestack.com]=0ASent: Friday, October 04, 2013 9:10= AM=0ATo: WG (v6ops@ietf.org); 6man WG; ippm@ietf.org=0ACc: Sigfrido Perdom= o; keven.haining@usbank.com; Bill Jouris; Ackermann Michael=0ASubject: [ipp= m] Fw: New Version Notification for=A0 =A0 =A0 =A0 draft-elkins-ippm-pdm-me= trics-00.txt=0A=0AWe have submitted a number of drafts.=A0 Some are new and= some are updates to our existing PDM proposal.=A0 We would appreciate any = comments, questions, and corrections from the lists.=0A=0A=0AThe new ones a= re:=0A=0A1.=A0 In IPPM:=0A=0Ahttp://www.ietf.org/internet-drafts/draft-elki= ns-ippm-pdm-metrics-00.txt=0A=0AThis describes the base and derived metrics= which can be obtained from the IPv6 PDM DO Extension Header.=0A=0A=0A2.=A0= In TicToc:=0A=0Ahttp://www.ietf.org/internet-drafts/draft-ackermann-tictoc= -pdm-ntp-usage-00.txt=0A=0AThis describes how NTP may be implemented to sup= port PDM.=0A=0A=0AThe updates are as follows=0A=0A1.=A0 In 6man:=0A=0Ahttp:= //www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt=0A=0ATh= is is the layout of the PDM DO header.=0A=0A=0A2.=A0 In v6ops:=0A=0Ahttp://= www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-packet-sequence-needed= -01.txt=0A=0Ahttp://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-pd= m-recommended-usage-01.txt=0A=0Ahttp://www.ietf.org/internet-drafts/draft-e= lkins-v6ops-ipv6-end-to-end-rt-needed-01.txt=0A=0AThese are background for = the proposal.=0A=0A=0AThanks,=0A=0ANalini Elkins=0AInside Products, Inc.=0A= (831) 659-8360=0Awww.insidethestack.com=0A=0A----- Forwarded Message -----= =0AFrom: "internet-drafts@ietf.org" =0ATo: Nalini= Elkins ; William Jouris =0ASent: Thursday, October 3, 2013 8:04 PM=0ASubject: New V= ersion Notification for draft-elkins-ippm-pdm-metrics-00.txt=0A=0A=0AA new = version of I-D, draft-elkins-ippm-pdm-metrics-00.txt=0Ahas been successfull= y submitted by Nalini Elkins and posted to the=0AIETF repository.=0A=0AFile= name:=A0 =A0 draft-elkins-ippm-pdm-metrics=0ARevision:=A0 =A0 00=0ATitle:= =A0 =A0 =A0 =A0 IPPM Considerations for the IPv6 PDM Extension Header=0ACre= ation date:=A0 =A0 2013-10-03=0AGroup:=A0 =A0 =A0 =A0 Individual Submission= =0ANumber of pages: 14=0AURL:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/in= ternet-drafts/draft-elkins-ippm-pdm-metrics-00.txt=0AStatus:=A0 =A0 =A0 =A0= =A0 http://datatracker.ietf.org/doc/draft-elkins-ippm-pdm-metrics=0AHtmliz= ed:=A0 =A0 =A0 =A0 http://tools.ietf.org/html/draft-elkins-ippm-pdm-metrics= -00=0A=0A=0AAbstract:=0A=A0 To diagnose performance and connectivity proble= ms, metrics on real=0A=A0 (non-synthetic) transmission are critical for tim= ely end-to-end=0A=A0 problem resolution. Such diagnostics may be real-time = or after the=0A=A0 fact, but must not impact an operational production netw= ork. These=0A=A0 metrics are defined in the IPv6 Performance and Diagnostic= Metrics=0A=A0 Destination Option (PDM). The base metrics are: packet seque= nce=0A=A0 number and packet timestamp. Other metrics may be derived from th= ese=0A=A0 for use in diagnostics.=A0 This document specifies such metrics, = their=0A=A0 calculation, and usage.=0A=0A=0A=0A=0A=0APlease note that it ma= y take a couple of minutes from the time of submission=0Auntil the htmlized= version and diff are available at tools.ietf.org.= =0A=0AThe IETF Secretariat ---1551098171-2085762115-1381844622=:97264 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Al,

Thanks= for your thorough examination and great comments.  My responses are i= nline.   Also, if you have time in Vancouver, Mike & I would like = to ask you to have lunch or dinner on us.   It is the least we can do = for all your help!  Please let us know if you have a free day.


>Early in= the Intro, the various time/number fields are referred to as "base metrics= " themselves.
>I know you'll want to clarify that (they are just fields).

Sure.

>In section 1.2: in addition to time and seq number= for current packet:

 >           &= nbsp;    PSNLR : Packet Sequence Number Last Received
 &g= t;               TSLR  : Timestamp = Last Received

>the device supplying the header appears to need to= maintain flow state to add
>these "last packet" fields. A very stron= g justification is probably needed.
>Later, I see that the Server ho= st essentially has to store the fields across
>request-response pair= s. Lower and higher layers need to work together,
>somehow.

Th= e Destination Options Header is created only by the OS's at the end points.=  That is, the Microsofts, linuxes, and IBM's of the world.  The = OS at the end point already maintains state.   If you think of TCP TimeW= ait status for example.   The connection is in TimeWait status for 2 *= MSL.  So, obviously state is being maintained.  Anyway, all the = OS's have control blocks associated with each active connection.

Now, the= re is going to be some discussion by the OS vendors about non-TCP protocols= !  I have participated in those discussions with IBM in a former life = (when they OEMed a product of mine & I wanted them to do something!) &n= bsp;but I believe that they are persuadable.   I am guessing that this= information is already being maintained.  All we are asking for is fo= r it to be exposed.

Our header is not for middle boxes.  We are not = asking for router, etc. to maintain state in this way.


>In Section 3.1 and 3.2, it's not clear which PDM time-stamps support the (rou= nd-trip delay
>and server delay) metrics. When you look at  RFC2= 681, it should be fairly clear where
>the time stamps are applied, a= nd that needs to carry though here (though I see it later
>in the exa= mple).

I will clarify.

>Looking at the example in section 4, there c= an be a significant delay between when
>the application layer transfe= rs packets to TCP's send buffer and when the packets are
>actually se= nt "on the wire" (as we say in IPPM), which happens after the IP header is<= br>>applied (or most of the header, in some cases). How would accuracy b= e maintained
>across all the different layers?

>Maybe anot= her way to phrase the question is this:
>How does the process that adds the PDM header (with last Seq number 25) know
>which packet to= add it to? 

There are 2 questions here.  First, it will be th= e IP layer adding the times.  Yes, I know that it is a "gross" measure= ment comprising of a number of components.  But, then so is one-way de= lay.  That is,  there are multiple components within the path. &n= bsp; The purpose of our measurements is to allow the diagnostician to do ve= ry quick triage.  That is, to say, is the problem in the network or th= e server?  Then, we hand the problem off to the right group who can ru= nmore detailed diagnostic tests.   

In our experience, this is = a very valuable kind of measurement to have.  A great deal of time, ef= fort and money is spent at large end user sites to determine just this.   Anecdotal evidence tells me that this is true for home users of the= Internet also.   My working life has been spent at large data centers= , so that I can answer to without any hesitation.

> I note that t= here is IPR declared on this draft, and licensing is not clear.

Yes, we d= o have IPR.  I hope I have declared it properly!  Please let me k= now if I have not.  We have not decided on the exact nature of the lic= ensing but it will be very reasonable.  We want the technology adopted= .    There are
more advanced = metrics which can be created from these which is the primary reason for the= IPR.

BTW, we are starting to engage in discussions also with folks looki= ng at a new WG. https://= sites.google.com/site/transportprotocolservices/home/charter-proposal-befor= e-bof
We feel our metrics / header = can help with a unified Simple Congestion Control (SCC) and Inter-Layer Com= munication (ILC).   That is some of our other work.   The above group seems to feel that work would fi= t in with their efforts!  I feel that the fields we propose are simple= yet very powerful.  Many uses can be made of them.   I can tell = you more on this, if you have interest.


______________________= __________________
From: ippm-bounces@ietf.org [ippm-bounces@ietf.org] On Behalf Of Nalini Elkins [nalini.elkins@insidethestack.com]
Sent: Friday, Octobe= r 04, 2013 9:10 AM
To: WG (v6ops@ietf.org); 6man WG; ippm@ietf.org
Cc: Sigfri= do Perdomo; keven.haining@usbank.com; Bill Jouris; Ackerma= nn Michael
Subject: [ippm] Fw: New Version Notification for   =     draft-elkins-ippm-pdm-metrics-00.txt

We have submitte= d a number of drafts.  Some are new and some are updates to our existi= ng PDM proposal.  We would appreciate any comments, questions, and cor= rections from the lists.


The new ones are:

1.  In IPPM:

ht= tp://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt
<= br>This describes the base and derived metrics which can be obtained from t= he IPv6 PDM DO Extension Header.


2.  In TicToc:

http= ://www.ietf.org/internet-drafts/draft-ackermann-tictoc-pdm-ntp-usage-00.txt=

This describes how NTP may be implemented to support PDM.

The updates are as follows

1.  In 6man:

http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-met= rics-00.txt

This is the layout of the PDM DO header.


= 2.  In v6ops:

http://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-= packet-sequence-needed-01.txt

http://www.ietf.org/internet-drafts/dr= aft-elkins-v6ops-ipv6-pdm-recommended-usage-01.txt

http://www.ietf.o= rg/internet-drafts/draft-elkins-v6ops-ipv6-end-to-end-rt-needed-01.txt
<= br>These are background for the proposal.


Thanks,

Nalini = Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

--= --- Forwarded Message -----
From: "internet-drafts@ietf.org= " <internet-drafts@ietf.org>
To: Nalini Elkin= s <nalini.elkins@insidethestack.com>= ; William Jouris <bill.jouris@insidethestack.com>=
Sent: Thursday, October 3, 2013 8:04 PM
Subject: New Version Notific= ation for draft-elkins-ippm-pdm-metrics-00.txt


A new version of = I-D, draft-elkins-ippm-pdm-metrics-00.txt
has been successfully submitte= d by Nalini Elkins and posted to the
IETF repository.

Filename:&n= bsp;   draft-elkins-ippm-pdm-metrics
Revision:    00
T= itle:        IPPM Considerations for the IPv6 PDM Exten= sion Header
Creation date:    2013-10-03
Group:   = ;     Individual Submission
Number of pages: 14
URL:  =           http://www.ietf.org/internet-drafts/draft-elkins-ippm-pd= m-metrics-00.txt
Status:          http://da= tatracker.ietf.org/doc/draft-elkins-ippm-pdm-metrics
Htmlized:  &nb= sp;     http://tools.ietf.org/html/draft-elkins-ip= pm-pdm-metrics-00


Abstract:
  To diagnose performanc= e and connectivity problems, metrics on real
  (non-synthetic) tran= smission are critical for timely end-to-end
  problem resolution. S= uch diagnostics may be real-time or after the
  fact, but must not = impact an operational production network. These
  metrics are defin= ed in the IPv6 Performance and Diagnostic Metrics
  Destination Opt= ion (PDM). The base metrics are: packet sequence
  number and packe= t timestamp. Other metrics may be derived from these
  for use in diagnostics.  This document specifies such metrics, their
  c= alculation, and usage.





Please note that it may take = a couple of minutes from the time of submission
until the htmlized versi= on and diff are available at tools.ietf.org<http://tools.ietf.org/>.

The IETF Se= cretariat




---1551098171-2085762115-1381844622=:97264-- From nalini.elkins@insidethestack.com Tue Oct 15 17:04:02 2013 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 AED2C11E80EE for ; Tue, 15 Oct 2013 17:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+OabCFS6tHF for ; Tue, 15 Oct 2013 17:03:57 -0700 (PDT) Received: from nm21-vm4.access.bullet.mail.bf1.yahoo.com (nm21-vm4.access.bullet.mail.bf1.yahoo.com [216.109.115.131]) by ietfa.amsl.com (Postfix) with ESMTP id 2624511E8227 for ; Tue, 15 Oct 2013 17:03:53 -0700 (PDT) Received: from [66.196.81.159] by nm21.access.bullet.mail.bf1.yahoo.com with NNFMP; 16 Oct 2013 00:03:52 -0000 Received: from [66.196.81.126] by tm5.access.bullet.mail.bf1.yahoo.com with NNFMP; 16 Oct 2013 00:03:52 -0000 Received: from [127.0.0.1] by omp1002.access.mail.bf1.yahoo.com with NNFMP; 16 Oct 2013 00:03:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 182789.13834.bm@omp1002.access.mail.bf1.yahoo.com Received: (qmail 36317 invoked by uid 60001); 16 Oct 2013 00:03:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1381881831; bh=fWEKUkOZgD4Zal9Y72DMSPCZN1A7gGDD7lfajVd7uXk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=3Ef3yP9O5Gz/8k4nbvSgtBgkuArZntlKDruFbXbJ/VIIq1qlYbfxIGIF1mq3FLHp2aR+ECbT5MB3KMd/dJh2KUCX5GXQLmVep7lpVvyzgWwo616kho3JMBUqJFyhqsH9uhGad+FgcT/BlSlq/i5TWxyfJw+7VNSO2pwDa2QWPOk= X-YMail-OSG: jb6qHngVM1nl969yNLWv5KtQkQjGxcJ5ejs9_QcjmP3A0Xt lhGD51BCVMGejBqLHQyyU2eRIuYtV6imrlwMQ9QlmSAcSa3wCK18B00oEAN_ kKfLEXkTsHP28ax1XDO0594jGj_tLocy1eraLz3nogtuKx1cB9VaTymNTaJY 81BFEO7_1U8kTsqDrKWOL6Z46lf92NrOnnHoC7GzXa1Pv3AFxvCIFvNuRz_d QxqAHzXxZesfSAvgKVQTBW4Cl3XgDk2S6ynvf8DhZ2fHWouj0D2IwFZEB6cj uGukI7wceCC3mMwew1hHT8eVM61nMo8buPpvkYVizeFv.v.F55pQfmiR3orN P5HXL_YSfqYM_4_vrfm0TJpyVXHK7RHdKowFmhuq3uYwAEmHIn_7PRlyC9GY BTWjptrJu1VBnYEnfbucr2ZQPfIJMeTO8MrG6U3kgHuGvDR.D82tCNHTXbSL rim0gQA.mGHMIWociBFaY8BJ4J1io0Su8D3xC0edvrTjQ86c1ogXOm1EIYou 5qs2jjC3pPOZ362lw6YJ_qtUDz7kBWxlEMoKEBOweSX1hqe0I4WKYDhrTC2p x6K8Nu4h66CbUOirVtl.3BMP5Z_NKfrcvmAHdTO8V42t8N5O2JGCCJoPHRzt pzBP1V5WqPXeLgqkpZo6ud8npDgqb6e_.kjDt0iw- Received: from [24.130.37.147] by web2801.biz.mail.ne1.yahoo.com via HTTP; Tue, 15 Oct 2013 17:03:51 PDT X-Rocket-MIMEInfo: 002.001, QWxsLAoKSSBoYXZlIHVwZGF0ZWQgdGhlIFBETSBzcGVjaWZpY2F0aW9uIHRvIGFkZCBhIHNlY29uZCBQRE0gdHlwZSB3aGljaCByZXF1aXJlcyBOTyB0aW1lIHN5bmNocm9uaXphdGlvbi4gwqAgVGhlIGRyYWZ0IGZvciBJUFBNIHdoaWNoIGRlc2NyaWJlcyBob3cgdG8gY2FsY3VsYXRlIGFuZCB1c2UgdGhlIHZhbHVlcyBkZXNjcmliZWQgaW4gdGhlIFBETS4gwqAgVGhlIElQUE0gZHJhZnQgaXM6CgpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1lbGtpbnMtaXBwbS1wZG0tbWV0cmljcy0wMQoKCkkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131015235832.2100.62094.idtracker@ietfa.amsl.com> Message-ID: <1381881831.35197.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Date: Tue, 15 Oct 2013 17:03:51 -0700 (PDT) From: Nalini Elkins To: v6ops WG , 6man WG , "ippm@ietf.org" In-Reply-To: <20131015235832.2100.62094.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="36908767-168568284-1381881831=:35197" Subject: [ippm] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-03.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 00:04:02 -0000 --36908767-168568284-1381881831=:35197 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All,=0A=0AI have updated the PDM specification to add a second PDM type whi= ch requires NO time synchronization. =A0 The draft for IPPM which describes= how to calculate and use the values described in the PDM. =A0 The IPPM dra= ft is:=0A=0Ahttp://tools.ietf.org/html/draft-elkins-ippm-pdm-metrics-01=0A= =0A=0AI would appreciate any comments or feedback.=A0=0A=0A=0AA new version= of I-D, draft-elkins-6man-ipv6-pdm-dest-option-03.txt=0Ahas been successfu= lly submitted by Nalini Elkins and posted to the=0AIETF repository.=0A=0AFi= lename:=A0=A0=A0 draft-elkins-6man-ipv6-pdm-dest-option=0ARevision:=A0=A0= =A0 03=0ATitle:=A0=A0=A0 =A0=A0=A0 IPv6 Performance and Diagnostic Metric= s Destination Option=0ACreation date:=A0=A0=A0 2013-10-15=0AGroup:=A0=A0= =A0 =A0=A0=A0 Individual Submission=0ANumber of pages: 18=0AURL:=A0 =A0 = =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-elkins-6man-ipv6= -pdm-dest-option-03.txt=0AStatus:=A0 =A0 =A0 =A0 =A0 http://datatracker.iet= f.org/doc/draft-elkins-6man-ipv6-pdm-dest-option=0AHtmlized:=A0 =A0 =A0 =A0= http://tools.ietf.org/html/draft-elkins-6man-ipv6-pdm-dest-option-03=0ADif= f:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/rfcdiff?url2=3Ddraft-elkins-6= man-ipv6-pdm-dest-option-03=0A=0AAbstract:=0A=A0 To diagnose performance a= nd connectivity problems, metrics on real=0A=A0 (non-synthetic) transmissi= on are critical for timely end-to-end=0A=A0 problem resolution. Such diagn= ostics may be real-time or after the=0A=A0 fact, but must not impact an op= erational production network. The base=0A=A0 metrics are: packet sequence = number and packet timestamp.=A0 Metrics=0A=A0 derived from these will be d= escribed separately. This document solves=0A=A0 these problems with a new = destination option, the Performance and=0A=A0 Diagnostic Metrics destinati= on option (PDM).=0A=0A=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A=0A=0APlease note that it may t= ake a couple of minutes from the time of submission=0Auntil the htmlized ve= rsion and diff are available at tools.ietf.org.=0A=0AThe IETF Secretariat --36908767-168568284-1381881831=:35197 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
All,
<= br>
I have updated the PDM specification to add a second PDM= type which requires NO time synchronization.   The draft for IPPM whi= ch describes how to calculate and use the values described in the PDM. &nbs= p; The IPPM draft is:


I would ap= preciate any comments or feedback. 

=0A
A new version of I-D, draft-elkins-6man-ipv6-pdm-dest-opt= ion-03.txt
has been successfully submitted by Nalini Elkins and posted t= o the
IETF repository.

Filename:    draft-elkins-= 6man-ipv6-pdm-dest-option
Revision:    03
Title: = ;       IPv6 Performance and Diagnostic Metrics D= estination Option
Creation date:    2013-10-15
Group:=         Individual Submission
Number of p= ages: 18
URL:            http://www.ietf.= org/internet-drafts/draft-elkins-6man-ipv6-pdm-dest-option-03.txt
Status= :          http://datatracker.ietf.org/doc/draft-e= lkins-6man-ipv6-pdm-dest-option
Htmlized:        htt= p://tools.ietf.org/html/draft-elkins-6man-ipv6-pdm-dest-option-03
Diff:&= nbsp;           http://www.ietf.org/rfcdiff?url2=3Ddraft-elkins-6man-ipv6-pdm-dest-option-= 03

Abstract:
  To diagnose performance and connectivity pro= blems, metrics on real
  (non-synthetic) transmission are critical= for timely end-to-end
  problem resolution. Such diagnostics may = be real-time or after the
  fact, but must not impact an operation= al production network. The base
  metrics are: packet sequence num= ber and packet timestamp.  Metrics
  derived from these will = be described separately. This document solves
  these problems wit= h a new destination option, the Performance and
  Diagnostic Metri= cs destination option (PDM).


          =                      = ;                     &nb= sp;                            


Please note that it may tak= e a couple of minutes from the time of submission
until the htmlized ver= sion and diff are available at tools.ietf.org.

The IETF Secretariat



--36908767-168568284-1381881831=:35197-- From internet-drafts@ietf.org Wed Oct 16 01:51:27 2013 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 087B711E8167; Wed, 16 Oct 2013 01:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4lNc54yMqid; Wed, 16 Oct 2013 01:51:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3476F11E8176; Wed, 16 Oct 2013 01:51:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131016085125.32193.95509.idtracker@ietfa.amsl.com> Date: Wed, 16 Oct 2013 01:51:25 -0700 Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-2330-update-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 08:51:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group of t= he IETF. Title : Advanced Stream and Sampling Framework for IPPM Author(s) : Joachim Fabini Al Morton Filename : draft-ietf-ippm-2330-update-01.txt Pages : 15 Date : 2013-10-16 Abstract: To obtain repeatable results in modern networks, test descriptions need an expanded stream parameter framework that also augments aspects specified as Type-P for test packets. This memo proposes to update the IP Performance Metrics (IPPM) Framework with advanced considerations for measurement methodology and testing. The existing framework mostly assumes deterministic connectivity, and that a single test stream will represent the characteristics of the path when it is aggregated with other flows. Networks have evolved and test stream descriptions must evolve with them, otherwise unexpected network features may dominate the measured performance. This memo describes new stream parameters for both network characterization and support of application design using IPPM metrics. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-2330-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-2330-update-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-2330-update-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trammell@tik.ee.ethz.ch Wed Oct 16 02:52:13 2013 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 00CF511E8289 for ; Wed, 16 Oct 2013 02:52:13 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVSeYppsTOkf for ; Wed, 16 Oct 2013 02:52:08 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBCD11E81B6 for ; Wed, 16 Oct 2013 02:52:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A6F71D9302 for ; Wed, 16 Oct 2013 11:52:02 +0200 (MEST) 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 NcplLSZbRxyK for ; Wed, 16 Oct 2013 11:52:02 +0200 (MEST) Received: from public-docking-pat-hg-3474.ethz.ch (public-docking-pat-hg-3474.ethz.ch [10.2.45.148]) (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 49493D9300 for ; Wed, 16 Oct 2013 11:52:02 +0200 (MEST) From: Brian Trammell Content-Type: multipart/signed; boundary="Apple-Mail=_BDE44AFD-6C4C-47BB-9F83-C0247CE3B3FD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 16 Oct 2013 11:52:00 +0200 References: <20131015205017.2154.97466.idtracker@ietfa.amsl.com> To: "ippm@ietf.org" Message-Id: <9D5BD7A6-9CC1-4A62-90C6-3A44E1AF350C@tik.ee.ethz.ch> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [ippm] Fwd: New Liaison Statement, "Performance Measurement Liaison Response to Broadband Forum" 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, 16 Oct 2013 09:52:13 -0000 --Apple-Mail=_BDE44AFD-6C4C-47BB-9F83-C0247CE3B3FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Greetings, all, The liaison response to BBF re: large-scale performance measurement has = been sent; see forwarded message below. Best regards, Brian Begin forwarded message: > From: Liaison Statement Management Tool > Subject: New Liaison Statement, "Performance Measurement Liaison = Response to Broadband Forum" > Date: 15 October 2013 22:50:17 GMT+02:00 > To: Christophe Alter > Cc: Jason Weil , Brian Trammell = , Bill Cerveny , Ray Bellis = , Mark Townsley , Sarah = Banks , Al Morton , Gonzalo = Camarillo , Dan Romascanu = , Christophe Alter Technical Committee Chair = Broadband Forum , Benoit Claise = , Joel Jaeggli , David Sinicrope = IETF/Broadband Forum Liaison Manager , = Ross Callon , Jari Arkko IETF Chair = , Robin Mersh Broadband Forum CEO = , Gabrielle Bingham Broadband Forum = Secretariat , Jason Walls Broadband Home = Working Group Co-Chair , John Blackford Broadband Home = Working Group Co-Chair , Dave Thorne Broadband = Forum E2E Architecture WG Chair , Dave Allan = Broadband Forum E2E Architecture WG Chair , = Sven Ooghe Broadband Forum E2E Architecture WG Vice Chair = , Peter Adams Broadband Forum Operations = and Network Management WG Chair , Jason Weil = , David Sinicrope >=20 > Title: Performance Measurement Liaison Response to Broadband Forum > Submission Date: 2013-10-15 > URL of the IETF Web page: http://datatracker.ietf.org/liaison/1286/ >=20 > From: The IETF (Jari Arkko >) > To: Broadband Forum (Christophe Alter ) > Cc: Jason Weil ,Brian Trammell = ,Bill Cerveny ,Ray Bellis = ,Mark Townsley ,Sarah = Banks ,Al Morton ,Gonzalo = Camarillo ,Dan Romascanu = ,Christophe Alter Technical Committee Chair = Broadband Forum ,Benoit Claise = ,Joel Jaeggli ,David Sinicrope = IETF/Broadband Forum Liaison Manager ,Ross = Callon ,Jari Arkko IETF Chair = ,Robin Mersh Broadband Forum CEO = ,Gabrielle Bingham Broadband Forum = Secretariat ,Jason Walls Broadband Home = Working Group Co-Chair ,John Blackford Broadband Home = Working Group Co-Chair ,Dave Thorne Broadband = Forum E2E Architecture WG Chair ,Dave Allan = Broadband Forum E2E Architecture WG Chair = ,Sven Ooghe Broadband Forum E2E Architecture = WG Vice Chair ,Peter Adams Broadband = Forum Operations and Network Management WG Chair = > Reponse Contact: David Sinicrope > Technical Contact: Jason Weil > Purpose: In response >=20 > Body: Date: October 15, 2013 >=20 > To:=20 > Christophe Alter, Technical Committee Chair, Broadband Forum = (christophe.alter@orange.com) >=20 > From:=20 > Dan Romascanu, IETF Large-Scale Measurement of Broadband Performance = WG Chair (dromasca@avaya.com) > Jason Weil, IETF Large-Scale Measurement of Broadband Performance WG = Chair (jason.weil@twcable.com) > Brian Trammell, IETF IP Performance Metrics WG Chair = (trammell@tik.ee.ethz.ch) > Bill Cerveny, IETF IP Performance Metrics WG Chair = (bill@wjcerveny.com) > Ray Bellis, IETF Home Networking WG Chair (ray.bellis@nominet.org.uk) > Mark Townsley, IETF Home Networking WG Chair (mark@townsley.net) > Sarah Banks, IETF Benchmarking Methodology WG Chair = (sbanks@aerohive.com) > Al Morton, IETF Benchmarking Methodology WG Chair (acmorton@att.com) >=20 > CC: > David Sinicrope, IETF/Broadband Forum Liaison Manager = (david.sinicrope@ericsson.com) > Ross Callon, IETF Internet Architecture Board (rcallon@juniper.net) > Jari Arkko, IETF Chair (jari.arkko@piuha.net) > Robin Mersh, Broadband Forum CEO (rmersh@broadband-forum.org) > Gabrielle Bingham, Broadband Forum Secretariat = (gbingham@broadband-forum.org) > Jason Walls, Broadband Home Working Group Co-Chair (jason@qacafe.com) > John Blackford, Broadband Home Working Group Co-Chair = (john.blackford@pace.com) > Dave Thorne, Broadband Forum E2E Architecture WG Chair = (david.j.thorne@bt.com) > Dave Allan, Broadband Forum E2E Architecture WG Chair = (david.i.allan@ericsson.com) > Sven Ooghe, Broadband Forum E2E Architecture WG Vice Chair = (sven.ooghe@alcatel-lucent.com) > Peter Adams, Broadband Forum Operations and Network Management WG = Chair (peter.adams@adtran.com)=20 >=20 >=20 >=20 > Thank-you for your liaisons listed below and keeping the IETF in mind = while developing work work on Broadband Forumv(BBF) WT-304 Broadband = Access Service Attributes and Performance Metrics. =20 >=20 > BBF Liaisons to date: > Mar 2013 - https://datatracker.ietf.org/liaison/1243/ to IETF Chair = and IESG > Dec 2012 - https://datatracker.ietf.org/liaison/1221/ to IPPM chairs = and Transport and Ops ADs > Sep 2012 - https://datatracker.ietf.org/liaison/1185/ to IETF Chair = and IESG > Aug 2012 - https://datatracker.ietf.org/liaison/1179/ to Ops Area = Directors >=20 >=20 > Thank you also for your patience. While there has been significant = interest in large-scale measurement of Broadband performance, formal = IETF working groups to address major components of this topic had not = been chartered until this summer. Now that the IPPM WG has been = re-chartered (to consider measurement methods appropriate for = large-scale measurements) and the LMAP WG formed (to consider the = architectural framework and operational components), both groups look = forward to communicating with the BBF on this subject. >=20 > In addition to LMAP and IPPM, you may also want to consider BMWG and = Homenet for some of your WT-304 efforts. Please see the links below for = all of these working groups=92 charters, scope and work plans. >=20 > LMAP (Ops and Mgmt Area) - = https://datatracker.ietf.org/wg/lmap/charter/=20 > IPPM (Transport Area) - https://datatracker.ietf.org/wg/ippm/charter/=20= > BMWG (Ops and Mgmt Area) - = https://datatracker.ietf.org/wg/bmwg/charter/=20 > HomeNet (Internet Area) - = https://datatracker.ietf.org/wg/homenet/charter/=20 >=20 > We note that you would like to reference IETF protocols and work to = satisfy the requirements of your architecture. We believe this is a = good division of work and scope and would be happy to cooperate along = these lines. We encourage specific communication with each of the = individual working groups via their Chairs along the lines of their = charters. For topics that cross one or more WGs, please address the = liaison to the Chairs of all of the relevant working groups and the = liaison manager from the IETF who will help direct the liaison to the = appropriate WG or IETF authority. >=20 > The LMAP WG is reviewing your March 2013 Liaison and notes the = following requests for information: > Feedback on the use of SIP to provide an inter and intra domain = mechanism to probe test target resource availability.=20 > Comments on the use of DNS-SD(RFC6763) and mDNS (RFC6762) to support = BBF's service attribute communication. =20 > Information model development for test and report parameters=20 >=20 > LMAP WG Response: >=20 > The LMAP WG was formed in June and held its first meeting in July of = this year. Following the goals and milestones as outlined in the WG = Charter that can be found in the above link, the WG will be focussed on = finalizing Use Case and Framework documents and then beginning work on = the Information Model document. The Information Model was mentioned as = an area of interest by the BBF in the March Liaison. The LMAP WG would = welcome input from the BBF as it begins work on the Information Model = document. For reference, the Informational Model scope as described in = the LMAP WG Charter is included for reference:=20 > Information Model, the abstract definition of the information carried = from the Controller to the MA and the information carried from the MA to = the Collector. It includes > * The metric(s) that can be measured and values for its parameters = such as the Peer MA participating in the measurement and the desired = environmental conditions (for example, only conduct the measurement when = there is no user traffic observed) > * The schedule: when the measurement should be run and how the = results should be reported (when and to which Collector) > * The report: the metric(s) measured and when, the actual result, = and supporting metadata such as location. Result reports may be = organized in batches or may be reported immediately, such as for an = on-demand measurement. > In regards to interest of using DNS-SD and mDNS in support of service = attribute communication between devices within the home network, the = LMAP WG would defer this question and possible further analysis to work = that is taking place in the Homenet WG. It should be noted that = currently the mDNS Protocol is constrained to a single link based on its = use of link-local multicast. If the BBF would be interested in the use = of mDNS and DNS-SD in a multi-segmented home network, this would require = new work to those protocols that is being discussed as part of a new = Working Group. Discussion of that WG charter language is currently = taking place. >=20 > In regards to the use of SIP as a inter-domain and/or intra-domain = mechanism for the discovery of test target (Measurement Peer in LMAP = terminology) availability, this point represents communication that = would take place between a Measurement Agent and a Measurement Peer. = Communication requirements as part of a test between a MA and its = measurement target (Measurement Peer) is currently not included as one = of the work items per the LMAP charter but may be a topic of discussion = for future work. >=20 > IPPM WG Response: =20 >=20 > Please be advised that the IPPM WG has considered updates to RFC 2680 = and 2681 in their March 2013 rechartering, but these have been deferred = until it is clear what impact the effort to update the framework (2330) = and the effort to define a registry on the March 2013 charter will have = on these updates. IPPM expects that the result will be compatible with = 2680 and 2681, and as such developments based on these RFCs may continue = as they are. >=20 > Many of the issues with 3148 raised in Question 1 of the December 2012 = BBF liaison may be addressed by draft-ietf-ippm-model-based-metrics-00, = on which work is progressing under their current charter; discussion of = issues with bulk capacity measurement not addressed therein is welcome = on the ippm@ietf.org mailing list. >=20 > With respect to the remaining outstanding questions, the IPPM WG will = take them as information that BBF is considering the use of 3393 and = 6349 as well; IPPM is not considering updates to these at this time, so = they remain a stable basis for further work, noting again in the latter = case that draft-ietf-ippm-model-based-metrics-00 aims to address issues = in using TCP to measure TCP bulk transfer capacity. >=20 > IPPM understands from Question 6 that 'moving up the stack', looking = specifically at VoIP, streaming video, and DNS resolution time, are of = interest to BBF. IPPM is not currently working on metrics in this area, = but would certainly consider contributions thereon under its current = charter, and have reviewed at least one individual draft on buffered = streaming video performance during the chartering discussions in March = 2013. >=20 > As for the general line of these questions (especially 6), please note = the ongoing registry effort on the IPPM charter. There are three = individual drafts: draft-bagnulo-ippm-new-registry, = draft-bagnulo-ippm-new-registry-independent, and = draft-claise-ippm-perf-metric-registry. The authors are currently = working on a unified approach to a performance metrics registry, with = the intention that the outcome be adopted for further development within = the IPPM WG. This registry will be populated with recommended metrics = for LMAP use cases, which would represent a consensus statement from = IPPM on the metrics IPPM consider useful in this area. Work in this area = is ongoing, and we welcome commentary on the ippm@ietf.org list once the = unified registry document is published. >=20 > We noted that there might be interest in the identification of test = reference points. This is currently on the IPPM WG charter and we now = have an initial working group document = (http://datatracker.ietf.org/doc/draft-ietf-ippm-lmap-path).=20 >=20 > The IETF encourages those in the BBF who are interested in this IETF = work, to participate and help drive the work via the relevant IETF WG = email lists noted above and the IETF development processes. While = formal liaison communication is necessary and beneficial, direct, active = participation by interested parties is very helpful and complementary to = drive the deliverables needed between the organizations. Please note = that access to all relevant IETF working groups, email lists, documents = and process is open so than any interested party may participate and = contribute. >=20 > Likewise, the IETF would be happy to provide input and feedback on BBF = related work. We understand the BBF is a membership organization and = may restrict access to its relevant works in progress. To facilitate = cooperation with the IETF, please liaise any work in progress you would = like the IETF to consider, review, comment on, collaborate on, etc., = with the understanding that access to the liaison and its attachments = will be open and not be restricted or limited to BBF membership. >=20 > Sincerely,=20 > LMAP, IPPM, Homenet and BMWG Chairs > Attachments: >=20 > No document has been attached --Apple-Mail=_BDE44AFD-6C4C-47BB-9F83-C0247CE3B3FD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSXmHAAAoJENt3nsOmbNJcZvEIAIOJEG0tjEwN6IdnJ4f8QEF3 fDlKI9imTVb3h7iP+dVK0fiK8AZH5y22wwwLPmkPf3wLei5Jazutzk9eokhRL3XB yrs+k89fc8aoLoxrpY7hgsSVxLUjI2kqoh/gOW7Xheaxkx75ZS3T3q3f59kxEKoy amhcPsEsU8rl+jOfUDrCNQ54iFHW1hJdkcFX8iuMZiz3AYm5ZLoqf1nbv5mve3Bq kiSloOdgSyPnCltYRw1+xZ5pVI/dobgApKE3CMDTxR6yaRgpjn0eUQYV5T1uvFy5 N92ghcgTIMyYO0OVWC1weOzK2GTXtC109SOIaAlgIvw+f5PN0s67kpFtTEQJ97U= =nt2n -----END PGP SIGNATURE----- --Apple-Mail=_BDE44AFD-6C4C-47BB-9F83-C0247CE3B3FD-- From Joachim.Fabini@tuwien.ac.at Wed Oct 16 04:43:10 2013 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 CC27321F9D99 for ; Wed, 16 Oct 2013 04:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.43 X-Spam-Level: X-Spam-Status: No, score=-5.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBlccK4vVBAJ for ; Wed, 16 Oct 2013 04:43:06 -0700 (PDT) Received: from mail1.zserv.tuwien.ac.at (mail1.zserv.tuwien.ac.at [128.130.35.37]) by ietfa.amsl.com (Postfix) with ESMTP id CA1ED21F9D89 for ; Wed, 16 Oct 2013 04:43:04 -0700 (PDT) Received: from [128.131.88.241] (priamos.ibk.tuwien.ac.at [128.131.88.241]) (authenticated bits=0) by mail1.zserv.tuwien.ac.at (8.13.8/8.13.8) with ESMTP id r9GBgxeq003773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Oct 2013 13:42:59 +0200 Message-ID: <525E7BBC.3080908@tuwien.ac.at> Date: Wed, 16 Oct 2013 13:42:52 +0200 From: Joachim Fabini User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: ippm@ietf.org References: <20131016085126.32193.86782.idtracker@ietfa.amsl.com> In-Reply-To: <20131016085126.32193.86782.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131016085126.32193.86782.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Al Morton Subject: [ippm] Fwd: New Version Notification for draft-ietf-ippm-2330-update-01.txt 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, 16 Oct 2013 11:43:10 -0000 Dear IPPM group, an updated version of the RFC2330-update draft is now available at http://datatracker.ietf.org/doc/draft-ietf-ippm-2330-update/. Al and me have integrated Kostas' comments from Berlin (thanks again Kostas for your input). We have re-structured the document and extended it with focus on metric and methodology criteria (new section 4). The new structure includes additional requirements/criteria raised by Matt's model based metrics draft. We welcome any reviews/comments/input. regards Al and Joachim -------- Original-Nachricht -------- Betreff: New Version Notification for draft-ietf-ippm-2330-update-01.txt Datum: Wed, 16 Oct 2013 01:51:26 -0700 Von: internet-drafts@ietf.org An: Joachim Fabini , Al Morton , "Al C. Morton" A new version of I-D, draft-ietf-ippm-2330-update-01.txt has been successfully submitted by Joachim Fabini and posted to the IETF repository. Filename: draft-ietf-ippm-2330-update Revision: 01 Title: Advanced Stream and Sampling Framework for IPPM Creation date: 2013-10-15 Group: ippm Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-ietf-ippm-2330-update-01.txt Status: http://datatracker.ietf.org/doc/draft-ietf-ippm-2330-update Htmlized: http://tools.ietf.org/html/draft-ietf-ippm-2330-update-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-2330-update-01 Abstract: To obtain repeatable results in modern networks, test descriptions need an expanded stream parameter framework that also augments aspects specified as Type-P for test packets. This memo proposes to update the IP Performance Metrics (IPPM) Framework with advanced considerations for measurement methodology and testing. The existing framework mostly assumes deterministic connectivity, and that a single test stream will represent the characteristics of the path when it is aggregated with other flows. Networks have evolved and test stream descriptions must evolve with them, otherwise unexpected network features may dominate the measured performance. This memo describes new stream parameters for both network characterization and support of application design using IPPM metrics. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nalini.elkins@insidethestack.com Wed Oct 16 06:41:22 2013 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 883A911E81DF for ; Wed, 16 Oct 2013 06:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duuF8brPs5O3 for ; Wed, 16 Oct 2013 06:41:22 -0700 (PDT) Received: from nm26-vm10.access.bullet.mail.bf1.yahoo.com (nm26-vm10.access.bullet.mail.bf1.yahoo.com [216.109.115.217]) by ietfa.amsl.com (Postfix) with ESMTP id 290D211E826F for ; Wed, 16 Oct 2013 06:41:10 -0700 (PDT) Received: from [66.196.81.155] by nm26.access.bullet.mail.bf1.yahoo.com with NNFMP; 16 Oct 2013 13:41:09 -0000 Received: from [66.196.81.148] by tm1.access.bullet.mail.bf1.yahoo.com with NNFMP; 16 Oct 2013 13:41:09 -0000 Received: from [127.0.0.1] by omp1024.access.mail.bf1.yahoo.com with NNFMP; 16 Oct 2013 13:41:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 690100.97728.bm@omp1024.access.mail.bf1.yahoo.com Received: (qmail 81911 invoked by uid 60001); 16 Oct 2013 13:41:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1381930868; bh=PXTBaoBK2gyima4oe58XWR+6cc4gjXMt/q5XMgvfHWs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Y8wXcmn5ZATyCGplafZEXFiPGCxQHyU5RSh5zRMZho0PkTCinAbUgTBm81VmruPaZpcKhMa+qCwcAcSF68el9XAo6DQLHLwwmeDxL8ZLFzZgRL91QVyFUQTG9ityzMhHVITCDpRWp5kL985qakkFZZe5bHacY2TIB3YeQYQ/ypQ= X-YMail-OSG: yPUi0tUVM1nlfy5zZ0Nqz5jVRtwJgJtxrCo7gdr_VOL5hq1 uiuJpgWHYYDs9AVZkxCZN0anvtPYDvG_mS_bMckAVgAuWOWZ3at5Jw5T8_Ll JpM8u8Mw7zXBm_WjFCkEfmkEIZOqRMTEoFtFpvuMxdMqEvhpORuZT27QRng2 rjCpiEAFa7tqZ.YdqvORIBmiVW.zsIiCW1I3MBNP2UcAU1UqtW4hBeCJz2rl mcyskhosTxLvuExgrl_GR4uvz4kAMIh5MntAGtAqQVdg.t4r0NDqnnbAI6f. OpoUgmpwnRFFH67UM.KiQW23eiwrC0LfmcfCVmVllYFGH22fXpzlBc97yrMj khH0TpRtLkah_STBDH5sRDy_ZizHvRZTvqwlz6aIFnp_pQv2zVWKxqzSLWna KCDLAVOmqbv7QV0BOmVbxfs3iEDNWr1h_3kkMr08nrFDOX0Cg8EVe.p4muHU 86p3pkOvhhVQxbyPs6cavM0Q_u.19_9qrJRquyta3EhIrg7MuHAoYKyUSVWO VQX7MsUuIPbuDaCI6.FHtbreCs1WZKUyybA5tC3fYEX8zEgwLtUcbMCngId0 f98uO3uTofRiqelam__tVz0U4kkBzwpJCIjF.4A-- Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Wed, 16 Oct 2013 06:41:08 PDT X-Rocket-MIMEInfo: 002.001, PiBJIGhhdmUgcmVhZCB0aGlzIGRyYWZ0LgoKPkFsbCBpbiBhbGwgaXQgc2VlbXMgcmF0aGVyIHNpbXBsaXN0aWMsIGFuZCBJIGNhbid0IGhlbHAgdGhpbmtpbmcgdGhhdAo.dGhlcmUncyBtdWNoIG1vcmUgdG8gdGhpcyB0aGFuIGlzIGV4cHJlc3NlZCBpbiB0aGUgZHJhZnQuCgpZZXMuIMKgVGhlcmUgaXMuIMKgU2VlIGJlbG93LgoKPkZvciBleGFtcGxlLCB0aGUgc2VydmVyIHRpbWUgY2FsY3VsYXRpb24gc2VlbXMgdG8gYXNzdW1lIHRoYXQgYSByZXNwb25zZQo.cGFja2V0IGhhcyB0byBiZSBzZW50IGltbWUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131015235832.2100.62094.idtracker@ietfa.amsl.com> <1381881831.35197.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <525E9152.60209@globis.net> Message-ID: <1381930868.81291.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Wed, 16 Oct 2013 06:41:08 -0700 (PDT) From: Nalini Elkins To: Ray Hunter In-Reply-To: <525E9152.60209@globis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [ippm] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-03.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 13:41:22 -0000 > I have read this draft.=0A=0A>All in all it seems rather simplistic, and = I can't help thinking that=0A>there's much more to this than is expressed i= n the draft.=0A=0AYes. =C2=A0There is. =C2=A0See below.=0A=0A>For example, = the server time calculation seems to assume that a response=0A>packet has t= o be sent immediately by every application as soon as data=0A>has been proc= essed: every response requires a response.=0A=0ANot at all.=0A=0A>What addi= tional processing is required to cater for cases where the=0A>sender and th= e receiver simply have nothing to say to each other at that=0A>point in tim= e?=0A=0AFrankly, other than keep-alives, I have not seen this. =C2=A0Please= correct me if I am wrong.=0A=0AThe logic for processing and making 'sense'= of these metrics is much more complex than the fields to be sent. =C2=A0Th= is is as it should be. =C2=A0 The OS needs to send packets quickly. =C2=A0A= fter the fact, we can take our time and do analysis.=0A=0AWhat needs to be = handled (at a minimum) are the following cases. =C2=A0You may have more.=0A= =0A1. =C2=A0 Host clocks=C2=A0not synchronized - done=0A2. =C2=A0 IP fragme= ntation=C2=A0=0A3. =C2=A0 Multiple=C2=A0sends from one side (multiple segme= nts)=C2=A0=0A4. =C2=A0=C2=A0Out=C2=A0of order segments (PSN will go negativ= e)=0A5. =C2=A0=C2=A0Retransmits=C2=A0(PSN will go negative)=0A6. =C2=A0 One= =E2=80=93way transmit only (ex. FTP) =C2=A0(server delta will continually i= ncrease)=0A7 =C2=A0 =C2=A0Delayed acks=0A8. =C2=A0 ACKs preceeding send for= another reason=0A9 =C2=A0 =C2=A0Proxy servers=0A10. Full=C2=A0duplex traff= ic=0A11. Keep alive (0 / 1 byte segments, larger segments)=0A12. No respons= e from other side (your case - which I believe to fall under Keep Alives) = =C2=A0=0A,=0A=0AI have only provided the most basic case in this draft. =C2= =A0 But, have thought a great deal about these others and how they would be= handled. =C2=A0I can provide packet flows for all these above to let you k= now how these can be handled. =C2=A0Again, if you have more cases, I welcom= e your input.=0A=0AAdditionally, I am in no way suggesting that this be the= ONLY metric that is used to calculate errors or performance. =C2=A0For exa= mple, =C2=A0if you look at my definition of the "Retransmit Duplication" me= tric, you will see that TCP sequence number is used in addition to the Pack= et Sequence Number to good effect.=C2=A0=0A=C2=A0=0A=C2=A0=0ARegards,=0ARay= H From nalini.elkins@insidethestack.com Wed Oct 16 07:28:03 2013 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 423F011E82B0 for ; Wed, 16 Oct 2013 07:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhnlRwRxqQAF for ; Wed, 16 Oct 2013 07:27:56 -0700 (PDT) Received: from nm5-vm4.access.bullet.mail.gq1.yahoo.com (nm5-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1C87311E81DB for ; Wed, 16 Oct 2013 07:27:56 -0700 (PDT) Received: from [216.39.60.165] by nm5.access.bullet.mail.gq1.yahoo.com with NNFMP; 16 Oct 2013 14:27:55 -0000 Received: from [216.39.60.241] by tm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 16 Oct 2013 14:27:55 -0000 Received: from [127.0.0.1] by omp1012.access.mail.gq1.yahoo.com with NNFMP; 16 Oct 2013 14:27:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 457644.41562.bm@omp1012.access.mail.gq1.yahoo.com Received: (qmail 16838 invoked by uid 60001); 16 Oct 2013 14:27:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1381933675; bh=vyXxIzfBO5pxgoDZyas51ZQJGK5zOWp8DDcQs6NzN9E=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OvJMIay+Lsv/T9vmYTrMqx759OxrWSXupHh3M0w7p1OHKjMrpkjDf28l0AqCzI3Btkd3++I5YugAGB8tU4bmbSJdUpXXsiLyNbohPylT+pLaOWgmMKPdRHwTCBqJP5b2udyzUinxrPDmIiE+IvCLZO3XfG33KSyS0v5gKx++PkM= X-YMail-OSG: hY5N5ykVM1mHmqJizrmjHCT4oNTk7BAoILWiQ9ltii1GVqr SlP_EdbfG6it6nleU6mGYTwTpIJFmlZopS.oOGeNTKDG625v9m5v2k1ia4dp 7ilhmU69MZ_lx_CHfc2svhwOF4w2t7YrU.TTgvalckqrAtuNUO479gdJ2GjV tBgSgwmdT1SQIC1q1._qLl09PdwfWRBs.kXPgPWcZ.od6a0VhfcxIwoVt51t iSgJ7p9pFF3xJbfy5O2nIxnKOtsm_ofjd3v.h1LuPQ2AaVtbD9AGsnF7iIgY rfqxH5d9iDm.xpCfqFWpI8KnoqiHg.B6uLjIIpNnt2PBuKFKIzpYwpqwdNc9 E640KTnXK1GhpzCza1vAbdSuznLiHnm3OUiuAAtjB5qwVFr_5PJdo7QB8BMj mMzwuOT.CNZt3fg4MCEUlEZzS5jphERZphOaY9Z9jfT2aiYC2ayuhCYj1Slg QYEbwyksTCtd6HDxvbtPoZ7TXVPkZi3qPoe.mkH9zZrFvD0600yWkXvbw5Iv LIOP4SYoF3Pn067qyRUINLQcq6rRbg54OjDAUMGOM17_r4HF6Ua9LQfL_MPa 0Px24YjF67TSw0a8x_C4F3dhdlw8PmRTlMln0dw-- Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Wed, 16 Oct 2013 07:27:55 PDT X-Rocket-MIMEInfo: 002.001, UmF5LAoKVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBjb21tZW50cyBhbmQgeW91ciBncmVhdCB1c2UgY2FzZXMuCsKgCj4.PiBJIGhhdmUgcmVhZCB0aGlzIGRyYWZ0LgoKPj4KPj4.IEFsbCBpbiBhbGwgaXQgc2VlbXMgcmF0aGVyIHNpbXBsaXN0aWMsIGFuZCBJIGNhbid0IGhlbHAgdGhpbmtpbmcgdGhhdAo.Pj4gdGhlcmUncyBtdWNoIG1vcmUgdG8gdGhpcyB0aGFuIGlzIGV4cHJlc3NlZCBpbiB0aGUgZHJhZnQuCj4.Cj4.IFllcy7CoCBUaGVyZSBpcy7CoCBTZWUgYmVsb3cuCgo.wqBUaGVuIEkgd28BMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131015235832.2100.62094.idtracker@ietfa.amsl.com> <1381881831.35197.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <525E9152.60209@globis.net> <1381930868.81291.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <525E9F3F.2020600@globis.net> Message-ID: <1381933675.16692.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Wed, 16 Oct 2013 07:27:55 -0700 (PDT) From: Nalini Elkins To: Ray Hunter In-Reply-To: <525E9F3F.2020600@globis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [ippm] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-03.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 14:28:03 -0000 Ray,=0A=0AThank you very much for your comments and your great use cases.= =0A=A0=0A>>> I have read this draft.=0A=0A>>=0A>>> All in all it seems rath= er simplistic, and I can't help thinking that=0A>>> there's much more to th= is than is expressed in the draft.=0A>>=0A>> Yes.=A0 There is.=A0 See below= .=0A=0A>=A0Then I would humbly suggest that you consider keeping this as a = clean=0A>standards track draft just defining the message formats for the=0A= >transport (in 6man WG) =3D Section 1 & 2, and leave the use cases,=0A>arch= itecture, and calculations to other informational drafts (e.g. in=0A>ippm) = =3D Section 3,4. c.f. SNMP=0A=A0=0AI will do this and provide an updated ve= rsion of both IPPM and 6Man documents by end of day today. =A0I will also a= dd use cases to the IPPM document.=0A=0AIf any others have use cases or com= ments, I would very much appreciate hearing from you.=0A=0AThanks,=0ANalini From acmorton@att.com Wed Oct 16 10:32:59 2013 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 AC79421F99F3 for ; Wed, 16 Oct 2013 10:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjxOgUbG+g5k for ; Wed, 16 Oct 2013 10:32:48 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id AAAB411E8192 for ; Wed, 16 Oct 2013 10:32:44 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id D573F122BDE; Wed, 16 Oct 2013 13:27:25 -0400 (EDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by mail-azure.research.att.com (Postfix) with ESMTP id E1E55E3023; Wed, 16 Oct 2013 13:27:24 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-blue.research.att.com (Postfix) with ESMTP id 96F88F218F; Mon, 14 Oct 2013 11:53:42 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::a44a:8177:9a5d:ac00%15]) with mapi; Mon, 14 Oct 2013 11:53:29 -0400 From: "MORTON, ALFRED C (AL)" To: William Cerveny , "ippm@ietf.org" Date: Mon, 14 Oct 2013 11:53:28 -0400 Thread-Topic: [ippm] My comments on draft-ietf-ippm-testplan-rfc2680-03 Thread-Index: Ac7I4T2RGPu4C1KcRSStVresHGheywAEbL9g Message-ID: <2845723087023D4CB5114223779FA9C8AB1BE3EF@njfpsrvexg8.research.att.com> References: <1381757286.8567.33770121.08E74A73@webmail.messagingengine.com> In-Reply-To: <1381757286.8567.33770121.08E74A73@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ippm] My comments on draft-ietf-ippm-testplan-rfc2680-03 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, 16 Oct 2013 17:32:59 -0000 Thanks for your comments, Bill. please see brief replies below, Al > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > William Cerveny > Sent: Monday, October 14, 2013 9:28 AM > To: ippm@ietf.org > Subject: [ippm] My comments on draft-ietf-ippm-testplan-rfc2680-03 >=20 > [Not sure if I need to say that my comments are with my IPPM co-chair > hat off, but if yes, I'm saying it :-) ] >=20 > Ann Cerveny and I are sending more detailed comments and suggestions > (mostly grammatical) directly to the authors, but my most significant > comments on the draft are: >=20 > 1) For "One-way Loss, ADK Sample Comparison", there is a sentence that > starts, "The common parameters used for tests in this section are:", but > no parameters follow. The sentence will be revised to indicate that the 3rd level headings describe specific experiments and the parameters are listed there, so no information is missing from the test plan. > 2) In some of the examples, "public" IP addresses are used (as far as I > can tell). Should these addresses be published in an RFC? We included the addresses in section 3 of http://tools.ietf.org/html/rfc680= 8 with no problems through to publication. > 3) I think the paragraph beginning with "There is consensus ..." might > need some clarification. IOW, this is an examination of results collected according to metric definitions in IPPM RFCs, rather than a comparison of system A vs. B. I'll see what can be done to clarify. > 4) I thought the formatting of the IF AND THEN statements for the text > in section 2 was a little unusual. The whole point is to turn attention to the improvements of the RFC text if necessary (again, not A vs. B). We haven't found a need to clarify=20 anything fundamental in either 2679 or 2680 testing. > 5) I would clarify what "Imp" in figure 1 refers to although I figured > out (I think) that it refers to "implementation". Ok >=20 > Bill Cerveny > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nalini.elkins@insidethestack.com Wed Oct 16 20:25:24 2013 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 E91B211E823C for ; Wed, 16 Oct 2013 20:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+1Au082laeR for ; Wed, 16 Oct 2013 20:25:18 -0700 (PDT) Received: from nm10-vm1.access.bullet.mail.bf1.yahoo.com (nm10-vm1.access.bullet.mail.bf1.yahoo.com [216.109.114.208]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4D111E8227 for ; Wed, 16 Oct 2013 20:25:10 -0700 (PDT) Received: from [66.196.81.159] by nm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 17 Oct 2013 03:25:06 -0000 Received: from [66.196.81.129] by tm5.access.bullet.mail.bf1.yahoo.com with NNFMP; 17 Oct 2013 03:25:06 -0000 Received: from [127.0.0.1] by omp1005.access.mail.bf1.yahoo.com with NNFMP; 17 Oct 2013 03:25:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 618570.49634.bm@omp1005.access.mail.bf1.yahoo.com Received: (qmail 38103 invoked by uid 60001); 17 Oct 2013 03:25:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1381980306; bh=mh+oOdKCb2QvARY0zwoNtRPnZbCODjlb33S9+KrICg0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=nzxBSXhwYbz0s/nMnFUB0m0I1TEgSHOT3gcRyf4zh7mjWp7KFo5TD8hS/vYdpVIVID5VqyyZnZdtnzY4aIKpy5s43NJi1dLFLKasCtm1fRKCtyew0k4uwgKtV0lBnhT9N0AmYwPt2qykrZ5/TBABR2T9KCBigL/7ttlHwaRI88k= X-YMail-OSG: 1sz_vFYVM1ngcJrIW7V59MZW_xiOO6tZT.SNylU6w7CYKJz 9F7drv1c3ENvQxsGYwfBhqAxOkRKh_pqMBDSeRXrqUUPsw59enSew6ISqzor 5Ca_30y4RB0yw8MoH0LZE4BRESTUNcvIOK2rBEomPNi7ZparDoYpPATPuEci cHMM1tdhOR6Dy1EcLQk0RVTL3EkNk_FdHwUNoMfGb9wgkywvBqzSGezCODvU UMR.A9o8ewqAkbci.JJA_fze7O4JtdHat6wZdr9_EtKQ7OSD0SLxwb1gbOlk .kDW8qv5PTLh_zUKpHll.EJJABj_oXWnPNEvyZOv5AoQFZaUMXIE2jen4TwX ZuInf_NZsn6t2BdJaQ4w3GA3qbhY5wjavDoEu9DpuAdnGhILXJynNvHnjb4f p9TyRS1PY78Z9QiMGuu08dSNjJV00.x9WZ6rp2wLLlYdaftXzJqWz4YiDfRD tWeZoA16uK4kkiue.IYJnNk13htS9GFC0h._MT43w80pgxUG24LDK5Hc50wA uYEJih4PoJSwZ3ubuczlblctvdjcb13RzEmsdM2s8CufkzJ074BWqqAE45ND __iYU8pk86lSMRDKuOk2G40d8pBkecKufNHKnnA6_enl3k8JfNQpW3nMvhv2 SbXqTo4HE0s9_4KD7MdA6Q2xXxX6Df8jBNTqPAJM- Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Wed, 16 Oct 2013 20:25:05 PDT X-Rocket-MIMEInfo: 002.001, QWxsLAoKSSBoYXZlIHJldmlzZWQgdGhlIDZtYW4gc3VibWlzc2lvbiB0byB0YWtlIG91dCB0aGUgY2FsY3VsYXRpb25zIGFuZCBwYWNrZXQgZmxvd3MuIMKgQWxsIG9mIHRoZXNlIGFyZSBpbiB0aGUgSVBQTSBkb2N1bWVudC4gwqAgQSBub3RhdGlvbiBvZiBhbGwgdGhlIHVzYWdlIGNhc2VzIHRoYXQgdGhpcyBtZXRob2RvbG9neSBzaG91bGQgaGFuZGxlIGhhcyBhbHNvIGJlZW7CoGFkZGVkIHRvIHRoZSBJUFBNIGRyYWZ0LgoKVGhlIElQUE0gZHJhZnQgaXMgaGVyZTrCoGh0dHA6Ly9kYXRhdHJhY2tlci5pZXQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> Message-ID: <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Wed, 16 Oct 2013 20:25:05 -0700 (PDT) From: Nalini Elkins To: v6ops WG , 6man WG , "ippm@ietf.org" In-Reply-To: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-1958070460-1381980305=:36254" Subject: [ippm] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 03:25:24 -0000 ---1551098171-1958070460-1381980305=:36254 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All,=0A=0AI have revised the 6man submission to take out the calculations a= nd packet flows. =A0All of these are in the IPPM document. =A0 A notation o= f all the usage cases that this methodology should handle has also been=A0a= dded to the IPPM draft.=0A=0AThe IPPM draft is here:=A0http://datatracker.i= etf.org/doc/draft-elkins-ippm-pdm-metrics/=0A=0AThe 6man draft is below.=0A= =0AI appreciate any thoughts and comments.=0A=0AA new version of I-D, draft= -elkins-6man-ipv6-pdm-dest-option-04.txt=0Ahas been successfully submitted = by Nalini Elkins and posted to the=0AIETF repository.=0A=0AFilename:=A0=A0= =A0 draft-elkins-6man-ipv6-pdm-dest-option=0ARevision:=A0=A0=A0 04=0ATitl= e:=A0=A0=A0 =A0=A0=A0 IPv6 Performance and Diagnostic Metrics Destination = Option=0ACreation date:=A0=A0=A0 2013-10-16=0AGroup:=A0=A0=A0 =A0=A0=A0 I= ndividual Submission=0ANumber of pages: 12=0AURL:=A0 =A0 =A0 =A0 =A0 =A0 h= ttp://www.ietf.org/internet-drafts/draft-elkins-6man-ipv6-pdm-dest-option-0= 4.txt=0AStatus:=A0 =A0 =A0 =A0 =A0 http://datatracker.ietf.org/doc/draft-el= kins-6man-ipv6-pdm-dest-option=0AHtmlized:=A0 =A0 =A0 =A0 http://tools.ietf= .org/html/draft-elkins-6man-ipv6-pdm-dest-option-04=0ADiff:=A0 =A0 =A0 =A0 = =A0 =A0 http://www.ietf.org/rfcdiff?url2=3Ddraft-elkins-6man-ipv6-pdm-dest-= option-04=0A=0AAbstract:=0A=A0 To diagnose performance and connectivity pr= oblems, metrics on real=0A=A0 (non-synthetic) transmission are critical fo= r timely end-to-end=0A=A0 problem resolution. Such diagnostics may be real= -time or after the=0A=A0 fact, but must not impact an operational producti= on network. The base=0A=A0 metrics are: packet sequence number and packet = timestamp.=A0 Metrics=0A=A0 derived from these will be described separatel= y. This document solves=0A=A0 these problems with a new destination option= , the Performance and=0A=A0 Diagnostic Metrics destination option (PDM).= =0A=0A=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =0A=0A=0APlease note that it may take a couple of = minutes from the time of submission=0Auntil the htmlized version and diff a= re available at tools.ietf.org.=0A=0AThe IETF Secretariat ---1551098171-1958070460-1381980305=:36254 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
All,
<= br>
I have revised the 6man submission to take out the calcu= lations and packet flows.  All of these are in the IPPM document. &nbs= p; A notation of all the usage cases that this methodology should handle ha= s also been adde= d to the IPPM draft.


The 6man draft is below.

I appreciate any thoughts and comments.
=0A
A new version of I-D, draft-elki= ns-6man-ipv6-pdm-dest-option-04.txt
has been successfully submitted by N= alini Elkins and posted to the
IETF repository.

Filename: &n= bsp;  draft-elkins-6man-ipv6-pdm-dest-option
Revision:  =   04
Title:        IPv6 Performance= and Diagnostic Metrics Destination Option
Creation date:  &nb= sp; 2013-10-16
Group:        Individual = Submission
Number of pages: 12
URL:         =   http://www.ietf.org/internet-drafts/draft-elkins-6man-ipv6-pdm-des= t-option-04.txt
Status:          http://datatra= cker.ietf.org/doc/draft-elkins-6man-ipv6-pdm-dest-option
Htmlized: =       http://tools.ietf.org/html/draft-elkins-6man-ipv6-pdm= -dest-option-04
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-elkins-6man-ipv6-pdm-dest-option-= 04

Abstract:
  To diagnose performance and connectivity pro= blems, metrics on real
  (non-synthetic) transmission are critical= for timely end-to-end
  problem resolution. Such diagnostics may = be real-time or after the
  fact, but must not impact an operation= al production network. The base
  metrics are: packet sequence num= ber and packet timestamp.  Metrics
  derived from these will = be described separately. This document solves
  these problems wit= h a new destination option, the Performance and
  Diagnostic Metri= cs destination option (PDM).


          =                      = ;                     &nb= sp;                            


Please note that it may tak= e a couple of minutes from the time of submission
until the htmlized ver= sion and diff are available at tools.ietf.org.

The IETF Secretariat



---1551098171-1958070460-1381980305=:36254-- From ippm@wjcerveny.com Fri Oct 18 06:03:05 2013 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 9389211E8287 for ; Fri, 18 Oct 2013 06:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9lYd3+5Yyai for ; Fri, 18 Oct 2013 06:03:00 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id AAB9C11E8295 for ; Fri, 18 Oct 2013 06:02:56 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id ED690220E2 for ; Fri, 18 Oct 2013 09:02:54 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 18 Oct 2013 09:02:54 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=from:content-type:subject:message-id:date :to:mime-version; s=smtpout; bh=yGyxwvpuPnm7SrYJ6x5II8gWCFs=; b= Ow3RyPDM3UsBXQIRIbJHSpUdJhgZid6GaPaH1q+BRPngtDGYS50MW8KnQsGxH8cg QUhZQlVZhfOjRGY0wdyYORAtZOV4WeKiQ8Pl3O4q5DqNUt2s5s8zZZuNUfzLCor/ sot7bNWDOGYTIqwtsCFN8BH6P8u44Bi1HhTK2FRg3zM= X-Sasl-enc: B11hs1iEZoJ3/vddsj5kCMYecEy0jevv8TxeW8WL/wBU 1382101374 Received: from [192.168.1.110] (unknown [96.35.101.227]) by mail.messagingengine.com (Postfix) with ESMTPA id B1A61C00E7F for ; Fri, 18 Oct 2013 09:02:54 -0400 (EDT) From: Bill Cerveny Content-Type: multipart/alternative; boundary="Apple-Mail=_1C11A0A2-07A0-45E9-B06C-681B7171A55A" Message-Id: <8C1F8AD6-6F60-40CA-BEAC-59D8351963D9@wjcerveny.com> Date: Fri, 18 Oct 2013 09:03:12 -0400 To: "ippm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [ippm] IPPM WG Registry Design Team 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, 18 Oct 2013 13:03:05 -0000 --Apple-Mail=_1C11A0A2-07A0-45E9-B06C-681B7171A55A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We have had two proposals for defining a performance metrics registry = submitted as individual drafts. The authors have been meeting amongst = themselves in an ongoing attempt to iron out the differences between the = proposals, and to arrive at a unified document to be submitted for = consideration as an IPPM Working Group draft. Since a de facto design team has formed around this work, we would like = to recognize this fact officially, and appoint the authors as members of = the IPPM Registry Design Team. We ask that the design team report to the = working group during the Vancouver IPPM meeting on Thursday, November 7, = and to the ippm@ietf.org list after that meeting. They will report on = their progress, and on any additional open issues they see necessary to = solve before the document is ready to be considered as a working group = draft. The members of the design team are: Aamer Akhter Marcelo Bagnulo Benoit Claise Philip Eardley Al Morton Best regards, Brian and Bill --Apple-Mail=_1C11A0A2-07A0-45E9-B06C-681B7171A55A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii ippm@ietf.org list after that = meeting. They will report on their progress, and on any additional open = issues they see necessary to solve before the document is ready to be = considered as a working group draft.

The members of the design = team are:

Aamer Akhter
Marcelo Bagnulo
Benoit = Claise
Philip Eardley
Al Morton

Best regards,

Brian = and Bill
= --Apple-Mail=_1C11A0A2-07A0-45E9-B06C-681B7171A55A-- From trammell@tik.ee.ethz.ch Fri Oct 18 06:39:00 2013 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 12E9911E81D1 for ; Fri, 18 Oct 2013 06:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.01 X-Spam-Level: X-Spam-Status: No, score=-6.01 tagged_above=-999 required=5 tests=[AWL=0.590, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7MAbBiierhL for ; Fri, 18 Oct 2013 06:38:55 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 47B3811E8112 for ; Fri, 18 Oct 2013 06:38:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 23F9AD9304 for ; Fri, 18 Oct 2013 15:38:54 +0200 (MEST) 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 qmDVNV-q08XX for ; Fri, 18 Oct 2013 15:38:53 +0200 (MEST) 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 CEA57D9303 for ; Fri, 18 Oct 2013 15:38:53 +0200 (MEST) From: Brian Trammell Content-Type: multipart/signed; boundary="Apple-Mail=_35F3E4D1-D423-4E32-844E-DA9702FBF82E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 18 Oct 2013 15:38:53 +0200 Message-Id: <74E373EA-7BC3-4186-8B24-B6DFECE40775@tik.ee.ethz.ch> To: "ippm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [ippm] IPPM WG Meeting Agenda at IETF 88 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "ippm-chairs@tools.ietf.org Chairs" List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 13:39:00 -0000 --Apple-Mail=_35F3E4D1-D423-4E32-844E-DA9702FBF82E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, A draft agenda for our meeting at IETF 88 in Vancouver, on Thursday, 7 = November, has been posted to: https://datatracker.ietf.org/meeting/88/agenda/ippm/ Please direct any comments thereon to ippm-chairs@tools.ietf.org. Presenters: Please send your slides to ippm-chairs@tools.ietf.org by = Wednesday. Note that we will have a full schedule, and the chairs will = be quite strict about holding to the agenda. Keep in mind that the slots = include time for presentations as well as discussion. Please plan = accordingly. Many thanks, best regards, Bill and Brian --Apple-Mail=_35F3E4D1-D423-4E32-844E-DA9702FBF82E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSYTntAAoJENt3nsOmbNJcbtcH/12eJ63p37V4ob7RvYcLh3xS FFmVDfYxb0y4VL7D4tWdrDFKTtn6KuPcovJLl0ulAiDW56JSJpbhhIEtyKoreXzk jxf4ZmAlM2CzsG7hvMot10QvzdixkHvjBJybagpKe6jITYQJzAqcwimRr6ynXLeM IQitVhSRbxBGo+zWbX64s2jvb9+pk2IQqOghJwnsU1cRCPEbtfM73YhvfmQwENs/ NDlx5AI+vVTIaQlNOvYs2lEoWItF7KGKEfNXxJ8VbQIKHpEuTTadMjYyb6nb2Uhj xCx//SJ4GI0Pz3NxrwFgM4xse9W9/PUVthrCZXx11AvteaV1MwZg8BK9GY3MCm4= =HxWZ -----END PGP SIGNATURE----- --Apple-Mail=_35F3E4D1-D423-4E32-844E-DA9702FBF82E-- From Joachim.Fabini@tuwien.ac.at Fri Oct 18 11:43:58 2013 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 0538511E82FF for ; Fri, 18 Oct 2013 11:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.981 X-Spam-Level: X-Spam-Status: No, score=-3.981 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdSJb6LSZv-r for ; Fri, 18 Oct 2013 11:43:52 -0700 (PDT) Received: from mail1.zserv.tuwien.ac.at (mail1.zserv.tuwien.ac.at [128.130.35.37]) by ietfa.amsl.com (Postfix) with ESMTP id E301911E81B8 for ; Fri, 18 Oct 2013 11:43:51 -0700 (PDT) Received: from centri (213-240-99-26.adsl.highway.telekom.at [213.240.99.26]) (authenticated bits=0) by mail1.zserv.tuwien.ac.at (8.13.8/8.13.8) with ESMTP id r9IIhkbV004125 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 18 Oct 2013 20:43:46 +0200 From: "Joachim Fabini" To: References: <202A7446-2F22-4F9B-9378-C6554249C6BB@tik.ee.ethz.ch> In-Reply-To: <202A7446-2F22-4F9B-9378-C6554249C6BB@tik.ee.ethz.ch> Date: Fri, 18 Oct 2013 20:43:40 +0200 Message-ID: <020801cecc31$f6ed3e50$e4c7baf0$@Fabini@tuwien.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7ACuEntCBQY3IiQHmU83eQWMDaaQMJSMMg Content-Language: en-ie Subject: Re: [ippm] WGLC announcement for draft-ietf-ippm-testplan-rfc2680 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, 18 Oct 2013 18:43:58 -0000 Dear group, I support the test plan draft and have added below some minor remarks/comments/typos which might help in improving clarity. regards Joachim General remark (applies mainly to RFC6808, which I read as introductory document and a potential future "advancement of round-trip delay document". For the 2680 testplan it should have a minor effect, affecting only the time value after which a packet is considered as lost). We have discussed this in previous emails with Al: NetEm _might_ be an important additional source of error. NetEm's resolution typically equals the system kernel tick (Hz value). In some Linux distributions (Ubuntu, Debian) the kernel tick is by default configured at 250Hz, such that an uncertainty value of 4ms is introduced (kernel compile with appropriate settings can increase the tick to 1000 Hz). Fedora seems to have by default 1000 Hz settings, which results in 1ms uncertainty. And recently a tickless operation has been introduced but I don't know if/how this affects NetEm. Abstracting from these technical settings, I propose to make these decisions and potential uncertainty sources explicit by mentioning them in the documents. - Page 7, Figure 1, upper: A detailed description of the figure, its notations, components and instances could be added. In particular I could not find any description about mapping the two Imp1 and two Imp2 instances to actual components/implementations. Are the Imp1's Netprobes and Imp2's Perfas, ore vice-versa? Is one of the two identically-labelled boxes/instances send-only and one receive-only? Or do the instances change for distinct tests, depending on the specific test? This might be detailed accurately in the text (what Imp1 and Imp2 rectangles are and how they relate to the figure and what their role for these tests is). - Page 7, Figure 1, upper vs. lower: The mapping between the upper figure and lower one is not obvious to me. Is Imp1 in the lower figure one instance of an Imp1 box in the upper figure, or is it an aggregation of the two Imp1 instances in the upper figure? Could be explained in text. - Page 7, Figure 1, lower: I miss NetEm in the lower figure. According to the upper figure 1, the U-turn for V100 and V200 seems to be implemented in the right Ethernet switch. So the netem instance should be part of the flow representation, too (inserted between Internet and Remote Switch - imho important issue, as it is the one which impairs/drops the traffic and might introduce additional uncertainties) - Page 20: Section 6.4.1: From a strictly technical point of view (affecting the timeout interval after which a packet is considered to be lost), it might make a difference whether timestamps are acquired before or after the system call. So the point in time when timestamp acquisition is scheduled should be defined unambiguously. -------------------- Layout, typos, etc. ---------------- - Page 4, second paragraph ("A renewed work...") - it is not clear to me whether this paragraph is related to the third paragraph and references RFC6567 (merge the two in this case?). Alternatively a reference/citation could be added to the second paragraph. - Page 4, next-to-last paragraph: is it acceptable to reference an ID (I-D.morton-ippm-advance-metrics) from here? - Page 5, Section 2, second paragraph: typo "the an equivalent" - Page 8: Add reference to "mii-tool"? (btw, as a side-node: mii-tool seems to be deprecated on some Linux distributions, being replaced by ethtool) - Page 8: Typo (DCSP instead of DSCP?) - Page 10: I'd propose to mark and delimit start and end of the traceroute output visually - perhaps add a caption (Netprobe traceroute)? - Page 11: third paragraph, typo ("was be") - Page 14: Perhaps it would improve readability to delimit the R output (on this page and all subsequent occurrences) visually and add a caption? - Page 23: section 6.4.3: typo "distributions when according" > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Brian Trammell > Sent: 03 October 2013 09:32 > To: ippm@ietf.org > Subject: [ippm] WGLC announcement for draft-ietf-ippm-testplan-rfc2680 > > Greetings, all, > > As discussed in Berlin, "Test Plan and Results for Advancing RFC 2680 > on the Standards Track", draft-ietf-ippm-testplan-rfc2680, is ready for > Working Group Last Call (WGLC); this message begins that last call. > Please direct any final comments on this draft to the ippm@ietf.org > mailing list by Friday 18 October 2013. > > Many thanks, best regards, > > Brian From acmorton@att.com Fri Oct 18 13:23:44 2013 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 E0A8211E81F2 for ; Fri, 18 Oct 2013 13:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McCxeooqaVn8 for ; Fri, 18 Oct 2013 13:23:39 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id A7C5E21F9425 for ; Fri, 18 Oct 2013 13:23:39 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 182BF121016; Fri, 18 Oct 2013 16:23:39 -0400 (EDT) Received: from njfpsrvexg1.research.att.com (njfpsrvexg1.research.att.com [135.207.177.20]) by mail-azure.research.att.com (Postfix) with ESMTP id 1AD37E2DD0; Fri, 18 Oct 2013 16:23:39 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg1.research.att.com ([fe80::58ce:ca01:5d18:db01%13]) with mapi; Fri, 18 Oct 2013 16:23:39 -0400 From: "MORTON, ALFRED C (AL)" To: Joachim Fabini , "ippm@ietf.org" Date: Fri, 18 Oct 2013 16:23:37 -0400 Thread-Topic: [ippm] WGLC announcement for draft-ietf-ippm-testplan-rfc2680 Thread-Index: Ac7ACuEntCBQY3IiQHmU83eQWMDaaQMJSMMgAAJg4MA= Message-ID: <2845723087023D4CB5114223779FA9C8AB2EA7A8@njfpsrvexg8.research.att.com> References: <202A7446-2F22-4F9B-9378-C6554249C6BB@tik.ee.ethz.ch> <020801cecc31$f6ed3e50$e4c7baf0$@Fabini@tuwien.ac.at> In-Reply-To: <020801cecc31$f6ed3e50$e4c7baf0$@Fabini@tuwien.ac.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ippm] WGLC announcement for draft-ietf-ippm-testplan-rfc2680 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, 18 Oct 2013 20:23:45 -0000 Thanks very much for your review and comments, Joachim! I will address these over the weekend, and ideally=20 propose resolutions in the text before the deadline on Monday... Also, thanks to Bill and Ann Cerveny for comments and suggestions. regards, Al > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Joachim Fabini > Sent: Friday, October 18, 2013 2:44 PM > To: ippm@ietf.org > Subject: Re: [ippm] WGLC announcement for draft-ietf-ippm-testplan-rfc268= 0 >=20 > Dear group, >=20 > I support the test plan draft and have added below some minor > remarks/comments/typos which might help in improving clarity. >=20 > regards > Joachim >=20 > General remark (applies mainly to RFC6808, which I read as introductory > document and a potential future "advancement of round-trip delay > document". > For the 2680 testplan it should have a minor effect, affecting only the > time > value after which a packet is considered as lost). We have discussed this > in > previous emails with Al: NetEm _might_ be an important additional source > of > error. NetEm's resolution typically equals the system kernel tick (Hz > value). In some Linux distributions (Ubuntu, Debian) the kernel tick is b= y > default configured at 250Hz, such that an uncertainty value of 4ms is > introduced (kernel compile with appropriate settings can increase the tic= k > to 1000 Hz). Fedora seems to have by default 1000 Hz settings, which > results > in 1ms uncertainty. And recently a tickless operation has been introduced > but I don't know if/how this affects NetEm. Abstracting from these > technical > settings, I propose to make these decisions and potential uncertainty > sources explicit by mentioning them in the documents. >=20 > - Page 7, Figure 1, upper: A detailed description of the figure, its > notations, components and instances could be added. In particular I could > not find any description about mapping the two Imp1 and two Imp2 instance= s > to actual components/implementations. Are the Imp1's Netprobes and Imp2's > Perfas, ore vice-versa? Is one of the two identically-labelled > boxes/instances send-only and one receive-only? Or do the instances chang= e > for distinct tests, depending on the specific test? This might be detaile= d > accurately in the text (what Imp1 and Imp2 rectangles are and how they > relate to the figure and what their role for these tests is). >=20 > - Page 7, Figure 1, upper vs. lower: The mapping between the upper figure > and lower one is not obvious to me. Is Imp1 in the lower figure one > instance > of an Imp1 box in the upper figure, or is it an aggregation of the two > Imp1 > instances in the upper figure? Could be explained in text. >=20 > - Page 7, Figure 1, lower: I miss NetEm in the lower figure. > According to the upper figure 1, the U-turn for V100 and V200 seems to be > implemented in the right Ethernet switch. So the netem instance should be > part of the flow representation, too (inserted between Internet and Remot= e > Switch - imho important issue, as it is the one which impairs/drops the > traffic and might introduce additional uncertainties) >=20 > - Page 20: Section 6.4.1: From a strictly technical point of view > (affecting > the timeout interval after which a packet is considered to be lost), it > might make a difference whether timestamps are acquired before or after > the > system call. So the point in time when timestamp acquisition is scheduled > should be defined unambiguously. >=20 >=20 > -------------------- Layout, typos, etc. ---------------- > - Page 4, second paragraph ("A renewed work...") - it is not clear to me > whether this paragraph is related to the third paragraph and references > RFC6567 (merge the two in this case?). Alternatively a reference/citation > could be added to the second paragraph. > - Page 4, next-to-last paragraph: is it acceptable to reference an ID > (I-D.morton-ippm-advance-metrics) from here? > - Page 5, Section 2, second paragraph: typo "the an equivalent" > - Page 8: Add reference to "mii-tool"? (btw, as a side-node: mii-tool > seems > to be deprecated on some Linux distributions, being replaced by ethtool) > - Page 8: Typo (DCSP instead of DSCP?) > - Page 10: I'd propose to mark and delimit start and end of the tracerout= e > output visually - perhaps add a caption (Netprobe traceroute)? > - Page 11: third paragraph, typo ("was be") > - Page 14: Perhaps it would improve readability to delimit the R output > (on > this page and all subsequent occurrences) visually and add a caption? > - Page 23: section 6.4.3: typo "distributions when according" >=20 > > -----Original Message----- > > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > > Brian Trammell > > Sent: 03 October 2013 09:32 > > To: ippm@ietf.org > > Subject: [ippm] WGLC announcement for draft-ietf-ippm-testplan-rfc2680 > > > > Greetings, all, > > > > As discussed in Berlin, "Test Plan and Results for Advancing RFC 2680 > > on the Standards Track", draft-ietf-ippm-testplan-rfc2680, is ready for > > Working Group Last Call (WGLC); this message begins that last call. > > Please direct any final comments on this draft to the ippm@ietf.org > > mailing list by Friday 18 October 2013. > > > > Many thanks, best regards, > > > > Brian >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From mackermann@bcbsm.com Tue Oct 15 09:41:28 2013 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 D8DD711E8118 for ; Tue, 15 Oct 2013 09:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4R+ItQa7YGRw for ; Tue, 15 Oct 2013 09:41:22 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id 2054411E819E for ; Tue, 15 Oct 2013 09:41:09 -0700 (PDT) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id BC0CB9AD9FC for ; Tue, 15 Oct 2013 11:41:03 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 05DB59AD9F5; Tue, 15 Oct 2013 11:41:01 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id D2B714F8055; Tue, 15 Oct 2013 12:31:09 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva1.bcbsm.com (Postfix) with ESMTP id C42E34F8051; Tue, 15 Oct 2013 12:31:09 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([fe80::8db:9ce7:e2cf:8565%13]) with mapi id 14.01.0438.000; Tue, 15 Oct 2013 12:40:54 -0400 From: "Ackermann, Michael" To: Nalini Elkins , "MORTON, ALFRED C (AL)" , "ippm@ietf.org" Thread-Topic: [ippm] Fw: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt Thread-Index: AQHOyayMqQBwUbYhkUaj9bxzxFlrf5n11Tpg Date: Tue, 15 Oct 2013 16:40:54 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0CA77267@PWN401EA160.ent.corp.bcbsm.com> References: <20131004030407.30291.83858.idtracker@ietfa.amsl.com>, <1380892227.93952.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2845723087023D4CB5114223779FA9C8AAD39FC2@njfpsrvexg8.research.att.com> <1381844622.97264.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: <1381844622.97264.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: multipart/alternative; boundary="_000_4FC37E442D05A748896589E468752CAA0CA77267PWN401EA160entc_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 18 Oct 2013 13:40:33 -0700 Cc: Sigfrido Perdomo , Bill Jouris Subject: Re: [ippm] Fw: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt 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, 15 Oct 2013 16:41:29 -0000 --_000_4FC37E442D05A748896589E468752CAA0CA77267PWN401EA160entc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Al, Echoing Nalini's thoughts regarding your great comments/questions and how = excited we are about the potential of working with you and your teams. Nalini's answers are great in my view and I have one comment/question on = the topic of =22Middle Boxes=22, which in my view includes Routers and = Firewalls. As Nalini said, the PDM was conceived to be populated and = utilized primarily by End Points, which will be Hosts/IP Stacks of = various types. The biggest function we had in mind for the Middle = Boxes, was to just not drop or alter the PDM. My question for you is = whether you think we SHOULD craft additional PDM function that CAN be = populated and/or utilized expressly for or by Middle Boxes? This would likely involve more complexity and overhead, but may be = warranted if associated value is perceived. I would also like endorse Nalini's answer on your great and very = fascinating question about The APP, TCP and other time breakdowns. As = a lowly customer/end user (while Nalini is a Diagnostic Software Expert), = I share her view on the value of the =22Network Triage=22. Knowing = whether the time is being spent in the Host, Network and in what = direction, is critically valuable. This may tell you all you need to = know, or other tools take over at that point for more granular = diagnostics. So, in my view that level of granular diagnostics is = beyond the scope of the PDM, but would luv, luv, luv to talk more about = this with you. Thanks again and look forward to seeing you in Vancouver=21 Mike From: Nalini Elkins =5Bmailto:nalini.elkins=40insidethestack.com=5D Sent: Tuesday, October 15, 2013 9:44 AM To: MORTON, ALFRED C (AL); ippm=40ietf.org Cc: Sigfrido Perdomo; keven.haining=40usbank.com; Bill Jouris; Ackermann, = Michael Subject: Re: =5Bippm=5D Fw: New Version Notification for = draft-elkins-ippm-pdm-metrics-00.txt Al, Thanks for your thorough examination and great comments. My responses are = inline. Also, if you have time in Vancouver, Mike & I would like to ask = you to have lunch or dinner on us. It is the least we can do for all = your help=21 Please let us know if you have a free day. >Early in the Intro, the various time/number fields are referred to as = =22base metrics=22 themselves. >I know you'll want to clarify that (they are just fields). Sure. >In section 1.2: in addition to time and seq number for current packet: > PSNLR : Packet Sequence Number Last Received > TSLR : Timestamp Last Received >the device supplying the header appears to need to maintain flow state to = add >these =22last packet=22 fields. A very strong justification is probably = needed. >Later, I see that the Server host essentially has to store the fields = across >request-response pairs. Lower and higher layers need to work together, >somehow. The Destination Options Header is created only by the OS's at the end = points. That is, the Microsofts, linuxes, and IBM's of the world. The OS = at the end point already maintains state. If you think of TCP TimeWait = status for example. The connection is in TimeWait status for 2 * MSL. = So, obviously state is being maintained. Anyway, all the OS's have = control blocks associated with each active connection. Now, there is going to be some discussion by the OS vendors about non-TCP = protocols=21 I have participated in those discussions with IBM in a = former life (when they OEMed a product of mine & I wanted them to do = something=21) but I believe that they are persuadable. I am guessing = that this information is already being maintained. All we are asking for = is for it to be exposed. Our header is not for middle boxes. We are not asking for router, etc. to = maintain state in this way. >In Section 3.1 and 3.2, it's not clear which PDM time-stamps support the = (round-trip delay >and server delay) metrics. When you look at RFC2681, it should be fairly = clear where >the time stamps are applied, and that needs to carry though here (though = I see it later >in the example). I will clarify. >Looking at the example in section 4, there can be a significant delay = between when >the application layer transfers packets to TCP's send buffer and when the = packets are >actually sent =22on the wire=22 (as we say in IPPM), which happens after = the IP header is >applied (or most of the header, in some cases). How would accuracy be = maintained >across all the different layers? >Maybe another way to phrase the question is this: >How does the process that adds the PDM header (with last Seq number 25) = know >which packet to add it to? There are 2 questions here. First, it will be the IP layer adding the = times. Yes, I know that it is a =22gross=22 measurement comprising of a = number of components. But, then so is one-way delay. That is, there are = multiple components within the path. The purpose of our measurements is = to allow the diagnostician to do very quick triage. That is, to say, is = the problem in the network or the server? Then, we hand the problem off = to the right group who can runmore detailed diagnostic tests. In our experience, this is a very valuable kind of measurement to have. A = great deal of time, effort and money is spent at large end user sites to = determine just this. Anecdotal evidence tells me that this is true for = home users of the Internet also. My working life has been spent at large = data centers, so that I can answer to without any hesitation. > I note that there is IPR declared on this draft, and licensing is not = clear. Yes, we do have IPR. I hope I have declared it properly=21 Please let me = know if I have not. We have not decided on the exact nature of the = licensing but it will be very reasonable. We want the technology adopted. = There are more advanced metrics which can be created from these which is the primary = reason for the IPR. BTW, we are starting to engage in discussions also with folks looking at a = new WG. = https://sites.google.com/site/transportprotocolservices/home/charter-propos= al-before-bof We feel our metrics / header can help with a unified Simple Congestion = Control (SCC) and Inter-Layer Communication (ILC). That is some of our = other work. The above group seems to feel that work would fit in with = their efforts=21 I feel that the fields we propose are simple yet very = powerful. Many uses can be made of them. I can tell you more on this, = if you have interest. ________________________________________ From: ippm-bounces=40ietf.org = =5Bippm-bounces=40ietf.org=5D On Behalf Of = Nalini Elkins = =5Bnalini.elkins=40insidethestack.com=5D Sent: Friday, October 04, 2013 9:10 AM To: WG (v6ops=40ietf.org); 6man WG; = ippm=40ietf.org Cc: Sigfrido Perdomo; = keven.haining=40usbank.com; Bill = Jouris; Ackermann Michael Subject: =5Bippm=5D Fw: New Version Notification for = draft-elkins-ippm-pdm-metrics-00.txt We have submitted a number of drafts. Some are new and some are updates = to our existing PDM proposal. We would appreciate any comments, = questions, and corrections from the lists. The new ones are: 1. In IPPM: http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt This describes the base and derived metrics which can be obtained from the = IPv6 PDM DO Extension Header. 2. In TicToc: http://www.ietf.org/internet-drafts/draft-ackermann-tictoc-pdm-ntp-usage-00= =2Etxt This describes how NTP may be implemented to support PDM. The updates are as follows 1. In 6man: http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt This is the layout of the PDM DO header. 2. In v6ops: http://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-packet-sequence= -needed-01.txt http://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-pdm-recommended= -usage-01.txt http://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-end-to-end-rt-n= eeded-01.txt These are background for the proposal. Thanks, Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com ----- Forwarded Message ----- From: =22internet-drafts=40ietf.org=22 = > To: Nalini Elkins = >; William Jouris = > Sent: Thursday, October 3, 2013 8:04 PM Subject: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt A new version of I-D, draft-elkins-ippm-pdm-metrics-00.txt has been successfully submitted by Nalini Elkins and posted to the IETF repository. Filename: draft-elkins-ippm-pdm-metrics Revision: 00 Title: IPPM Considerations for the IPv6 PDM Extension Header Creation date: 2013-10-03 Group: Individual Submission Number of pages: 14 URL: = http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt Status: = http://datatracker.ietf.org/doc/draft-elkins-ippm-pdm-metrics Htmlized: http://tools.ietf.org/html/draft-elkins-ippm-pdm-metrics-00 Abstract: To diagnose performance and connectivity problems, metrics on real (non-synthetic) transmission are critical for timely end-to-end problem resolution. Such diagnostics may be real-time or after the fact, but must not impact an operational production network. These metrics are defined in the IPv6 Performance and Diagnostic Metrics Destination Option (PDM). The base metrics are: packet sequence number and packet timestamp. Other metrics may be derived from these for use in diagnostics. This document specifies such metrics, their calculation, and usage. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_4FC37E442D05A748896589E468752CAA0CA77267PWN401EA160entc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

Hi Al,

 

Echoing Nalini&=238217;s thoughts regarding =  your great comments/questions and how excited we are about the = potential of working with you and your teams. 

 

Nalini&=238217;s answers are great in my view = and I have one comment/question on the topic of &=238220;Middle = Boxes&=238221;, which in my view includes Routers and = Firewalls.     As Nalini said, the PDM was conceived to be populated and utilized primarily =  by End Points, which will be Hosts/IP Stacks of various = types.     The biggest function we had in mind for the = Middle Boxes, was to just not drop or alter the = PDM.      My question for you is whether you think we SHOULD craft additional PDM function that =  CAN be populated and/or utilized expressly for or by Middle = Boxes?  

This would likely involve more complexity and = overhead, but may be warranted if associated value is perceived.  

 

I would also like endorse Nalini&=238217;s = answer on your great and very fascinating question about The APP, TCP and = other time breakdowns.      As a lowly customer/end user (while Nalini is a Diagnostic Software Expert), I share her view on = the value of the &=238220;Network Triage&=238221;.     = Knowing whether the time is being spent in the Host, Network and in what = direction, is critically valuable.    This may tell you all = you need to know, or other tools take over at that point for more granular = diagnostics.    So, in my view that level of granular = diagnostics is beyond the scope of the PDM, but would luv, luv, luv to = talk more about this with you.  

 

Thanks again and look forward to seeing you in = Vancouver=21

 

Mike

 

 

 

From: Nalini Elkins =5Bmailto:nalini.elkins=40insidethestack.com=5D
Sent: Tuesday, October 15, 2013 9:44 AM
To: MORTON, ALFRED C (AL); ippm=40ietf.org
Cc: Sigfrido Perdomo; keven.haining=40usbank.com; Bill Jouris; = Ackermann, Michael
Subject: Re: =5Bippm=5D Fw: New Version Notification for = draft-elkins-ippm-pdm-metrics-00.txt

 

Al,

 

Thanks for your thorough examination and great comments.  My = responses are inline.   Also, if you have time in Vancouver, Mike = & I would like to ask you to have lunch or dinner on us.   It is the least we can do for all your help=21  Please = let us know if you have a free day.

 


>Early in the Intro, the various time/number fields are referred to as = "base metrics" themselves.
>I know you'll want to clarify that (they are just = fields).

 

Sure.

 

>In section 1.2: in addition to time and seq = number for current packet:

 >                PSNLR : = Packet Sequence Number Last Received
 >               TSLR  : = Timestamp Last Received

>the device supplying the header appears to need to maintain flow state = to add
>these "last packet" fields. A very strong justification is = probably needed.
>Later, I see that the Server host essentially has to store the fields = across
>request-response pairs. Lower and higher layers need to work = together,
>somehow.

The Destination Options Header is created only by the OS's at the end = points.  That is, the Microsofts, linuxes, and IBM's of the world. =  The OS at the end point already maintains state.   If you think = of TCP TimeWait status for example.   The connection is in TimeWait status for 2 * MSL.  So, obviously state is being = maintained.  Anyway, all the OS's have control blocks associated with = each active connection.

 

Now, there is going to be some discussion by the = OS vendors about non-TCP protocols=21  I have participated in those = discussions with IBM in a former life (when they OEMed a product of mine & I wanted them to do something=21)  but I believe that they are = persuadable.   I am guessing that this information is already being = maintained.  All we are asking for is for it to be = exposed.

 

Our header is not for middle boxes.  We are = not asking for router, etc. to maintain state in this way.


>In Section 3.1 and 3.2, it's not clear which PDM time-stamps support = the (round-trip delay
>and server delay) metrics. When you look at  RFC2681, it should = be fairly clear where
>the time stamps are applied, and that needs to carry though here = (though I see it later
>in the example).

 

I will clarify.

 

>Looking at the example in section 4, there = can be a significant delay between when
>the application layer transfers packets to TCP's send buffer and when = the packets are
>actually sent "on the wire" (as we say in IPPM), which = happens after the IP header is
>applied (or most of the header, in some cases). How would accuracy be = maintained
>across all the different layers?

>Maybe another way to phrase the question is this:
>How does the process that adds the PDM header (with last Seq number = 25) know
>which packet to add it to? 

 

There are 2 questions here.  First, it will = be the IP layer adding the times.  Yes, I know that it is a = "gross" measurement comprising of a number of components. =  But, then so is one-way delay.  That is,  there are multiple components within the = path.   The purpose of our measurements is to allow the diagnostician = to do very quick triage.  That is, to say, is the problem in the = network or the server?  Then, we hand the problem off to the right group who can runmore detailed diagnostic tests. =   

 

In our experience, this is a very valuable kind = of measurement to have.  A great deal of time, effort and money is = spent at large end user sites to determine just this.   Anecdotal = evidence tells me that this is true for home users of the Internet also.   My = working life has been spent at large data centers, so that I can answer to = without any hesitation.

 

> I note that there is IPR declared on = this draft, and licensing is not clear.

 

Yes, we do have IPR.  I hope I have = declared it properly=21  Please let me know if I have not.  We = have not decided on the exact nature of the licensing but it will be very = reasonable.  We want the technology adopted.    There are

more advanced metrics which can be created from = these which is the primary reason for the IPR.

 

BTW, we are starting to engage in discussions = also with folks looking at a new WG. https://sites.google.com/site/transportprotocols= ervices/home/charter-proposal-before-bof

We feel our metrics / header can help with a = unified Simple Congestion Control (SCC) and Inter-Layer Communication = (ILC).   That is some of our other work.   The above group = seems to feel that work would fit in with their efforts=21  I feel that the fields = we propose are simple yet very powerful.  Many uses can be made of = them.   I can tell you more on this, if you have = interest.

 


________________________________________
From: ippm-bounces=40ietf.org = =5Bippm-bounces=40ietf.org=5D = On Behalf Of Nalini Elkins =5Bnalini.elkins=40insi= dethestack.com=5D
Sent: Friday, October 04, 2013 9:10 AM
To: WG (v6ops=40ietf.org); = 6man WG; ippm=40ietf.org
Cc: Sigfrido Perdomo; keven.haining=40usbank.com; Bill Jouris; Ackermann Michael
Subject: =5Bippm=5D Fw: New Version Notification for      =   draft-elkins-ippm-pdm-metrics-00.txt

We have submitted a number of drafts.  Some are new and some are = updates to our existing PDM proposal.  We would appreciate any = comments, questions, and corrections from the lists.


The new ones are:

1.  In IPPM:

http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metric= s-00.txt

This describes the base and derived metrics which can be obtained from the = IPv6 PDM DO Extension Header.


2.  In TicToc:

http://www.ietf.org/internet-drafts/draft-ackermann-ticto= c-pdm-ntp-usage-00.txt

This describes how NTP may be implemented to support PDM.


The updates are as follows

1.  In 6man:

http://www.ietf.org/internet-drafts/draft-elkins-ippm= -pdm-metrics-00.txt

This is the layout of the PDM DO header.


2.  In v6ops:

http://www.ietf.org/internet-drafts/draft-elkin= s-v6ops-ipv6-packet-sequence-needed-01.txt

http://www.ietf.org/internet-drafts/draft-elkins= -v6ops-ipv6-pdm-recommended-usage-01.txt

http://www.ietf.org/internet-drafts/draft-elkins-= v6ops-ipv6-end-to-end-rt-needed-01.txt

These are background for the proposal.


Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

----- Forwarded Message -----
From: "internet-drafts=40ietf.org" <internet-drafts=40ietf.org>
To: Nalini Elkins <nalini.elkins=40insi= dethestack.com>; William Jouris <bill.jouris=40insideth= estack.com>
Sent: Thursday, October 3, 2013 8:04 PM
Subject: New Version Notification for = draft-elkins-ippm-pdm-metrics-00.txt


A new version of I-D, draft-elkins-ippm-pdm-metrics-00.txt
has been successfully submitted by Nalini Elkins and posted to the
IETF repository.

Filename:    draft-elkins-ippm-pdm-metrics
Revision:    00
Title:        IPPM Considerations for the IPv6 PDM = Extension Header
Creation date:    2013-10-03
Group:        Individual Submission
Number of pages: 14
URL:            http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt
Status:          http://datatracker.ietf.org/doc/draft-elkins-ippm-pdm-metrics
Htmlized:        http://tools.ietf.org/html/draft-elkins-ippm-pdm-metrics-00


Abstract:
  To diagnose performance and connectivity problems, metrics on = real
  (non-synthetic) transmission are critical for timely end-to-end
  problem resolution. Such diagnostics may be real-time or after = the
  fact, but must not impact an operational production network. = These
  metrics are defined in the IPv6 Performance and Diagnostic = Metrics
  Destination Option (PDM). The base metrics are: packet sequence
  number and packet timestamp. Other metrics may be derived from = these
  for use in diagnostics.  This document specifies such metrics, = their
  calculation, and usage.





Please note that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

The IETF Secretariat




The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

--_000_4FC37E442D05A748896589E468752CAA0CA77267PWN401EA160entc_-- From v6ops@globis.net Wed Oct 16 06:15:10 2013 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 CAC7F11E82A7; Wed, 16 Oct 2013 06:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3cjMEz5564x; Wed, 16 Oct 2013 06:15:10 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id B3F7B11E82AB; Wed, 16 Oct 2013 06:15:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id DF19687007F; Wed, 16 Oct 2013 15:15:00 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-eHjwW1gte4; Wed, 16 Oct 2013 15:15:00 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 915A9870073; Wed, 16 Oct 2013 15:15:00 +0200 (CEST) Message-ID: <525E9152.60209@globis.net> Date: Wed, 16 Oct 2013 15:14:58 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Nalini Elkins References: <20131015235832.2100.62094.idtracker@ietfa.amsl.com> <1381881831.35197.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> In-Reply-To: <1381881831.35197.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 18 Oct 2013 13:40:32 -0700 Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [ippm] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-03.txt 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, 16 Oct 2013 13:15:11 -0000 Nalini Elkins wrote: > All, > > I have updated the PDM specification to add a second PDM type which requires NO time synchronization. The draft for IPPM which describes how to calculate and use the values described in the PDM. The IPPM draft is: > > http://tools.ietf.org/html/draft-elkins-ippm-pdm-metrics-01 > > > I would appreciate any comments or feedback. > > > A new version of I-D, draft-elkins-6man-ipv6-pdm-dest-option-03.txt > has been successfully submitted by Nalini Elkins and posted to the > IETF repository. > > Filename: draft-elkins-6man-ipv6-pdm-dest-option > Revision: 03 > Title: IPv6 Performance and Diagnostic Metrics Destination Option > Creation date: 2013-10-15 > Group: Individual Submission > Number of pages: 18 > URL: http://www.ietf.org/internet-drafts/draft-elkins-6man-ipv6-pdm-dest-option-03.txt > Status: http://datatracker.ietf.org/doc/draft-elkins-6man-ipv6-pdm-dest-option > Htmlized: http://tools.ietf.org/html/draft-elkins-6man-ipv6-pdm-dest-option-03 > Diff: http://www.ietf.org/rfcdiff?url2=draft-elkins-6man-ipv6-pdm-dest-option-03 > > Abstract: > To diagnose performance and connectivity problems, metrics on real > (non-synthetic) transmission are critical for timely end-to-end > problem resolution. Such diagnostics may be real-time or after the > fact, but must not impact an operational production network. The base > metrics are: packet sequence number and packet timestamp. Metrics > derived from these will be described separately. This document solves > these problems with a new destination option, the Performance and > Diagnostic Metrics destination option (PDM). > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat I have read this draft. All in all it seems rather simplistic, and I can't help thinking that there's much more to this than is expressed in the draft. For example, the server time calculation seems to assume that a response packet has to be sent immediately by every application as soon as data has been processed: every response requires a response. What additional processing is required to cater for cases where the sender and the receiver simply have nothing to say to each other at that point in time? e.g. a simple poll response protocol that is triggered every minute would seem to suggest that there's a minimum of a sixty second server processing time in the poller, when in fact it's just not doing anything at all for this process. Likewise, the calculations for round trip time do not seem to take into account any packet drops or duplicates, which would seem to suggest to me that the protocol as described would report packet drops as additional latency, rather than any sort of protocol recovery/ retransmission timers being triggered. Wouldn't the PDM sequence numbers have to be linked to TCP sequence numbers when calculating stats? And for UDP you'd have no indication (or have to use some app specific sequence number or hash to detect forward progression of the flow)? -- Regards, RayH From v6ops@globis.net Wed Oct 16 07:14:28 2013 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 C9B3B11E81D3; Wed, 16 Oct 2013 07:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2e4v9xPSUB-k; Wed, 16 Oct 2013 07:14:28 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2322C11E81DB; Wed, 16 Oct 2013 07:14:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E4D05870074; Wed, 16 Oct 2013 16:14:24 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucbpHUt47nty; Wed, 16 Oct 2013 16:14:24 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id C2E69870073; Wed, 16 Oct 2013 16:14:24 +0200 (CEST) Message-ID: <525E9F3F.2020600@globis.net> Date: Wed, 16 Oct 2013 16:14:23 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Nalini Elkins References: <20131015235832.2100.62094.idtracker@ietfa.amsl.com> <1381881831.35197.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <525E9152.60209@globis.net> <1381930868.81291.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: <1381930868.81291.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 18 Oct 2013 13:40:32 -0700 Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [ippm] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-03.txt 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, 16 Oct 2013 14:14:28 -0000 > Nalini Elkins > 16 October 2013 15:41 >> I have read this draft. > >> All in all it seems rather simplistic, and I can't help thinking that >> there's much more to this than is expressed in the draft. > > Yes. There is. See below. Then I would humbly suggest that you consider keeping this as a clean standards track draft just defining the message formats for the transport (in 6man WG) = Section 1 & 2, and leave the use cases, architecture, and calculations to other informational drafts (e.g. in ippm) = Section 3,4. c.f. SNMP >> For example, the server time calculation seems to assume that a response >> packet has to be sent immediately by every application as soon as data >> has been processed: every response requires a response. > > Not at all. > >> What additional processing is required to cater for cases where the >> sender and the receiver simply have nothing to say to each other at that >> point in time? > > Frankly, other than keep-alives, I have not seen this. Please correct me if I am wrong. > > The logic for processing and making 'sense' of these metrics is much more complex than the fields to be sent. This is as it should be. The OS needs to send packets quickly. After the fact, we can take our time and do analysis. > > What needs to be handled (at a minimum) are the following cases. You may have more. > > 1. Host clocks not synchronized - done > 2. IP fragmentation > 3. Multiple sends from one side (multiple segments) > 4. Out of order segments (PSN will go negative) > 5. Retransmits (PSN will go negative) > 6. One–way transmit only (ex. FTP) (server delta will continually increase) > 7 Delayed acks > 8. ACKs preceeding send for another reason > 9 Proxy servers > 10. Full duplex traffic > 11. Keep alive (0 / 1 byte segments, larger segments) > 12. No response from other side (your case - which I believe to fall under Keep Alives) > , > > I have only provided the most basic case in this draft. But, have thought a great deal about these others and how they would be handled. I can provide packet flows for all these above to let you know how these can be handled. Again, if you have more cases, I welcome your input. 6. one way transmit only (e.g.real time transports and streaming protocols, although RTP has it's own timestamps based on NTP) 13. Drop without retransmit (real time transports) 14. Looped packets (where the same packet may pass the same point multiple times without duplication) 15. Multihoming via Shim6 > Additionally, I am in no way suggesting that this be the ONLY metric that is used to calculate errors or performance. For example, if you look at my definition of the "Retransmit Duplication" metric, you will see that TCP sequence number is used in addition to the Packet Sequence Number to good effect. > > -- Regards, RayH From internet-drafts@ietf.org Sat Oct 19 12:47:55 2013 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 3794911E828D; Sat, 19 Oct 2013 12:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPCAj9wg7S1R; Sat, 19 Oct 2013 12:47:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C69D911E827B; Sat, 19 Oct 2013 12:47:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131019194754.9630.50753.idtracker@ietfa.amsl.com> Date: Sat, 19 Oct 2013 12:47:54 -0700 Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-testplan-rfc2680-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 19:47:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group of t= he IETF. Title : Test Plan and Results for Advancing RFC 2680 on the Stan= dards Track Author(s) : Len Ciavattone Ruediger Geib Al Morton Matthias Wieser Filename : draft-ietf-ippm-testplan-rfc2680-04.txt Pages : 27 Date : 2013-10-19 Abstract: This memo proposes to advance a performance metric RFC along the standards track, specifically RFC 2680 on One-way Loss Metrics. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2680. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-testplan-rfc2680 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-testplan-rfc2680-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-testplan-rfc2680-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From denglingli@chinamobile.com Sun Oct 20 20:10:15 2013 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 00D0011E847B for ; Sun, 20 Oct 2013 20:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.132 X-Spam-Level: ** X-Spam-Status: No, score=2.132 tagged_above=-999 required=5 tests=[AWL=2.057, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvtyR17wITRH for ; Sun, 20 Oct 2013 20:10:10 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 30A3911E8478 for ; Sun, 20 Oct 2013 20:10:07 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee252649ab7db1-7fdb1; Mon, 21 Oct 2013 11:08:39 +0800 (CST) X-RM-TRANSID: 2ee252649ab7db1-7fdb1 Received: from cmccPC (unknown[10.2.52.235]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee352649ab6e4e-0eeda; Mon, 21 Oct 2013 11:08:39 +0800 (CST) X-RM-TRANSID: 2ee352649ab6e4e-0eeda From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: Date: Mon, 21 Oct 2013 11:10:13 +0800 Message-ID: <01ad01cece0b$0fa84090$2ef8c1b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7NMX8cFbuTcSSvQneB583saBailgA2Jjhw Content-Language: zh-cn Subject: [ippm] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-deng-ippm-wireless-00=2Etxt?= 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, 21 Oct 2013 03:10:15 -0000 Hi all, A newly uploaded draft is requesting for your comments. It talks about the potential problems and requirements for performance = measurements in mobile networks, and hopes to gain more attention and = suggestions. In particular, it argues that the pervasive adopted device pools (for = the sake of load balancing and scalability) dictates a viable passive = measurements method, and more stable metrics may be needed for = performance measurements in mobile networks. BR Lingli -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2013=E5=B9=B410=E6=9C=8820=E6=97=A5 9:03 =E6=94=B6=E4=BB=B6=E4=BA=BA: Deng Lingli; Lingli Deng; Zhen Cao =E4=B8=BB=E9=A2=98: New Version Notification for = draft-deng-ippm-wireless-00.txt A new version of I-D, draft-deng-ippm-wireless-00.txt has been successfully submitted by Lingli Deng and posted to the IETF repository. Filename: draft-deng-ippm-wireless Revision: 00 Title: Problem Statement for IP measurement in mobile networks Creation date: 2013-10-18 Group: Individual Submission Number of pages: 6 URL: = http://www.ietf.org/internet-drafts/draft-deng-ippm-wireless-00.txt Status: = http://datatracker.ietf.org/doc/draft-deng-ippm-wireless Htmlized: http://tools.ietf.org/html/draft-deng-ippm-wireless-00 Abstract: This document analyzes the potential problems of applying existing IP-based performance measurement methods to wireless accessing environments. It suggests that more robust passive measuring methods and performance metrics are needed. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From internet-drafts@ietf.org Mon Oct 21 04:50:55 2013 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 C439B11E8170; Mon, 21 Oct 2013 04:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcarE709LoH6; Mon, 21 Oct 2013 04:50:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 900D911E84BD; Mon, 21 Oct 2013 04:50:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021115030.29534.21461.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 04:50:30 -0700 Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-ipsec-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 11:50:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group of t= he IETF. Title : Network Performance Measurement for IPsec Author(s) : Kostas Pentikousis Yang Cui Emma Zhang Filename : draft-ietf-ippm-ipsec-01.txt Pages : 17 Date : 2013-10-21 Abstract: IPsec is a mature technology with several interoperable implementations. Indeed, the use of IPsec tunnels is increasingly gaining popularity in several deployment scenarios, not the least in what used to be solely areas of traditional telecommunication protocols. Wider IPsec deployment calls for mechanisms and methods that enable tunnel end-users, as well as operators, to measure one- way and two-way network performance in a standardized manner. Unfortunately, however, standard IP performance measurement security mechanisms cannot be readily used with IPsec. This document makes the case for employing IPsec to protect the One-way and Two-Way Active Measurement Protocols (O/TWAMP) and proposes a method which combines IKEv2 and O/TWAMP as defined in RFC 4656 and RFC 5357, respectively. This specification aims, on the one hand, to ensure that O/TWAMP can be secured with the best mechanisms we have at our disposal today while, on the other hand, it facilitates the applicability of O/TWAMP to networks that have already deployed IPsec. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-ipsec-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-ipsec-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From k.pentikousis@eict.de Mon Oct 21 05:01:26 2013 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 D430D11E84F9; Mon, 21 Oct 2013 05:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srI-osX0dzK2; Mon, 21 Oct 2013 05:01:22 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 978A911E84DD; Mon, 21 Oct 2013 05:01:10 -0700 (PDT) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 551831FF54; Mon, 21 Oct 2013 14:01:09 +0200 (CEST) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 034EA37819D; Mon, 21 Oct 2013 14:01:09 +0200 (CEST) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Mon, 21 Oct 2013 14:01:08 +0200 From: Konstantinos Pentikousis To: "ippm@ietf.org" Date: Mon, 21 Oct 2013 14:01:06 +0200 Thread-Topic: draft-ietf-ippm-ipsec-01 Thread-Index: Ac7OVTk8AzkEO6uuRee1VRb7bH9Vnw== Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10BFCB854@SBS2008.eict.local> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: [ippm] draft-ietf-ippm-ipsec-01 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, 21 Oct 2013 12:01:27 -0000 Dear all, We have updated the draft on "Network Performance Measurement for IPsec" (h= ttp://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec), and we would like to= hear your comments/suggestions/text contributions as we proceed towards th= e corresponding milestone in December. One of the main items still to be determined by the IPPM WG would be which = optimization to adopt in the end. We're looking forward to the discussion i= n Vancouver and on the mailing list. Best regards, Kostas From nalini.elkins@insidethestack.com Mon Oct 21 15:58:39 2013 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 70B2511E87D8 for ; Mon, 21 Oct 2013 15:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=-1.181, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lULYPyFkewtq for ; Mon, 21 Oct 2013 15:58:28 -0700 (PDT) Received: from nm1.access.bullet.mail.bf1.yahoo.com (nm1.access.bullet.mail.bf1.yahoo.com [216.109.114.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8736411E87BB for ; Mon, 21 Oct 2013 15:58:22 -0700 (PDT) Received: from [66.196.81.156] by nm1.access.bullet.mail.bf1.yahoo.com with NNFMP; 21 Oct 2013 22:58:21 -0000 Received: from [66.196.81.129] by tm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 21 Oct 2013 22:58:21 -0000 Received: from [127.0.0.1] by omp1005.access.mail.bf1.yahoo.com with NNFMP; 21 Oct 2013 22:58:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 759889.68060.bm@omp1005.access.mail.bf1.yahoo.com Received: (qmail 23180 invoked by uid 60001); 21 Oct 2013 22:58:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1382396301; bh=gz7bsWA3BKYe3p8KchJBGACAUiJhFU+zTjXy2NOwom0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qdS7Q3Cy6lMzupXUJmmljNB/YrBNx/+yUBc9iKsGxxBNs+QEs/TRb6JXap2xfY/PkeeysCwQHmkjaMwChshIp6i3ToV3ebMokr17E2MESN6uvj8MCPhtQfUaNmCMWSfJQ6rK6WeNIstMipirz3dNoU36Sp54UDZtl8xIFXOlPhM= X-YMail-OSG: 3qSutDkVM1m_rKOwD95QcNtpkvhcHeb9fl8kjbNU_zTepCz HpYBLoU8elofJ3oS18.BqVNg3h0TwGU5CANcnT30cosgpoOj1TSWC2l6vJX9 QFFrri7PMeDKffpZuH7mWWphetrFM6HF_vtVjXdEoRTmgmsGsnf00eGO2FAN l_a3a5fvrZZhH2b3DQPd06lhJIHNz.YKEjgpzggYc6jP7eJrxGnsJONWudMI tcqOh4R0NbruuSL9Q77wuqbxplQBmXM2dVQvLeKAhpGEPbkX16cR70wEf3aD WeoDj_HhOyKW.JLB6lKl4vY8vWYjE01qKOTYTbebOFmeM3RA.7gGGNsIaadq WPbIiC9BI8yLhGpaqXmVwgegUX84grXgjG1jpeYaguRYMfohIwQeWE_Xm0Vx SJvQE4RQCF4u2wFTfwVcpCduWql6lWyhAOmgBJXEZEWlt0HivW7Y3R6UJEGE EiNcNcAskPO9ZAoR7PdyPPTT.62TL5QJ3yzspqcO0sEJTkGVlSCRejis3XT. jGnv6I6YKq3lRqgv4Fs8JcEc_nc6HGHXwevqBtG2UF5ky5khqh3MaEHDspoc oSWu003NfORL2l8w- Received: from [24.130.37.147] by web2801.biz.mail.ne1.yahoo.com via HTTP; Mon, 21 Oct 2013 15:58:20 PDT X-Rocket-MIMEInfo: 002.001, Cj7CoDEpIGVuY29kaW5nIGhhcyB0byBiZSBmYXN0LCBidXQgZGVjb2RpbmcgZG9lcyBub3QKClRydWUKCj7CoDIpIGEgbm9kZSdzIGNsb2NrIGNvdWxkIGJlIGVpdGhlciBpbiBvdXIgb3V0IG9mIHN5bmNoIHdpdGggc29tZSBub3Rpb25hbAo.wqBtYXN0ZXIgY2xvY2sgKGUuZy4gdmlhIE5UUCkKPsKgMykgdHdvIGNsb2NrcyBjb3VsZCBiZSBpbiBzeW5jaCB0byBhIG1hc3RlciBzb3VyY2UsIGJ1dCB0aGUgbWFzdGVyCj7CoHNvdXJjZXMgbWF5IHRoZW1zZWx2ZXMgbm90IHNoYXJlIGEgY29tbW9uIHNvdXJjZSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> Message-ID: <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Date: Mon, 21 Oct 2013 15:58:20 -0700 (PDT) From: Nalini Elkins To: Ray Hunter In-Reply-To: <5263C783.1080001@globis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [ippm] [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:58:39 -0000 =0A>=A01) encoding has to be fast, but decoding does not=0A=0ATrue=0A=0A>= =A02) a node's clock could be either in our out of synch with some notional= =0A>=A0master clock (e.g. via NTP)=0A>=A03) two clocks could be in synch to= a master source, but the master=0A>=A0sources may themselves not share a c= ommon source (one sourced from GPS,=0A>one from DCF77)=0A>4) the key to bei= ng able to perform the end to end calculations is=0A>whether two communicat= ing nodes are synchronised to the same master=0A>clock (within some level o= f error/jitter)=0A>5) the absolute time is not particularly important=0A=0A= =0AThis is true for PDM 1 only. =A0PDM 2 does not require time synchronizat= ion.=0A=0A>=A0Q1. Why do you want to encode differences as deltas in the ca= se of an=A0unsynchronised/ free running clock?=0A>=A0Isn't that slow, and d= ifficult for hardware implementations to achieve=A0(e.g. TCP offload)?=A0Do= esn't it also require maintaining large amounts of state in the=A0sending n= ode.=0A>=0A=0A1.=A0I think that it is going to be interesting to see how ha= rdware is going to handle TCP offload with IPv6 extension headers. =A0 I do= not see why PDM 2 would be so much harder than PDM 1 for an OS.=0ACan you = tell me which end host operating systems are doing TCP offload in hardware?= =A0=A0=0A=0AI know some OS's which process TCP segmentation in hardware. = =A0 =A0But at this point, the packet is already crafted. =A0Also some do IP= checksum offload in hardware but that does not apply to IPv6 as there is n= o IP header checksum.=0A=0A=0A2. =A0End hosts already maintain quite a bit = of state. =A0Every OS has control blocks to handle events such as TCP dupli= cate packets, round trip time, congestion window, etc. =A0 We are NOT sugge= sting=0Athat the PDM headers be used in middle boxes. =A0That is, we are NO= T asking routers to maintain state.=0A=0A=0A>=A0Why not just encode the tim= estamp as-is and perform the appropriate=A0difference calculation during de= coding?=0A=0AIf clocks are out of synch, you could end up having it look li= ke you received the packet before you sent it.=0A=0A>=A0Q2. Why do you need= two separate packet formats at all?=0A=0A>=A0Why not have a common format = for all cases, containing a timestamp based=0A>on the local clock, plus an = optional field containing a flag that states=0A>if the local timestamp is c= oordinated to some master clock, plus an=0A>identifier for the master clock= .=0A=0A>You could then encode whether a node had a free-running clock (case= 2),=0A>a synchronised clock (case 1), and whether it was synched via NTP t= o=0A>some stratum 0 source e.g. GPS, and also some identification of the=0A= >stratum 1 source (IPv6 address).=0A=0A>Two communicating nodes could then = use e.g. NTP trace to see if they=0A>shared a common clock source or not, b= efore performing their calculations.=0A=0AWe are trying to craft a solution= with PDM 2 for those situations where time synchronization is not practica= l, possible or desired.=0A From internet-drafts@ietf.org Mon Oct 21 16:24:01 2013 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 554A01F0ED5; Mon, 21 Oct 2013 16:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nci3gGGQ8tT9; Mon, 21 Oct 2013 16:24:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A4B1F0D5E; Mon, 21 Oct 2013 16:24:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021232400.32508.61974.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 16:24:00 -0700 Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-model-based-metrics-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 23:24:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group of t= he IETF. Title : Model Based Bulk Performance Metrics Author(s) : Matt Mathis Al Morton Filename : draft-ietf-ippm-model-based-metrics-01.txt Pages : 38 Date : 2013-10-21 Abstract: We introduce a new class of model based metrics designed to determine if a long network path can meet predefined end-to-end application performance targets by applying a suite of IP diagnostic tests to successive subpaths. The subpath at a time tests are designed to exclude all known conditions which might prevent the full end-to-end path from meeting the user's target application performance. This approach makes it possible to to determine the IP performance requirements needed to support the desired end-to-end TCP performance. The IP metrics are based on traffic patterns that mimic TCP or other transport protocol but are precomputed independently of the actual behavior of the transport protocol over the subpath under test. This makes the measurements open loop, eliminating nearly all of the difficulties encountered by traditional bulk transport metrics, which fundamentally depend on congestion control equilibrium behavior. A natural consequence of this methodology is verifiable network measurement: measurements from any given vantage point can be verified by repeating them from other vantage points. Formatted: Mon Oct 21 15:42:35 PDT 2013 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-model-based-metrics There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-model-based-metrics-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-model-based-metrics-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From acmorton@att.com Mon Oct 21 17:27:18 2013 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 359AC11E86BB for ; Mon, 21 Oct 2013 17:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbJfSsGaN5k1 for ; Mon, 21 Oct 2013 17:27:10 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBAA11E829C for ; Mon, 21 Oct 2013 17:27:05 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id B858612089F; Mon, 21 Oct 2013 20:27:04 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-azure.research.att.com (Postfix) with ESMTP id DEFB9E28AD; Mon, 21 Oct 2013 20:27:04 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::a44a:8177:9a5d:ac00%15]) with mapi; Mon, 21 Oct 2013 20:26:43 -0400 From: "MORTON, ALFRED C (AL)" To: "Ackermann, Michael" , Nalini Elkins , "ippm@ietf.org" Date: Mon, 21 Oct 2013 20:26:42 -0400 Thread-Topic: [ippm] Fw: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt Thread-Index: AQHOyayMqQBwUbYhkUaj9bxzxFlrf5n11TpggAoLe6A= Message-ID: <2845723087023D4CB5114223779FA9C8AB2EAB14@njfpsrvexg8.research.att.com> References: <20131004030407.30291.83858.idtracker@ietfa.amsl.com>, <1380892227.93952.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2845723087023D4CB5114223779FA9C8AAD39FC2@njfpsrvexg8.research.att.com> <1381844622.97264.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0CA77267@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0CA77267@PWN401EA160.ent.corp.bcbsm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C8AB2EAB14njfpsrvexg8rese_" MIME-Version: 1.0 Cc: Sigfrido Perdomo , Bill Jouris Subject: Re: [ippm] Fw: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt 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, 22 Oct 2013 00:27:18 -0000 --_000_2845723087023D4CB5114223779FA9C8AB2EAB14njfpsrvexg8rese_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Michael, Regarding one of your questions below: My question for you is whether you think we SHOULD craft additional PDM fun= ction that CAN be populated and/or utilized expressly for or by Middle Box= es? This would likely involve more complexity and overhead, but may be warrante= d if associated value is perceived. Yes, but it has been attempted by dedicated flow monitoring appliances. I did some research and reading about this topic today. Have a look at: http://tools.ietf.org/html/draft-mornulo-ippm-registry-columns-01#section-6 and the references. This is a case of completely passive RTT measurement on TCP(SYN/SYN_ACK) request response pairs, but with the addition of the IPv6 PDM, one could attribute the delay properly to network beyond the monitoring point and server (the later doesn't change). The main point is that it should be do-able to do the correlations mid-path, without help from the app (as you would have at the server end). Of course, there's a cost for these middlebox monitoring instances, and you have to have sufficient coverage to observe both directions of the connection. So, what's needed is a compelling case where troubleshoo= ting is enhanced by the middlebox measurements, perhaps when multiple networks are involved in the path. hope this helps, Al From: Ackermann, Michael [mailto:MAckermann@bcbsm.com] Sent: Tuesday, October 15, 2013 12:41 PM To: Nalini Elkins; MORTON, ALFRED C (AL); ippm@ietf.org Cc: Sigfrido Perdomo; keven.haining@usbank.com; Bill Jouris Subject: RE: [ippm] Fw: New Version Notification for draft-elkins-ippm-pdm-= metrics-00.txt Hi Al, Echoing Nalini's thoughts regarding your great comments/questions and how = excited we are about the potential of working with you and your teams. Nalini's answers are great in my view and I have one comment/question on th= e topic of "Middle Boxes", which in my view includes Routers and Firewalls.= As Nalini said, the PDM was conceived to be populated and utilized pri= marily by End Points, which will be Hosts/IP Stacks of various types. = The biggest function we had in mind for the Middle Boxes, was to just not d= rop or alter the PDM. My question for you is whether you think we SHOU= LD craft additional PDM function that CAN be populated and/or utilized exp= ressly for or by Middle Boxes? This would likely involve more complexity and overhead, but may be warrante= d if associated value is perceived. I would also like endorse Nalini's answer on your great and very fascinatin= g question about The APP, TCP and other time breakdowns. As a lowly cu= stomer/end user (while Nalini is a Diagnostic Software Expert), I share her= view on the value of the "Network Triage". Knowing whether the time is= being spent in the Host, Network and in what direction, is critically valu= able. This may tell you all you need to know, or other tools take over a= t that point for more granular diagnostics. So, in my view that level of= granular diagnostics is beyond the scope of the PDM, but would luv, luv, l= uv to talk more about this with you. Thanks again and look forward to seeing you in Vancouver! Mike From: Nalini Elkins [mailto:nalini.elkins@insidethestack.com] Sent: Tuesday, October 15, 2013 9:44 AM To: MORTON, ALFRED C (AL); ippm@ietf.org Cc: Sigfrido Perdomo; keven.haining@usbank.com; Bill Jouris; Ackermann, Mic= hael Subject: Re: [ippm] Fw: New Version Notification for draft-elkins-ippm-pdm-= metrics-00.txt Al, Thanks for your thorough examination and great comments. My responses are = inline. Also, if you have time in Vancouver, Mike & I would like to ask y= ou to have lunch or dinner on us. It is the least we can do for all your = help! Please let us know if you have a free day. >Early in the Intro, the various time/number fields are referred to as "bas= e metrics" themselves. >I know you'll want to clarify that (they are just fields). Sure. >In section 1.2: in addition to time and seq number for current packet: > PSNLR : Packet Sequence Number Last Received > TSLR : Timestamp Last Received >the device supplying the header appears to need to maintain flow state to = add >these "last packet" fields. A very strong justification is probably needed= . >Later, I see that the Server host essentially has to store the fields acro= ss >request-response pairs. Lower and higher layers need to work together, >somehow. The Destination Options Header is created only by the OS's at the end point= s. That is, the Microsofts, linuxes, and IBM's of the world. The OS at th= e end point already maintains state. If you think of TCP TimeWait status = for example. The connection is in TimeWait status for 2 * MSL. So, obvio= usly state is being maintained. Anyway, all the OS's have control blocks a= ssociated with each active connection. Now, there is going to be some discussion by the OS vendors about non-TCP p= rotocols! I have participated in those discussions with IBM in a former li= fe (when they OEMed a product of mine & I wanted them to do something!) bu= t I believe that they are persuadable. I am guessing that this informatio= n is already being maintained. All we are asking for is for it to be expos= ed. Our header is not for middle boxes. We are not asking for router, etc. to = maintain state in this way. >In Section 3.1 and 3.2, it's not clear which PDM time-stamps support the (= round-trip delay >and server delay) metrics. When you look at RFC2681, it should be fairly = clear where >the time stamps are applied, and that needs to carry though here (though I= see it later >in the example). I will clarify. >Looking at the example in section 4, there can be a significant delay betw= een when >the application layer transfers packets to TCP's send buffer and when the = packets are >actually sent "on the wire" (as we say in IPPM), which happens after the I= P header is >applied (or most of the header, in some cases). How would accuracy be main= tained >across all the different layers? >Maybe another way to phrase the question is this: >How does the process that adds the PDM header (with last Seq number 25) kn= ow >which packet to add it to? There are 2 questions here. First, it will be the IP layer adding the time= s. Yes, I know that it is a "gross" measurement comprising of a number of = components. But, then so is one-way delay. That is, there are multiple c= omponents within the path. The purpose of our measurements is to allow th= e diagnostician to do very quick triage. That is, to say, is the problem i= n the network or the server? Then, we hand the problem off to the right gr= oup who can runmore detailed diagnostic tests. In our experience, this is a very valuable kind of measurement to have. A = great deal of time, effort and money is spent at large end user sites to de= termine just this. Anecdotal evidence tells me that this is true for home= users of the Internet also. My working life has been spent at large data= centers, so that I can answer to without any hesitation. > I note that there is IPR declared on this draft, and licensing is not cle= ar. Yes, we do have IPR. I hope I have declared it properly! Please let me kn= ow if I have not. We have not decided on the exact nature of the licensing= but it will be very reasonable. We want the technology adopted. There = are more advanced metrics which can be created from these which is the primary = reason for the IPR. BTW, we are starting to engage in discussions also with folks looking at a = new WG. https://sites.google.com/site/transportprotocolservices/home/charte= r-proposal-before-bof We feel our metrics / header can help with a unified Simple Congestion Cont= rol (SCC) and Inter-Layer Communication (ILC). That is some of our other = work. The above group seems to feel that work would fit in with their eff= orts! I feel that the fields we propose are simple yet very powerful. Man= y uses can be made of them. I can tell you more on this, if you have inte= rest. ________________________________________ From: ippm-bounces@ietf.org [ippm-bounces@iet= f.org] On Behalf Of Nalini Elkins [nalini.elk= ins@insidethestack.com] Sent: Friday, October 04, 2013 9:10 AM To: WG (v6ops@ietf.org); 6man WG; ippm@ietf.org Cc: Sigfrido Perdomo; keven.haining@usbank.com; Bill Jouris; Ackermann Michael Subject: [ippm] Fw: New Version Notification for draft-elkins-ippm-p= dm-metrics-00.txt We have submitted a number of drafts. Some are new and some are updates to= our existing PDM proposal. We would appreciate any comments, questions, a= nd corrections from the lists. The new ones are: 1. In IPPM: http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt This describes the base and derived metrics which can be obtained from the = IPv6 PDM DO Extension Header. 2. In TicToc: http://www.ietf.org/internet-drafts/draft-ackermann-tictoc-pdm-ntp-usage-00= .txt This describes how NTP may be implemented to support PDM. The updates are as follows 1. In 6man: http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt This is the layout of the PDM DO header. 2. In v6ops: http://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-packet-sequence= -needed-01.txt http://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-pdm-recommended= -usage-01.txt http://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-end-to-end-rt-n= eeded-01.txt These are background for the proposal. Thanks, Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com ----- Forwarded Message ----- From: "internet-drafts@ietf.org" > To: Nalini Elkins >; William Jouris > Sent: Thursday, October 3, 2013 8:04 PM Subject: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt A new version of I-D, draft-elkins-ippm-pdm-metrics-00.txt has been successfully submitted by Nalini Elkins and posted to the IETF repository. Filename: draft-elkins-ippm-pdm-metrics Revision: 00 Title: IPPM Considerations for the IPv6 PDM Extension Header Creation date: 2013-10-03 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-m= etrics-00.txt Status: http://datatracker.ietf.org/doc/draft-elkins-ippm-pdm-metr= ics Htmlized: http://tools.ietf.org/html/draft-elkins-ippm-pdm-metrics-0= 0 Abstract: To diagnose performance and connectivity problems, metrics on real (non-synthetic) transmission are critical for timely end-to-end problem resolution. Such diagnostics may be real-time or after the fact, but must not impact an operational production network. These metrics are defined in the IPv6 Performance and Diagnostic Metrics Destination Option (PDM). The base metrics are: packet sequence number and packet timestamp. Other metrics may be derived from these for use in diagnostics. This document specifies such metrics, their calculation, and usage. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this communicat= ion is directed. If you are not the intended recipient, you are hereby noti= fied that any viewing, copying, disclosure or distribution of this informat= ion is prohibited. Please notify the sender, by electronic mail or telephon= e, of any unintended receipt and delete the original message without making= any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are no= nprofit corporations and independent licensees of the Blue Cross and Blue S= hield Association. --_000_2845723087023D4CB5114223779FA9C8AB2EAB14njfpsrvexg8rese_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Michael,

 

Regarding one of your questions belo= w:

My question for you is = whether you think we SHOULD craft additional PDM function that  CAN be= populated and/or utilized expressly for or by Middle Boxes?  

This would likely involve m= ore complexity and overhead, but may be warranted if associated value is pe= rceived.  

 

Yes, but it has been attempted by dedicated flow monitoring appliance= s.

I did some research and reading about this top= ic today.

Have a look at:

http://tools.ietf.org/html/draft-mornulo-ippm-registry-colu= mns-01#section-6

and the references.

 

This is a case of compl= etely passive RTT measurement on TCP(SYN/SYN_ACK)

request response pairs, but with the addition of the IPv6 PDM, one could

attribute the delay properly to network beyond the= monitoring point

and server (the later doesn't = change).  The main point is that it should be

(as you would have at the server end).

 

Of course, there's a cost for t= hese middlebox monitoring instances,

and you have= to have sufficient coverage to observe both directions <= /p>

of the connection. So, what's needed is a compelling case where tro= ubleshooting

is enhanced by the middlebox measure= ments, perhaps when multiple networks

are involve= d in the path.

 

h= ope this helps,

Al

 

 

 <= /o:p>

From: Ackermann, Michael= [mailto:MAckermann@bcbsm.com]
Sent: Tuesday, October 15, 2013 1= 2:41 PM
To: Nalini Elkins; MORTON, ALFRED C (AL); ippm@ietf.orgCc: Sigfrido Perdomo; keven.haining@usbank.com; Bill Jouris
= Subject: RE: [ippm] Fw: New Version Notification for draft-elkins-ippm-= pdm-metrics-00.txt

 

Hi Al,

=

 

Echoing Nalini’s thoughts regarding  your great comment= s/questions and how excited we are about the potential of working with you = and your teams. 

 

Nalini’s answers= are great in my view and I have one comment/question on the topic of ̶= 0;Middle Boxes”, which in my view includes Routers and Firewalls.&nbs= p;    As Nalini said, the PDM was conceived to be populated = and utilized primarily  by End Points, which will be Hosts/IP Stacks o= f various types.     The biggest function we had in min= d for the Middle Boxes, was to just not drop or alter the PDM.  &= nbsp;   My question for you is whether you think we SHOULD craft = additional PDM function that  CAN be populated and/or utilized express= ly for or by Middle Boxes?  

This would likely involve more complexity and overhead, but m= ay be warranted if associated value is perceived.  

 

I would also like endorse Nalini’s answer on your= great and very fascinating question about The APP, TCP and other time brea= kdowns.      As a lowly customer/end user (while N= alini is a Diagnostic Software Expert), I share her view on the value of th= e “Network Triage”.     Knowing whether the= time is being spent in the Host, Network and in what direction, is critica= lly valuable.    This may tell you all you need to know, or = other tools take over at that point for more granular diagnostics. &nb= sp;  So, in my view that level of granular diagnostics is beyond the s= cope of the PDM, but would luv, luv, luv to talk more about this with you.&= nbsp; 

 

Thanks again and look forward to= seeing you in Vancouver!

=  

Mike

 

 

 

From: Nalini Elk= ins [mailto:nalini.elkins@insidethestack.com]
Sent: Tuesday, Oct= ober 15, 2013 9:44 AM
To: MORTON, ALFRED C (AL); ippm@ietf.orgCc: Sigfrido Perdomo; keven.haining@usbank.com; Bill Jouris; Ackerm= ann, Michael
Subject: Re: [ippm] Fw: New Version Notification for= draft-elkins-ippm-pdm-metrics-00.txt

 

Al,

 

Thanks for your thorough = examination and great comments.  My responses are inline.   Also,= if you have time in Vancouver, Mike & I would like to ask you to have = lunch or dinner on us.   It is the least we can do for all your help! =  Please let us know if you have a free day.

 

<= div>


>Early in the Intro, the various time/number fields= are referred to as "base metrics" themselves.
>I know you'= ll want to clarify that (they are just fields).

=

 

Sure.

 

>In section 1.2: in ad= dition to time and seq number for current packet:

 >   =              PSNLR : Packet Sequence Num= ber Last Received
 >             &= nbsp; TSLR  : Timestamp Last Received

>the device supplying = the header appears to need to maintain flow state to add
>these "= ;last packet" fields. A very strong justification is probably needed. =
>Later, I see that the Server host essentially has to store the fiel= ds across
>request-response pairs. Lower and higher layers need to w= ork together,
>somehow.

The Destination Options Header is crea= ted only by the OS's at the end points.  That is, the Microsofts, linu= xes, and IBM's of the world.  The OS at the end point already maintain= s state.   If you think of TCP TimeWait status for example.   The= connection is in TimeWait status for 2 * MSL.  So, obviously state is= being maintained.  Anyway, all the OS's have control blocks associate= d with each active connection.

 =

Now, there is going to be some discussion by t= he OS vendors about non-TCP protocols!  I have participated in those d= iscussions with IBM in a former life (when they OEMed a product of mine &am= p; I wanted them to do something!)  but I believe that they are persua= dable.   I am guessing that this information is already being maintain= ed.  All we are asking for is for it to be exposed.<= /p>

 

Our header is not = for middle boxes.  We are not asking for router, etc. to maintain stat= e in this way.


>In Section 3.1 and 3.2, it's not clear which = PDM time-stamps support the (round-trip delay
>and server delay) metr= ics. When you look at  RFC2681, it should be fairly clear where
&g= t;the time stamps are applied, and that needs to carry though here (though = I see it later
>in the example).

 

I will clarify.

<= /div>

 

>Looking at the examp= le in section 4, there can be a significant delay between when
>the a= pplication layer transfers packets to TCP's send buffer and when the packet= s are
>actually sent "on the wire" (as we say in IPPM), whi= ch happens after the IP header is
>applied (or most of the header, in= some cases). How would accuracy be maintained
>across all the differ= ent layers?

>Maybe another way to phrase the question is this:>How does the process that adds the PDM header (with last Seq number 2= 5) know
>which packet to add it to? 

 

There are 2 questions here. =  First, it will be the IP layer adding the times.  Yes, I know th= at it is a "gross" measurement comprising of a number of componen= ts.  But, then so is one-way delay.  That is,  there are mul= tiple components within the path.   The purpose of our measurements is= to allow the diagnostician to do very quick triage.  That is, to say,= is the problem in the network or the server?  Then, we hand the probl= em off to the right group who can runmore detailed diagnostic tests.  =  

 

<= div>

In our experience, this is a very valuable kind of measurement to have= .  A great deal of time, effort and money is spent at large end user s= ites to determine just this.   Anecdotal evidence tells me that this i= s true for home users of the Internet also.   My working life has been= spent at large data centers, so that I can answer to without any hesitatio= n.

 

=

> I note that there is IPR declared on this draft, and licensing i= s not clear.

 

<= /div>

Yes, we do have IPR.  I hope I have declared it properly! &= nbsp;Please let me know if I have not.  We have not decided on the exa= ct nature of the licensing but it will be very reasonable.  We want th= e technology adopted.    There are

more advanced metrics which can be created from these which is the prima= ry reason for the IPR.

 

BTW, we are starting to engage in discussions also wit= h folks looking at a new WG. https://sites.g= oogle.com/site/transportprotocolservices/home/charter-proposal-before-bof


________________________________________
From: ippm-bounces@ietf.org [ippm-bounces@ietf.org] On Behalf Of Nalin= i Elkins [nalini.elkins= @insidethestack.com]
Sent: Friday, October 04, 2013 9:10 AM
To: W= G (v6ops@ietf.org); 6man WG; ippm@ietf.org
Cc: Sigfrido Perdomo; keven.haining@usbank.com; Bill Jo= uris; Ackermann Michael
Subject: [ippm] Fw: New Version Notification for=         draft-elkins-ippm-pdm-metrics-00.txt

We = have submitted a number of drafts.  Some are new and some are updates = to our existing PDM proposal.  We would appreciate any comments, quest= ions, and corrections from the lists.


The new ones are:

1= .  In IPPM:

http://www.ietf.org/internet-drafts/draft= -elkins-ippm-pdm-metrics-00.txt

This describes the base and deri= ved metrics which can be obtained from the IPv6 PDM DO Extension Header.

2.  In TicToc:

http://www.ietf.org/in= ternet-drafts/draft-ackermann-tictoc-pdm-ntp-usage-00.txt

This d= escribes how NTP may be implemented to support PDM.


The updates = are as follows

1.  In 6man:

= http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt

This is the layout of the PDM DO header.


2.  In v6= ops:

http://www.ietf.org/internet-drafts/= draft-elkins-v6ops-ipv6-packet-sequence-needed-01.txt

http://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6= -pdm-recommended-usage-01.txt

http://ww= w.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-end-to-end-rt-needed-01.= txt

These are background for the proposal.


Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

----- Forwarded Message -----
From: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
To: Nal= ini Elkins <nalini.e= lkins@insidethestack.com>; William Jouris <bill.jouris@insidethestack.com>
Sent:= Thursday, October 3, 2013 8:04 PM
Subject: New Version Notification for= draft-elkins-ippm-pdm-metrics-00.txt


A new version of I-D, draf= t-elkins-ippm-pdm-metrics-00.txt
has been successfully submitted by Nali= ni Elkins and posted to the
IETF repository.

Filename:  &nbs= p; draft-elkins-ippm-pdm-metrics
Revision:    00
Title:&nbs= p;       IPPM Considerations for the IPv6 PDM Extension Head= er
Creation date:    2013-10-03
Group:      =   Individual Submission
Number of pages: 14
URL:    &n= bsp;       http://www.ietf.org/i= nternet-drafts/draft-elkins-ippm-pdm-metrics-00.txt
Status:  &n= bsp;       http://datatracker.ietf.org/doc/draft-elkins-ippm-= pdm-metrics
Htmlized:        http= ://tools.ietf.org/html/draft-elkins-ippm-pdm-metrics-00


Abst= ract:
  To diagnose performance and connectivity problems, metrics = on real
  (non-synthetic) transmission are critical for timely end-= to-end
  problem resolution. Such diagnostics may be real-time or a= fter the
  fact, but must not impact an operational production netw= ork. These
  metrics are defined in the IPv6 Performance and Diagno= stic Metrics
  Destination Option (PDM). The base metrics are: pack= et sequence
  number and packet timestamp. Other metrics may be der= ived from these
  for use in diagnostics.  This document speci= fies such metrics, their
  calculation, and usage.



<= br>
Please note that it may take a couple of minutes from the time of su= bmission
until the htmlized version and diff are available at tools.ietf= .org<http://tools.i= etf.org/>.

The IETF Secretariat


=

 

Th= e information contained in this communication is highly confidential and is= intended solely for the use of the individual(s) to whom this communicatio= n is directed. If you are not the intended recipient, you are hereby notifi= ed that any viewing, copying, disclosure or distribution of this informatio= n is prohibited. Please notify the sender, by electronic mail or telephone,= of any unintended receipt and delete the original message without making a= ny copies.

Blue Cross Blue Shield of Michigan and Blue Car= e Network of Michigan are nonprofit corporations and independent licensees = of the Blue Cross and Blue Shield Association.

<= /html>= --_000_2845723087023D4CB5114223779FA9C8AB2EAB14njfpsrvexg8rese_-- From john.mattsson@ericsson.com Tue Oct 22 14:37:22 2013 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 2B67E11E82A5 for ; Tue, 22 Oct 2013 14:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.418 X-Spam-Level: X-Spam-Status: No, score=-6.418 tagged_above=-999 required=5 tests=[AWL=-0.769, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+RDpwcHq91s for ; Tue, 22 Oct 2013 14:37:16 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D55FA11E827A for ; Tue, 22 Oct 2013 14:36:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-d4-5266efe66514 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D0.2B.16099.6EFE6625; Tue, 22 Oct 2013 23:36:38 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.88]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 23:36:38 +0200 From: John Mattsson To: "ippm@ietf.org" Thread-Topic: draft-ietf-ippm-ipsec-01 review Thread-Index: Ac7PbUm7fxHy7g5dSjWMtSxLJHcnNg== Date: Tue, 22 Oct 2013 21:36:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvje6z92lBBl+aTCx6HrxjdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRscmuYIPLhUzPh5kamD8bt7FyMkhIWAisWtzFwuELSZx4d56 ti5GDg4hgcOMEs/ruxi5gMzFjBJNk9+B1bAJGEjM3dPABmKLCChLtHz7wwhiCwtoSHy48IYJ Iq4rcX3JYVYIW0/i6IfbYPUsAqoSm7f2gtXzCnhLTDj+BSzOCLT3+6k1YL3MAuISt57MZ4K4 R0BiyZ7zzBC2qMTLx/9YIWwlicYlT1gh6vUkbkydwgZha0ssW/iaGWK+oMTJmU9YJjAKz0Iy dhaSlllIWmYhaVnAyLKKkT03MTMnvdxwEyMwhA9u+a27g/HUOZFDjNIcLErivB/eOgcJCaQn lqRmp6YWpBbFF5XmpBYfYmTi4JRqYCw1NM9b3LGm+/wBrRTPIHP9Ms3zAbPi3AuYipiDpc2c 7i+xE3ynzrbiteC0Hv9nNk0Sz3gnp/502nhDXPt+V9mDHVmfDwhf5hLXE+uw3C1wPlTsVMYp Rum9HD09b/8b8EzUuVl4bdPj12FqvefuPJsmsjni4umDC1/PX+L51K4+eWnkJCcTcyWW4oxE Qy3mouJEAD/C8r8vAgAA Subject: [ippm] draft-ietf-ippm-ipsec-01 review 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, 22 Oct 2013 21:37:22 -0000 Hi, I reviewed draft-ietf-ippm-ipsec-01, I think the issue is important, and I = think the document is a good start. I do however have some the doubts regar= ding the suggested solution to extract keying material from IPsec. Here are my comments and suggestions. Best Regards John Comments on draft-ietf-ippm-ipsec-01 --------------------------------------------- In general I think the abstract and Introduction could be clearer in what t= he problems and use cases are and what the document tries to achieve. E.g. = do the document want to measure the performance of IPsec or use IPsec for p= rotection, or both. What are the problems, if any, of just sending O/TWAMP = over the existing IPsec tunnel?=20 - [Abstract]=20 "it extends the applicability of O/TWAMP to networks that have already depl= oyed IPsec" "Unfortunately, however, standard IP performance measurement security mecha= nisms cannot be readily used with IPsec." This gives the idea that you cannot use O/TWAMP with IPsec, but this is of = course not true. You can e.g. send O/TWAMP over IPsec, and depending on the= IPsec security policy database (SPD) you can send O/TWAMP outside of the I= Psec tunnel. - [Section 1] "In particular, we note that it is not necessary to use distinct keys in OW= AMP-Control and OWAMP-Test layers. One key for encryption and another for = authentication is sufficient for both Control and Test layers. This obviat= es the need to generate two keys for each layer and reduces the complexity = of O/TWAMP protocols in an IPsec environment. This observation comes from = the fact that separate session keys in the OWAMP-Control and OWAMP-Test lay= ers were designed for preventing reflection attacks when employing the curr= ent mechanism." I assume O/TWAMP uses different keys as is it bad security design to use th= e same key for two different purposes. Using the same key twice may leads a= number of security problems - It easily causes so called "two-time pads" were the confidentiality is to= tally compromised. - For some algorithms the integrity may be compromised.=20 - If one use of the keys has a cryptographic weakness so than an attacker c= an recover the key, the attacker has the use that key to attack both uses o= f the key. - It gives an attacker twice as much material (protected traffic) to work w= ith. I therefore strongly recommends against using the same key twice unless you= must, and in this case we do not. - [Section 3.1] The Server-Start message with Server-IV is missing from the text.=20 Suggestion: "In the authenticated and encrypted modes, all further communication is enc= rypted using the AES Session-key and authenticated with the HMAC Session-ke= y. After receiving Set-Up-Response the server responds with a Server-Start= message containing Server-IV. The client encrypts everything it transmits = through the just-established O/TWAMP-Control connection using stream encryp= tion with Client-IV as the IV."=20 - [Section 4] I think "IPsec SA" is old terminology for IKE(v1), all occurrences should b= e changed to "Child SA". - [Section 4] "Therefore, even if the peers choose to opt for the unauthenticated mode, I= Psec integrity protection is extended to O/TWAMP. I think the document would be improved by discussing this and other options= :=20 O/TWAMP unauthenticated over existing Child SA with integrity. O/TWAMP unauthenticated over existing Child SA with encryption. O/TWAMP unauthenticated over existing Child SA with encryption and integrit= y. O/TWAMP unauthenticated over new Child SA with encryption and or integrity. in a separate section before the section on extracting keying material. It = may very well be the case that O/TWAMP unauthenticated over the existing Ch= ild SA fulfills the user's security requirements. - [Section 3.4] "If the AH protocol is used, IP packets are transmitted in plaintext. The a= uthentication part covers the entire packet. So all test information, such= as UDP port number, and the test results will be visible to any attacker, = which can intercept these test packets, and introduce errors or forge packe= ts that may be injected during the transmission. In order to avoid this at= tack, the receiver must validate the integrity of these packets with the ne= gotiated secret key." As the packeges are authenticated an attacker cannot forge or inject errors= . And as the packages are not encrypted, reading the information cannot be= considered an attack. I suggest deleting " to any attacker, which can intercept these test packet= s, and introduce errors or forge packets that may be injected during the tr= ansmission. In order to avoid this attack, the receiver must validate the = integrity of these packets with the negotiated secret key.=20 - [Section 3.4, Section 4] "If ESP is used, IP packets are encrypted" "When using ESP, all IP packets are encrypted" This is not true as ESP can be used with only integrity protection (NULL ci= pher). In fact, I think this is far more common than using AH. Instead of s= tart talking about AH, I think the draft could list the three different ESP= options (integrity and/or encryption) and then have a note stating that fo= r AH have similar properties as ESP with NULL cipher. - [Section 4] >From a security perspective it would be very bad to allow extraction of SKE= YSEED or KEYMAT. They could be used to passively eavesdrop on the IPsec tra= ffic or to alter/inject messages. Even if we trust the O/TWAMP application = to not be malicious, use of the same key in another application may cause s= ecurity problems such as two-time pad, which completely compromises the con= fidentiality. =20 A secure solution would be that the IPsec API returns a key that is derived= from some of IPsec keying material. E.g. a new "KEYMAT" derived using some= new random material instead of (Ni,Nr), e.g.: Shared secret =3D prf+( SK_d, SID )=20 Or a key derived from KEYMAT:=20 Shared secret =3D PRF( KEYMAT, SID )=20 I strongly suggest removing the options that exposes the IPsec keying mater= ial, only keeping secure options, and adding text describing that it is the= IPsec implementation that performs the key derivations. - [Section 4] While extracting keying material from IPsec would be nice, to my knowledge = there is no standardized (or de facto standard) API to extract SKEYSEED, SK= _d, KEYMAT or even SPI from an IPsec implementation. This was even one of t= he reasons IPsec was not chosen as the default security protocol for O/TWAM= P. You could of course do it with a new proprietary implementation, but tha= t kind of beats some of the purpose from the Abstract "gaining popularity i= n several deployment scenarios". Work on an IPsec API started a couple a years ago http://tools.ietf.org/htm= l/draft-ietf-btns-ipsec-apireq-00 but died, and even that work did prohibit extraction of keying material and= discouraged the extraction of SPI as the SPI might change. Has the API proposals been discussed in the ipsecme working group? - [Section 4] I think the approach in Section 4 with extracting keying material would onl= y work with a proprietary IPsec implementation and modifications (adding ne= w fields) to O/TWAMP. Have approaches that do not require extracting keying information been cons= idered? If the Child SA is encrypted, a simpler approach would be to transfer the O= /TWAMP shared secret in a similar manner as the O/TWAMP session key, e.g. i= n the KeyID field. This would just require changes to the function in the O= /TWAMP that receives the shared secret, and no modifications to IPsec. At least if the Child SA is integrity protected, one approach would be to u= se Diffie-Hellman in O/TWAMP. This would still require new O/TWAMP fields b= ut still be easier than the current suggestion as it does not require any c= hanges to IPsec. A problem is still the lack of API to find out whether encryption or integr= ity is in use.=20 Minor editorial comments on draft-ietf-ippm-ipsec-01 ------------------------------------------------------------------ - [s3.1] "OWAMP-Control commands" -> "O/TWAMP-Control commands" - [s4] "must be generated firstly" -> "must be generated first" - [s4] "session ID is is the" ---------------------------------------------------------------------------= --------- JOHN MATTSSON MSc Engineering Physics, MSc Business Administration and Economics=20 Senior Researcher, Security=20 Ericsson AB Security Research F=E4r=F6gatan 6 SE-164 80 Stockholm, Sweden Phone +46 10 71 43 501 SMS/MMS +46 76 11 53 501 john.mattsson at ericsson.com www.ericsson.com From nalini.elkins@insidethestack.com Tue Oct 22 19:47:49 2013 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 7159C11E80F6 for ; Tue, 22 Oct 2013 19:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8FPNhHRadd1 for ; Tue, 22 Oct 2013 19:47:43 -0700 (PDT) Received: from nm13-vm9.access.bullet.mail.bf1.yahoo.com (nm13-vm9.access.bullet.mail.bf1.yahoo.com [216.109.115.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8865911E82AF for ; Tue, 22 Oct 2013 19:47:42 -0700 (PDT) Received: from [66.196.81.158] by nm13.access.bullet.mail.bf1.yahoo.com with NNFMP; 23 Oct 2013 02:47:42 -0000 Received: from [66.196.81.138] by tm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 23 Oct 2013 02:47:42 -0000 Received: from [127.0.0.1] by omp1014.access.mail.bf1.yahoo.com with NNFMP; 23 Oct 2013 02:47:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 986757.83326.bm@omp1014.access.mail.bf1.yahoo.com Received: (qmail 47023 invoked by uid 60001); 23 Oct 2013 02:47:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1382496461; bh=cp/HBCX/azKn4xEzvCECFX47EmKLyeH/PkzW2nQkVfg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=cCILD0lcg4yCQrbCKIsOasldBSmzwrTwj00/2xYq+zJyjhhy6n3Cf5eMNxUWwt01dbFxx0V6L9Bz02kC8gSPYcH27aQlZXRuFHSS5R12P1bDmuwMFSb5Tu1pqV/ecSbv2ZNdO3lx3MZm0XAqscPSdZmaEKL+ZqQTSnbg3bDyZ20= X-YMail-OSG: QPQC_PsVM1kZD_X6gftynY4P1O7fpNe3sXgZmv80zWVACon 0c4YSAvjLK7lrM9GBYC1tsImxDhj_Yv_c9JUzlt89s57taT5hkZaFLU3wura dbkpAoGoL398Wp_SPxc6_I5D8ZqfG2.auj7MojOJvR.m6gH7_i1JjdrNoKAW KskYXNZCdRS.xDt2RdTzdHoQq2FFHxACNh3gXI3OAQpAnek2xNd96ar0Fb0y G3T9Llgg_uvxyqa_4kkh3_FFtTwno0mVzqPSfsH5c6fFo6hvdA2g5OdHpDVD 8moyZzinaLOczBgi6tiUzZU9vrCtcx2_FkiB4KuwpHr0nKtpC4i5mp8NQbLZ ydi5VRWZ2QxsuV7DwQ5.VA.2PBKscBTAy5xUmi5d568mNhbjvUE.KuFWXUIC dDlNxkMQaR_dHsLO9f9L_vK3On292mgnHeNomXnjjTjkikPpCCpnhG7Hkmn. xVLQmLtyHx.y1jy8PitoDE4wJQuqOJmDa.0K9xSPXID3gu_DzAS12QmtSjsb CpIWqr1JMPLCSwVgFmkczX7Vzwsr8exMm__v5fIfD3TbT_1kih2VQJFwGrQK PXoNxb6DajkwKdVcCiJj_xJ1Aspkil4VXwKHorw-- Received: from [24.130.37.147] by web2802.biz.mail.ne1.yahoo.com via HTTP; Tue, 22 Oct 2013 19:47:40 PDT X-Rocket-MIMEInfo: 002.001, Cgo.IE5hbGluaSBFbGtpbnMgPG1haWx0bzpuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbT4KPiAyMiBPY3RvYmVyIDIwMTMgMDA6NTgKPj7CoCAxKSBlbmNvZGluZyBoYXMgdG8gYmUgZmFzdCwgYnV0IGRlY29kaW5nIGRvZXMgbm90Cj4KPiBUcnVlCj4KPj7CoCAyKSBhIG5vZGUncyBjbG9jayBjb3VsZCBiZSBlaXRoZXIgaW4gb3VyIG91dCBvZiBzeW5jaCB3aXRoIHNvbWUgbm90aW9uYWwKPj7CoCBtYXN0ZXIgY2xvY2sgKGUuZy4gdmlhIE5UUCkKPj7CoCAzKSB0d28gY2xvY2tzIGNvdWxkIGJlIGkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> Message-ID: <1382496460.46942.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Date: Tue, 22 Oct 2013 19:47:40 -0700 (PDT) From: Nalini Elkins To: Ray Hunter In-Reply-To: <526616C4.40304@globis.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-153701192-410707112-1382496460=:46942" Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [ippm] [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 02:47:49 -0000 ---153701192-410707112-1382496460=:46942 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A> Nalini Elkins =0A> 22 Octo= ber 2013 00:58=0A>>=A0 1) encoding has to be fast, but decoding does not=0A= >=0A> True=0A>=0A>>=A0 2) a node's clock could be either in our out of sync= h with some notional=0A>>=A0 master clock (e.g. via NTP)=0A>>=A0 3) two clo= cks could be in synch to a master source, but the master=0A>>=A0 sources ma= y themselves not share a common source (one sourced from GPS,=0A>> one from= DCF77)=0A>> 4) the key to being able to perform the end to end calculation= s is=0A>> whether two communicating nodes are synchronised to the same mast= er=0A>> clock (within some level of error/jitter)=0A>> 5) the absolute time= is not particularly important=0A>=0A>=0A> This is true for PDM 1 only.=A0 = PDM 2 does not require time synchronization.=0A>=0A>>=A0 Q1. Why do you wan= t to encode differences as deltas in the case of an unsynchronised/ free ru= nning clock?=0A>>=A0 Isn't that slow, and difficult for hardware implementa= tions to achieve (e.g. TCP offload)? Doesn't it also require maintaining la= rge amounts of state in the sending node.=0A>>=0A>=0A> 1. I think that it i= s going to be interesting to see how hardware is going to handle TCP offloa= d with IPv6 extension headers.=A0 I do not see why PDM 2 would be so much = harder than PDM 1 for an OS.=0A> Can you tell me which end host operating s= ystems are doing TCP offload in hardware?=A0 =0A=0A=0A>IMHO Not a relevant = question. As a standards body we should be looking=0A>to the future. There = are many operations that are delegated to microcode.=0A=0A>If you specified= the packet with one single way of encapsulating=0A>timestamps, then hardwa= re or interface microcode could add the timestamp=0A>at the last possible m= oment before the packet reached the wire, without=0A>having to examine the = original packet contents, or knowing the context=0A>of the communicating no= des. I think that's very desirable.=0A=0ASure. =A0 Sounds good! =A0Also loo= king to the future, then I will speculate that we will likely have more and= better time synchronization also.=0A=0A=0A> I know some OS's which process= TCP segmentation in hardware.=A0 =A0 But at this point, the packet is alre= ady crafted.=A0 Also some do IP checksum offload in hardware but that does = not apply to IPv6 as there is no IP header checksum.=0A=0A>=0A>=0A> 2.=A0 E= nd hosts already maintain quite a bit of state.=A0 Every OS has control blo= cks to handle events such as TCP duplicate packets, round trip time, conges= tion window, etc.=A0 We are NOT suggesting=0A> that the PDM headers be use= d in middle boxes.=A0 That is, we are NOT asking routers to maintain state.= =0A=0A=0A>So what? Why add to the problem?=0A=0AYes. =A0Just saying that we= are not CREATING the problem.=0A=0A>Why does the timestamp require synchro= nisation with that other TCP state?=0A=0AIt doesn't. =A0Just mentioning oth= er reasons why state is maintained.=0A=0A>Isn't it better to define a solut= ion that is independent of the upper=A0layer header transport protocol?=0A= =0AYes. =A0Our solution IS independent. =A0I think my analogy actually conf= used the issue!=0A=0A>=A0 Why not allow middleboxes (or node hardwa= re) to insert the=A0timestamp header on the fly?=0A=0AInteresting = idea!=0A=0A>=0A>>=A0 Why not just encode the timestamp as-is and perform th= e appropriate difference calculation during decoding?=0A>=0A> If clocks are= out of synch, you could end up having it look like you received the packet= before you sent it.=0A=0A>=A0No. I'm not suggesting you use the same decod= ing algorithm: only that=A0you define a single common encoding algorithm th= at combines all the=A0information required for PDM 1 and PDM 2 calculations= . Having to chose=0A>which packet encoding to use in advance is problematic= IMHO.=A0=0A=0AWe will look at this. =A0 I am also meeting with a couple of= the end host OS vendors to get their viewpoint on the PDMs. =A0 Their engi= neers have good opinions on what the problems might be with actually creati= ng PDMs.=0AI should have that info before Vancouver.=0A=0A>>=A0 Q2. Why do = you need two separate packet formats at all?=0A>=0A>>=A0 Why not have a com= mon format for all cases, containing a timestamp based=0A>> on the local cl= ock, plus an optional field containing a flag that states=0A>> if the local= timestamp is coordinated to some master clock, plus an=0A>> identifier for= the master clock.=0A>=0A>> You could then encode whether a node had a free= -running clock (case 2),=0A>> a synchronised clock (case 1), and whether it= was synched via NTP to=0A>> some stratum 0 source e.g. GPS, and also some = identification of the=0A>> stratum 1 source (IPv6 address).=0A>=0A>> Two co= mmunicating nodes could then use e.g. NTP trace to see if they=0A>> shared = a common clock source or not, before performing their calculations.=0A>=0A>= We are trying to craft a solution with PDM 2 for those situations where ti= me synchronization is not practical, possible or desired.=0A=0A>I understan= d the aim, but let me ask my question a different way.=0A=0A>Imagine there = are nodes A&B that with clocks synched to DCF77.=0A>Imagine there are nodes= C&D that with clocks=A0 synched to GPS.=0A>Node E has free running clock (= possibly because the GPS receiver is down).=0A=0A>Which packet format PDM t= ype 1 or PDM type 2 do you use between each=0A>pair of nodes, and how does = the sending node know that?=0A=0A>Scale this solution to 100K hosts.=0A=0AG= ood question. =A0We were thinking that each node would start with PDM 1 and= then if the other side could not do PDM 1, then it would drop back to PDM = 2.=0ABut, the clock issue is good. =A0Now,=A0my understanding is that clock= difference has more to do with Stratum levels. =A0 =A0But, I am not the NT= P expert in the group.=A0=0AI am just wondering (leaving off Node E) how mu= ch clock difference would there be? =A0 What do you think?=A0I have a meeti= ng with my team tomorrow &=A0will bring this up for discussion.=0A=0A>=0A> = ------------------------------------------------------------------------=0A= =0A=0A-- =0ARegards,=0ARayH ---153701192-410707112-1382496460=:46942 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

=0A> Nalini Elkins <mailto:nalini.elkins@insidethestack.com>
> 22 October= 2013 00:58
>>  1) encoding has to be fast, but decoding does= not
>
> True
>
>>  2) a node's clock could= be either in our out of synch with some notional
>>  master = clock (e.g. via NTP)
>>  3) two clocks could be in synch to a= master source, but the master
>>  sources may themselves not= share a common source (one sourced from GPS,
>> one from DCF77)>> 4) the key to being able to perform the end to end calculations = is
>> whether two communicating nodes are synchronised to the same= master
>> clock (within some level of error/jitter)
>> 5= ) the absolute time is not particularly important
>
>
> T= his is true for PDM 1 only.  PDM 2 does not require time synchronization.
>
>&g= t;  Q1. Why do you want to encode differences as deltas in the case of= an unsynchronised/ free running clock?
>>  Isn't that slow, = and difficult for hardware implementations to achieve (e.g. TCP offload)? D= oesn't it also require maintaining large amounts of state in the sending no= de.
>>
>
> 1. I think that it is going to be interesti= ng to see how hardware is going to handle TCP offload with IPv6 extension h= eaders.  I do not see why PDM 2 would be so much harder than PDM 1 fo= r an OS.
> Can you tell me which end host operating systems are doing= TCP offload in hardware? 

>IMHO Not a relevant question. As a standards body we should be looki= ng
>to the future. There are many operations that are delegated to mi= crocode.

>If you specified the packet with one single way of encapsulating
>timestamps, then hardware or interface microcode coul= d add the timestamp
>at the last possible moment before the packet re= ached the wire, without
>having to examine the original packet conten= ts, or knowing the context
>of the communicating nodes. I think that'= s very desirable.

Sure.   Sounds good!  Also looking to the fu= ture, then I will speculate that we will likely have more and better time s= ynchronization also.

> I know som= e OS's which process TCP segmentation in hardware.    But at this= point, the packet is already crafted.  Also some do IP checksum offlo= ad in hardware but that does not apply to IPv6 as there is no IP header che= cksum.
>
>
> 2.  End hosts already maintain quite a bit of state.  Every OS h= as control blocks to handle events such as TCP duplicate packets, round tri= p time, congestion window, etc.  We are NOT suggesting
> that t= he PDM headers be used in middle boxes.  That is, we are NOT asking ro= uters to maintain state.

>So= what? Why add to the problem?

Yes.  Just saying that we are no= t CREATING the problem.

>Why doe= s the timestamp require synchronisation with that other TCP state?

It doesn't.  Just mentioning other reasons why state is maintained.

>Isn't it better to define a solution that is independent of the upper&= nbsp;layer header transport protocol?

Yes. &n= bsp;Our solution IS independent.  I think my analogy actually confused= the issue!

><heresy>  Why= not allow middleboxes (or node hardware) to insert the timestamp header on the fly?</heresy>

=

><= br>>>  Why not just encode the timestamp as-is and perform the a= ppropriate difference calculation during decoding?
>
> If clock= s are out of synch, you could end up having it look like you received the p= acket before you sent it.

> No. I'm not suggesting you use the same decoding= algorithm: only that you define a single common encoding algorithm th= at combines all the information required for PDM 1 and PDM 2 calculati= ons. Having to chose
>which packet e= ncoding to use in advance is problematic IMHO. 

We will look at this= .   I am also meeting with a couple of the end host OS vendors to get = their viewpoint on the PDMs.   Their engineers have good opinions on w= hat the problems might be with actually creating PDMs.
I should have that info before Vancouver.

>>&n= bsp; Q2. Why do you need two separate packet formats at all?
>
>= ;>  Why not have a common format for all cases, containing a timest= amp based
>> on the local clock, plus an optional field containing a flag that states
>> if the local timestamp is coordinated to so= me master clock, plus an
>> identifier for the master clock.
&g= t;
>> You could then encode whether a node had a free-running cloc= k (case 2),
>> a synchronised clock (case 1), and whether it was s= ynched via NTP to
>> some stratum 0 source e.g. GPS, and also some= identification of the
>> stratum 1 source (IPv6 address).
>=
>> Two communicating nodes could then use e.g. NTP trace to see i= f they
>> shared a common clock source or not, before performing t= heir calculations.
>
> We are trying to craft a solution with P= DM 2 for those situations where time synchronization is not practical, poss= ible or desired.

>I understand the aim, but let me ask my questio= n a different way.

>Imagine there are nodes A&B that with clo= cks synched to DCF77.
>Imagine there are nodes C&D that with clocks  synched to GPS.
>= Node E has free running clock (possibly because the GPS receiver is down).<= br>
>Which packet format PDM type 1 or PDM type 2 do you use between = each
>pair of nodes, and how does th= e sending node know that?

>Scale this solution to 100K hosts.

Good q= uestion.  We were thinking that each node would start with PDM 1 and t= hen if the other side could not do PDM 1, then it would drop back to PDM 2.=
But, = the clock issue is good.  Now,=  my understanding is that cloc= k difference has more to do with Stratum levels.    But, I am not= the NTP expert in the group. 
I am just wondering (leaving off Node E) how much clock difference would there be= ?   What do you think? I = have a meeting with my team tomorrow & will bring this up for discussion.

>
> ------------------------------------------= ------------------------------


--
Regards,
RayH


---153701192-410707112-1382496460=:46942-- From k.pentikousis@eict.de Wed Oct 23 02:08:46 2013 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 DE52621F84D0; Wed, 23 Oct 2013 02:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wU98IJwHUTg; Wed, 23 Oct 2013 02:08:41 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 013AB11E8162; Wed, 23 Oct 2013 02:08:36 -0700 (PDT) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 22BD11FF58; Wed, 23 Oct 2013 11:08:35 +0200 (CEST) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 93AEB37819D; Wed, 23 Oct 2013 11:08:34 +0200 (CEST) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Wed, 23 Oct 2013 11:08:34 +0200 From: Konstantinos Pentikousis To: John Mattsson Date: Wed, 23 Oct 2013 11:08:32 +0200 Thread-Topic: [ippm] draft-ietf-ippm-ipsec-01 review Thread-Index: Ac7PmlUqX2JIOakDT/CgxsRdf+tOogAM82Jw Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10BFCB993@SBS2008.eict.local> References: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] draft-ietf-ippm-ipsec-01 review 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, 23 Oct 2013 09:08:46 -0000 Hi John, all, | I reviewed draft-ietf-ippm-ipsec-01, I think the issue is important, | and I think the document is a good start. I do however have some the | doubts regarding the suggested solution to extract keying material from | IPsec. |=20 | Here are my comments and suggestions. |=20 | Best Regards | John Many thanks for the review! We really appreciate it, as it also opens up th= e discussion ahead of the meeting in Vancouver. I'm adding in CC the ipsecm= e WG, as experts in that list may want to voice their opinion as well. @ippm: Please note that the core of John's review is on the ipsec part. We = still need to get going on the discussion about the O/TWAMP protocol aspect= s (e.g. Server Greeting and backwards compatibility, Modes, optimizations a= nd so on) @ipsecme: John's full review is available at http://www.ietf.org/mail-archi= ve/web/ippm/current/msg03231.html Best regards, Kostas From joelja@bogus.com Thu Oct 24 11:14:50 2013 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 85EE311E81C5; Thu, 24 Oct 2013 11:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBs8g+YIrVom; Thu, 24 Oct 2013 11:14:49 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 621D811E8200; Thu, 24 Oct 2013 11:14:47 -0700 (PDT) Received: from 00698a-hsutim.corp.zynga.com ([199.48.105.4]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r9OIEeJu029937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 24 Oct 2013 18:14:42 GMT (envelope-from joelja@bogus.com) Content-Type: multipart/signed; boundary="Apple-Mail=_4C19CD7E-9716-48FB-A56B-DCFF30077490"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: joel jaeggli In-Reply-To: <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> Date: Thu, 24 Oct 2013 11:14:35 -0700 Message-Id: <585D21EB-BD17-40C7-9C31-67F12EC6712F@bogus.com> References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> To: "Ackermann, Michael" X-Mailer: Apple Mail (2.1816) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 24 Oct 2013 18:14:43 +0000 (UTC) Cc: Ray Hunter , v6ops WG , "ippm@ietf.org" , 6man WG Subject: Re: [ippm] [v6ops] New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt 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, 24 Oct 2013 18:14:50 -0000 --Apple-Mail=_4C19CD7E-9716-48FB-A56B-DCFF30077490 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 24, 2013, at 9:50 AM, Ackermann, Michael = wrote: > Hi Ray. > And thanks again for all your insightful comments/questions.=20 >=20 > I am a little late in responding, so let me just tack on a little to = what Nalini and others have already said.=20 >=20 > Your point 4 seems to indicate that all nodes in a desired time = synchronization domain need to be synched to the same master clock. = This has not been my experience. As long as the required Stratum level = is realized, for the level of accuracy required by the situation or = application, the proper level of time synchronization is achieved. = Example would be that if one node in the NTP domain is referencing a GPS = Stratum 0 and another node is referencing a separate Stratum 0 source, = the two nodes should be Stratum 1 and within that level of accuracy. =20 stratum is not an indication of either precision or accuracy it=92s an = inidication of a position within the NTP heirachary. > This is something we have implemented across several disparate = enterprises and it has worked well for us. I am wondering if your = experience has yielded different results? >=20 > You also had two other points/questions, that I believe Nalini already = responded to, but.............. >=20 > 1. The possibility that "Middleboxes" could utilize PDM, is very = intriguing to me. I believe this would be more difficult to = add/implement, but worth the effort if the Middlebox vendors would = perceive value and actually use PDM. Not sure how to determine if this = would be the case or not?=20 >=20 > 2. It would be ideal to have only 1 PDM format that handles both time = sycnronized and non synchronized situations. I do not readily see how = to achieve this. Would love to talk to you some more if you have some = ideas! =20 >=20 > Again, thanks for your great input, thoughts and questions!!! (and = hopefully more to come). =20 >=20 > Mike >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Ray Hunter > Sent: Tuesday, October 22, 2013 2:10 AM > To: Nalini Elkins > Cc: v6ops WG; 6man WG; ippm@ietf.org > Subject: Re: [v6ops] Fw: New Version Notification for = draft-elkins-6man-ipv6-pdm-dest-option-04.txt >=20 >> Nalini Elkins >> 22 October 2013 00:58 >>> 1) encoding has to be fast, but decoding does not >>=20 >> True >>=20 >>> 2) a node's clock could be either in our out of synch with some=20 >>> notional master clock (e.g. via NTP) >>> 3) two clocks could be in synch to a master source, but the master =20= >>> sources may themselves not share a common source (one sourced from=20= >>> GPS, one from DCF77) >>> 4) the key to being able to perform the end to end calculations is=20= >>> whether two communicating nodes are synchronised to the same master=20= >>> clock (within some level of error/jitter) >>> 5) the absolute time is not particularly important >>=20 >>=20 >> This is true for PDM 1 only. PDM 2 does not require time = synchronization. >>=20 >>> Q1. Why do you want to encode differences as deltas in the case of = an unsynchronised/ free running clock? >>> Isn't that slow, and difficult for hardware implementations to = achieve (e.g. TCP offload)? Doesn't it also require maintaining large = amounts of state in the sending node. >>>=20 >>=20 >> 1. I think that it is going to be interesting to see how hardware is = going to handle TCP offload with IPv6 extension headers. I do not see = why PDM 2 would be so much harder than PDM 1 for an OS. >> Can you tell me which end host operating systems are doing TCP = offload in hardware? =20 > IMHO Not a relevant question. As a standards body we should be looking = to the future. There are many operations that are delegated to = microcode. >=20 > If you specified the packet with one single way of encapsulating = timestamps, then hardware or interface microcode could add the timestamp = at the last possible moment before the packet reached the wire, without = having to examine the original packet contents, or knowing the context = of the communicating nodes. I think that's very desirable. >> I know some OS's which process TCP segmentation in hardware. But = at this point, the packet is already crafted. Also some do IP checksum = offload in hardware but that does not apply to IPv6 as there is no IP = header checksum. >>=20 >>=20 >> 2. End hosts already maintain quite a bit of state. Every OS has = control blocks to handle events such as TCP duplicate packets, round = trip time, congestion window, etc. We are NOT suggesting >> that the PDM headers be used in middle boxes. That is, we are NOT = asking routers to maintain state. > So what? Why add to the problem? >=20 > Why does the timestamp require synchronisation with that other TCP = state? >=20 > Isn't it better to define a solution that is independent of the upper = layer header transport protocol? >=20 > Why not allow middleboxes (or node hardware) to insert the = timestamp header on the fly? >>=20 >>> Why not just encode the timestamp as-is and perform the appropriate = difference calculation during decoding? >>=20 >> If clocks are out of synch, you could end up having it look like you = received the packet before you sent it. >=20 > No. I'm not suggesting you use the same decoding algorithm: only that = you define a single common encoding algorithm that combines all the = information required for PDM 1 and PDM 2 calculations. Having to chose = which packet encoding to use in advance is problematic IMHO. >=20 >=20 >=20 >>> Q2. Why do you need two separate packet formats at all? >>=20 >>> Why not have a common format for all cases, containing a timestamp=20= >>> based on the local clock, plus an optional field containing a flag=20= >>> that states if the local timestamp is coordinated to some master=20 >>> clock, plus an identifier for the master clock. >>=20 >>> You could then encode whether a node had a free-running clock (case=20= >>> 2), a synchronised clock (case 1), and whether it was synched via = NTP=20 >>> to some stratum 0 source e.g. GPS, and also some identification of=20= >>> the stratum 1 source (IPv6 address). >>=20 >>> Two communicating nodes could then use e.g. NTP trace to see if they=20= >>> shared a common clock source or not, before performing their = calculations. >>=20 >> We are trying to craft a solution with PDM 2 for those situations = where time synchronization is not practical, possible or desired. >=20 > I understand the aim, but let me ask my question a different way. >=20 > Imagine there are nodes A&B that with clocks synched to DCF77. > Imagine there are nodes C&D that with clocks synched to GPS. > Node E has free running clock (possibly because the GPS receiver is = down). >=20 > Which packet format PDM type 1 or PDM type 2 do you use between each = pair of nodes, and how does the sending node know that? >=20 > Scale this solution to 100K hosts. >>=20 >> = ---------------------------------------------------------------------- >> -- >=20 >=20 > -- > Regards, > RayH >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you = are hereby notified that any viewing, copying, disclosure or = distribution of this information is prohibited. Please notify the = sender, by electronic mail or telephone, of any unintended receipt and = delete the original message without making any copies. >=20 > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross = and Blue Shield Association. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 --Apple-Mail=_4C19CD7E-9716-48FB-A56B-DCFF30077490 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJpY4sACgkQ8AA1q7Z/VrKo/wCcDK5BXwTKRrJAadowt4znf186 rTgAnR/PcdhLLw8rsgOOhnTmlYlYh58I =5W5c -----END PGP SIGNATURE----- --Apple-Mail=_4C19CD7E-9716-48FB-A56B-DCFF30077490-- From v6ops@globis.net Sun Oct 20 05:07:43 2013 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 25B9E11E83B7; Sun, 20 Oct 2013 05:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D86ek-V6F8fQ; Sun, 20 Oct 2013 05:07:42 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id DD26611E81B0; Sun, 20 Oct 2013 05:07:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 05DC1870076; Sun, 20 Oct 2013 14:07:33 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FVtSBQZRb1a; Sun, 20 Oct 2013 14:07:32 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id C7D7987003F; Sun, 20 Oct 2013 14:07:32 +0200 (CEST) Message-ID: <5263C783.1080001@globis.net> Date: Sun, 20 Oct 2013 14:07:31 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Nalini Elkins References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 24 Oct 2013 23:51:37 -0700 Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [ippm] [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt 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, 20 Oct 2013 12:07:43 -0000 Nalini Elkins wrote: > All, > > I have revised the 6man submission to take out the calculations and packet flows. All of these are in the IPPM document. A notation of all the usage cases that this methodology should handle has also been added to the IPPM draft. > > The IPPM draft is here: http://datatracker.ietf.org/doc/draft-elkins-ippm-pdm-metrics/ > > The 6man draft is below. > > I appreciate any thoughts and comments. > > A new version of I-D, draft-elkins-6man-ipv6-pdm-dest-option-04.txt > has been successfully submitted by Nalini Elkins and posted to the > IETF repository. > > Filename: draft-elkins-6man-ipv6-pdm-dest-option > Revision: 04 > Title: IPv6 Performance and Diagnostic Metrics Destination Option > Creation date: 2013-10-16 > Group: Individual Submission > Number of pages: 12 > URL: http://www.ietf.org/internet-drafts/draft-elkins-6man-ipv6-pdm-dest-option-04.txt > Status: http://datatracker.ietf.org/doc/draft-elkins-6man-ipv6-pdm-dest-option > Htmlized: http://tools.ietf.org/html/draft-elkins-6man-ipv6-pdm-dest-option-04 > Diff: http://www.ietf.org/rfcdiff?url2=draft-elkins-6man-ipv6-pdm-dest-option-04 > > Abstract: > To diagnose performance and connectivity problems, metrics on real > (non-synthetic) transmission are critical for timely end-to-end > problem resolution. Such diagnostics may be real-time or after the > fact, but must not impact an operational production network. The base > metrics are: packet sequence number and packet timestamp. Metrics > derived from these will be described separately. This document solves > these problems with a new destination option, the Performance and > Diagnostic Metrics destination option (PDM). > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat Given that it seems to me that: 1) encoding has to be fast, but decoding does not 2) a node's clock could be either in our out of synch with some notional master clock (e.g. via NTP) 3) two clocks could be in synch to a master source, but the master sources may themselves not share a common source (one sourced from GPS, one from DCF77) 4) the key to being able to perform the end to end calculations is whether two communicating nodes are synchronised to the same master clock (within some level of error/jitter) 5) the absolute time is not particularly important Q1. Why do you want to encode differences as deltas in the case of an unsynchronised/ free running clock? Isn't that slow, and difficult for hardware implementations to achieve (e.g. TCP offload)? Doesn't it also require maintaining large amounts of state in the sending node. Why not just encode the timestamp as-is and perform the appropriate difference calculation during decoding? Q2. Why do you need two separate packet formats at all? Why not have a common format for all cases, containing a timestamp based on the local clock, plus an optional field containing a flag that states if the local timestamp is coordinated to some master clock, plus an identifier for the master clock. You could then encode whether a node had a free-running clock (case 2), a synchronised clock (case 1), and whether it was synched via NTP to some stratum 0 source e.g. GPS, and also some identification of the stratum 1 source (IPv6 address). Two communicating nodes could then use e.g. NTP trace to see if they shared a common clock source or not, before performing their calculations. IMHO that would then allow you to place some error bounds on your time calculations, whilst also simplifying the implementation for the sender. -- Regards, RayH From v6ops@globis.net Mon Oct 21 23:10:16 2013 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 7868011E815B; Mon, 21 Oct 2013 23:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJFbTpG883gE; Mon, 21 Oct 2013 23:10:15 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED2511E8160; Mon, 21 Oct 2013 23:10:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 823348700BD; Tue, 22 Oct 2013 08:10:14 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rc69tpUhZj34; Tue, 22 Oct 2013 08:10:14 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 0222387005F; Tue, 22 Oct 2013 08:10:13 +0200 (CEST) Message-ID: <526616C4.40304@globis.net> Date: Tue, 22 Oct 2013 08:10:12 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Nalini Elkins References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> In-Reply-To: <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 24 Oct 2013 23:51:37 -0700 Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [ippm] [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt 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, 22 Oct 2013 06:10:16 -0000 > Nalini Elkins > 22 October 2013 00:58 >> 1) encoding has to be fast, but decoding does not > > True > >> 2) a node's clock could be either in our out of synch with some notional >> master clock (e.g. via NTP) >> 3) two clocks could be in synch to a master source, but the master >> sources may themselves not share a common source (one sourced from GPS, >> one from DCF77) >> 4) the key to being able to perform the end to end calculations is >> whether two communicating nodes are synchronised to the same master >> clock (within some level of error/jitter) >> 5) the absolute time is not particularly important > > > This is true for PDM 1 only. PDM 2 does not require time synchronization. > >> Q1. Why do you want to encode differences as deltas in the case of an unsynchronised/ free running clock? >> Isn't that slow, and difficult for hardware implementations to achieve (e.g. TCP offload)? Doesn't it also require maintaining large amounts of state in the sending node. >> > > 1. I think that it is going to be interesting to see how hardware is going to handle TCP offload with IPv6 extension headers. I do not see why PDM 2 would be so much harder than PDM 1 for an OS. > Can you tell me which end host operating systems are doing TCP offload in hardware? IMHO Not a relevant question. As a standards body we should be looking to the future. There are many operations that are delegated to microcode. If you specified the packet with one single way of encapsulating timestamps, then hardware or interface microcode could add the timestamp at the last possible moment before the packet reached the wire, without having to examine the original packet contents, or knowing the context of the communicating nodes. I think that's very desirable. > I know some OS's which process TCP segmentation in hardware. But at this point, the packet is already crafted. Also some do IP checksum offload in hardware but that does not apply to IPv6 as there is no IP header checksum. > > > 2. End hosts already maintain quite a bit of state. Every OS has control blocks to handle events such as TCP duplicate packets, round trip time, congestion window, etc. We are NOT suggesting > that the PDM headers be used in middle boxes. That is, we are NOT asking routers to maintain state. So what? Why add to the problem? Why does the timestamp require synchronisation with that other TCP state? Isn't it better to define a solution that is independent of the upper layer header transport protocol? Why not allow middleboxes (or node hardware) to insert the timestamp header on the fly? > >> Why not just encode the timestamp as-is and perform the appropriate difference calculation during decoding? > > If clocks are out of synch, you could end up having it look like you received the packet before you sent it. No. I'm not suggesting you use the same decoding algorithm: only that you define a single common encoding algorithm that combines all the information required for PDM 1 and PDM 2 calculations. Having to chose which packet encoding to use in advance is problematic IMHO. >> Q2. Why do you need two separate packet formats at all? > >> Why not have a common format for all cases, containing a timestamp based >> on the local clock, plus an optional field containing a flag that states >> if the local timestamp is coordinated to some master clock, plus an >> identifier for the master clock. > >> You could then encode whether a node had a free-running clock (case 2), >> a synchronised clock (case 1), and whether it was synched via NTP to >> some stratum 0 source e.g. GPS, and also some identification of the >> stratum 1 source (IPv6 address). > >> Two communicating nodes could then use e.g. NTP trace to see if they >> shared a common clock source or not, before performing their calculations. > > We are trying to craft a solution with PDM 2 for those situations where time synchronization is not practical, possible or desired. I understand the aim, but let me ask my question a different way. Imagine there are nodes A&B that with clocks synched to DCF77. Imagine there are nodes C&D that with clocks synched to GPS. Node E has free running clock (possibly because the GPS receiver is down). Which packet format PDM type 1 or PDM type 2 do you use between each pair of nodes, and how does the sending node know that? Scale this solution to 100K hosts. > > ------------------------------------------------------------------------ -- Regards, RayH From mackermann@bcbsm.com Tue Oct 22 08:01:31 2013 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 2272711E83F0 for ; Tue, 22 Oct 2013 08:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MbuO-6b3dRX for ; Tue, 22 Oct 2013 08:01:23 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id CEE4B11E81B6 for ; Tue, 22 Oct 2013 08:01:22 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 803962FF404 for ; Tue, 22 Oct 2013 10:01:21 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id E86D230741A; Tue, 22 Oct 2013 10:01:19 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id B7D164F8055; Tue, 22 Oct 2013 10:51:10 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva1.bcbsm.com (Postfix) with ESMTP id A20E14F8051; Tue, 22 Oct 2013 10:51:10 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([fe80::8db:9ce7:e2cf:8565%13]) with mapi id 14.01.0438.000; Tue, 22 Oct 2013 11:01:06 -0400 From: "Ackermann, Michael" To: "MORTON, ALFRED C (AL)" , Nalini Elkins , "ippm@ietf.org" Thread-Topic: [ippm] Fw: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt Thread-Index: AQHOyayMqQBwUbYhkUaj9bxzxFlrf5n11TpggAoLe6CAAPewMA== Date: Tue, 22 Oct 2013 15:01:06 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0CA85E57@PWN401EA160.ent.corp.bcbsm.com> References: <20131004030407.30291.83858.idtracker@ietfa.amsl.com>, <1380892227.93952.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2845723087023D4CB5114223779FA9C8AAD39FC2@njfpsrvexg8.research.att.com> <1381844622.97264.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0CA77267@PWN401EA160.ent.corp.bcbsm.com> <2845723087023D4CB5114223779FA9C8AB2EAB14@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8AB2EAB14@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: multipart/alternative; boundary="_000_4FC37E442D05A748896589E468752CAA0CA85E57PWN401EA160entc_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 24 Oct 2013 23:51:37 -0700 Cc: Sigfrido Perdomo , Bill Jouris Subject: Re: [ippm] Fw: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt 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, 22 Oct 2013 15:01:31 -0000 --_000_4FC37E442D05A748896589E468752CAA0CA85E57PWN401EA160entc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Al, And yes, the information you provided is very helpful and informative. As you mentioned, the RTT approach has certain shortcomings, that we are = aware of and are trying to allow the PDM to be more resilient to. Right now PDM is mainly for end point hosts. Could be used by = =22Middleboxes=22 in it's present form, but if said Middleboxes are going = to be active in this space and derive optimal value, my initial thought = is that a separate PDM type could be crafted for those situations/devices. = More thought would need to be put into this, but I gather from your = comments it is at least worth looking into. Once again thanks for your feedback and look forward to more, and to = meeting you=21 Mike From: MORTON, ALFRED C (AL) =5Bmailto:acmorton=40att.com=5D Sent: Monday, October 21, 2013 8:27 PM To: Ackermann, Michael; Nalini Elkins; ippm=40ietf.org Cc: Sigfrido Perdomo; keven.haining=40usbank.com; Bill Jouris Subject: RE: =5Bippm=5D Fw: New Version Notification for = draft-elkins-ippm-pdm-metrics-00.txt Hi Michael, Regarding one of your questions below: My question for you is whether you think we SHOULD craft additional PDM = function that CAN be populated and/or utilized expressly for or by Middle = Boxes? This would likely involve more complexity and overhead, but may be = warranted if associated value is perceived. Yes, but it has been attempted by dedicated flow monitoring appliances. I did some research and reading about this topic today. Have a look at: http://tools.ietf.org/html/draft-mornulo-ippm-registry-columns-01=23section= -6 and the references. This is a case of completely passive RTT measurement on TCP(SYN/SYN_ACK) request response pairs, but with the addition of the IPv6 PDM, one could attribute the delay properly to network beyond the monitoring point and server (the later doesn't change). The main point is that it should be do-able to do the correlations mid-path, without help from the app (as you would have at the server end). Of course, there's a cost for these middlebox monitoring instances, and you have to have sufficient coverage to observe both directions of the connection. So, what's needed is a compelling case where = troubleshooting is enhanced by the middlebox measurements, perhaps when multiple networks are involved in the path. hope this helps, Al From: Ackermann, Michael =5Bmailto:MAckermann=40bcbsm.com=5D Sent: Tuesday, October 15, 2013 12:41 PM To: Nalini Elkins; MORTON, ALFRED C (AL); = ippm=40ietf.org Cc: Sigfrido Perdomo; = keven.haining=40usbank.com; Bill Jouris Subject: RE: =5Bippm=5D Fw: New Version Notification for = draft-elkins-ippm-pdm-metrics-00.txt Hi Al, Echoing Nalini's thoughts regarding your great comments/questions and how = excited we are about the potential of working with you and your teams. Nalini's answers are great in my view and I have one comment/question on = the topic of =22Middle Boxes=22, which in my view includes Routers and = Firewalls. As Nalini said, the PDM was conceived to be populated and = utilized primarily by End Points, which will be Hosts/IP Stacks of = various types. The biggest function we had in mind for the Middle = Boxes, was to just not drop or alter the PDM. My question for you is = whether you think we SHOULD craft additional PDM function that CAN be = populated and/or utilized expressly for or by Middle Boxes? This would likely involve more complexity and overhead, but may be = warranted if associated value is perceived. I would also like endorse Nalini's answer on your great and very = fascinating question about The APP, TCP and other time breakdowns. As = a lowly customer/end user (while Nalini is a Diagnostic Software Expert), = I share her view on the value of the =22Network Triage=22. Knowing = whether the time is being spent in the Host, Network and in what = direction, is critically valuable. This may tell you all you need to = know, or other tools take over at that point for more granular = diagnostics. So, in my view that level of granular diagnostics is = beyond the scope of the PDM, but would luv, luv, luv to talk more about = this with you. Thanks again and look forward to seeing you in Vancouver=21 Mike From: Nalini Elkins =5Bmailto:nalini.elkins=40insidethestack.com=5D Sent: Tuesday, October 15, 2013 9:44 AM To: MORTON, ALFRED C (AL); ippm=40ietf.org Cc: Sigfrido Perdomo; = keven.haining=40usbank.com; Bill = Jouris; Ackermann, Michael Subject: Re: =5Bippm=5D Fw: New Version Notification for = draft-elkins-ippm-pdm-metrics-00.txt Al, Thanks for your thorough examination and great comments. My responses are = inline. Also, if you have time in Vancouver, Mike & I would like to ask = you to have lunch or dinner on us. It is the least we can do for all = your help=21 Please let us know if you have a free day. >Early in the Intro, the various time/number fields are referred to as = =22base metrics=22 themselves. >I know you'll want to clarify that (they are just fields). Sure. >In section 1.2: in addition to time and seq number for current packet: > PSNLR : Packet Sequence Number Last Received > TSLR : Timestamp Last Received >the device supplying the header appears to need to maintain flow state to = add >these =22last packet=22 fields. A very strong justification is probably = needed. >Later, I see that the Server host essentially has to store the fields = across >request-response pairs. Lower and higher layers need to work together, >somehow. The Destination Options Header is created only by the OS's at the end = points. That is, the Microsofts, linuxes, and IBM's of the world. The OS = at the end point already maintains state. If you think of TCP TimeWait = status for example. The connection is in TimeWait status for 2 * MSL. = So, obviously state is being maintained. Anyway, all the OS's have = control blocks associated with each active connection. Now, there is going to be some discussion by the OS vendors about non-TCP = protocols=21 I have participated in those discussions with IBM in a = former life (when they OEMed a product of mine & I wanted them to do = something=21) but I believe that they are persuadable. I am guessing = that this information is already being maintained. All we are asking for = is for it to be exposed. Our header is not for middle boxes. We are not asking for router, etc. to = maintain state in this way. >In Section 3.1 and 3.2, it's not clear which PDM time-stamps support the = (round-trip delay >and server delay) metrics. When you look at RFC2681, it should be fairly = clear where >the time stamps are applied, and that needs to carry though here (though = I see it later >in the example). I will clarify. >Looking at the example in section 4, there can be a significant delay = between when >the application layer transfers packets to TCP's send buffer and when the = packets are >actually sent =22on the wire=22 (as we say in IPPM), which happens after = the IP header is >applied (or most of the header, in some cases). How would accuracy be = maintained >across all the different layers? >Maybe another way to phrase the question is this: >How does the process that adds the PDM header (with last Seq number 25) = know >which packet to add it to? There are 2 questions here. First, it will be the IP layer adding the = times. Yes, I know that it is a =22gross=22 measurement comprising of a = number of components. But, then so is one-way delay. That is, there are = multiple components within the path. The purpose of our measurements is = to allow the diagnostician to do very quick triage. That is, to say, is = the problem in the network or the server? Then, we hand the problem off = to the right group who can runmore detailed diagnostic tests. In our experience, this is a very valuable kind of measurement to have. A = great deal of time, effort and money is spent at large end user sites to = determine just this. Anecdotal evidence tells me that this is true for = home users of the Internet also. My working life has been spent at large = data centers, so that I can answer to without any hesitation. > I note that there is IPR declared on this draft, and licensing is not = clear. Yes, we do have IPR. I hope I have declared it properly=21 Please let me = know if I have not. We have not decided on the exact nature of the = licensing but it will be very reasonable. We want the technology adopted. = There are more advanced metrics which can be created from these which is the primary = reason for the IPR. BTW, we are starting to engage in discussions also with folks looking at a = new WG. = https://sites.google.com/site/transportprotocolservices/home/charter-propos= al-before-bof We feel our metrics / header can help with a unified Simple Congestion = Control (SCC) and Inter-Layer Communication (ILC). That is some of our = other work. The above group seems to feel that work would fit in with = their efforts=21 I feel that the fields we propose are simple yet very = powerful. Many uses can be made of them. I can tell you more on this, = if you have interest. ________________________________________ From: ippm-bounces=40ietf.org = =5Bippm-bounces=40ietf.org=5D On Behalf Of = Nalini Elkins = =5Bnalini.elkins=40insidethestack.com=5D Sent: Friday, October 04, 2013 9:10 AM To: WG (v6ops=40ietf.org); 6man WG; = ippm=40ietf.org Cc: Sigfrido Perdomo; = keven.haining=40usbank.com; Bill = Jouris; Ackermann Michael Subject: =5Bippm=5D Fw: New Version Notification for = draft-elkins-ippm-pdm-metrics-00.txt We have submitted a number of drafts. Some are new and some are updates = to our existing PDM proposal. We would appreciate any comments, = questions, and corrections from the lists. The new ones are: 1. In IPPM: http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt This describes the base and derived metrics which can be obtained from the = IPv6 PDM DO Extension Header. 2. In TicToc: http://www.ietf.org/internet-drafts/draft-ackermann-tictoc-pdm-ntp-usage-00= =2Etxt This describes how NTP may be implemented to support PDM. The updates are as follows 1. In 6man: http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt This is the layout of the PDM DO header. 2. In v6ops: http://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-packet-sequence= -needed-01.txt http://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-pdm-recommended= -usage-01.txt http://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-end-to-end-rt-n= eeded-01.txt These are background for the proposal. Thanks, Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com ----- Forwarded Message ----- From: =22internet-drafts=40ietf.org=22 = > To: Nalini Elkins = >; William Jouris = > Sent: Thursday, October 3, 2013 8:04 PM Subject: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt A new version of I-D, draft-elkins-ippm-pdm-metrics-00.txt has been successfully submitted by Nalini Elkins and posted to the IETF repository. Filename: draft-elkins-ippm-pdm-metrics Revision: 00 Title: IPPM Considerations for the IPv6 PDM Extension Header Creation date: 2013-10-03 Group: Individual Submission Number of pages: 14 URL: = http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt Status: = http://datatracker.ietf.org/doc/draft-elkins-ippm-pdm-metrics Htmlized: http://tools.ietf.org/html/draft-elkins-ippm-pdm-metrics-00 Abstract: To diagnose performance and connectivity problems, metrics on real (non-synthetic) transmission are critical for timely end-to-end problem resolution. Such diagnostics may be real-time or after the fact, but must not impact an operational production network. These metrics are defined in the IPv6 Performance and Diagnostic Metrics Destination Option (PDM). The base metrics are: packet sequence number and packet timestamp. Other metrics may be derived from these for use in diagnostics. This document specifies such metrics, their calculation, and usage. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_4FC37E442D05A748896589E468752CAA0CA85E57PWN401EA160entc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

Thanks Al,

 

And yes, the information you provided is very = helpful and informative. 

 

As you mentioned, the RTT approach has certain = shortcomings, that we are aware of and are trying to allow the PDM to be = more resilient to.  

 

Right now PDM is mainly for end point = hosts.   Could be used by  &=238220;Middleboxes&=238221; in = it&=238217;s present form, but if said Middleboxes are going to be active = in this space and derive optimal value,  my initial thought is that a = separate PDM type could be crafted for those = situations/devices.    More thought would need to be put = into this, but I gather from your comments it is at least worth looking = into. 

 

Once again thanks for your feedback and look = forward to more, and to meeting you=21

 

Mike

 

 

 

From: MORTON, ALFRED C (AL) =5Bmailto:acmorton=40att.com=5D
Sent: Monday, October 21, 2013 8:27 PM
To: Ackermann, Michael; Nalini Elkins; ippm=40ietf.org
Cc: Sigfrido Perdomo; keven.haining=40usbank.com; Bill Jouris
Subject: RE: =5Bippm=5D Fw: New Version Notification for = draft-elkins-ippm-pdm-metrics-00.txt

 

Hi = Michael,

 

Regarding one of your questions below:

My question for you is whether you think we = SHOULD craft additional PDM function that  CAN be populated and/or = utilized expressly for or by Middle Boxes?  

This would likely involve more complexity and = overhead, but may be warranted if associated value is perceived.  

 

Yes, = but it has been attempted by dedicated flow monitoring = appliances.

I did = some research and reading about this topic today.

Have a = look at:

http://tools.ietf.org/html/draft-mornulo-ippm-registry-colu= mns-01=23section-6

and the = references.

 

This is = a case of completely passive RTT measurement on = TCP(SYN/SYN_ACK)

request = response pairs, but with the addition of the IPv6 PDM, one = could

attribute the delay properly to network beyond the monitoring = point

and = server (the later doesn't change).  The main point is that it should be

do-able = to do the correlations mid-path, without help from the = app

(as you = would have at the server end).

 

Of = course, there's a cost for these middlebox monitoring = instances,

and you = have to have sufficient coverage to observe both directions

of the = connection. So, what's needed is a compelling case where = troubleshooting

is = enhanced by the middlebox measurements, perhaps when multiple = networks

are = involved in the path.

 

hope = this helps,

Al

 

 

 

 

Hi Al,

 

Echoing Nalini&=238217;s thoughts regarding =  your great comments/questions and how excited we are about the = potential of working with you and your teams. 

 

Nalini&=238217;s answers are great in my view = and I have one comment/question on the topic of &=238220;Middle = Boxes&=238221;, which in my view includes Routers and = Firewalls.     As Nalini said, the PDM was conceived to be populated and utilized primarily =  by End Points, which will be Hosts/IP Stacks of various = types.     The biggest function we had in mind for the = Middle Boxes, was to just not drop or alter the = PDM.      My question for you is whether you think we SHOULD craft additional PDM function that =  CAN be populated and/or utilized expressly for or by Middle = Boxes?  

This would likely involve more complexity and = overhead, but may be warranted if associated value is perceived.  

 

I would also like endorse Nalini&=238217;s = answer on your great and very fascinating question about The APP, TCP and = other time breakdowns.      As a lowly customer/end user (while Nalini is a Diagnostic Software Expert), I share her view on = the value of the &=238220;Network Triage&=238221;.     = Knowing whether the time is being spent in the Host, Network and in what = direction, is critically valuable.    This may tell you all = you need to know, or other tools take over at that point for more granular = diagnostics.    So, in my view that level of granular = diagnostics is beyond the scope of the PDM, but would luv, luv, luv to = talk more about this with you.  

 

Thanks again and look forward to seeing you in = Vancouver=21

 

Mike

 

 

 

 

Al,

 

Thanks for your thorough examination and great comments.  My = responses are inline.   Also, if you have time in Vancouver, Mike = & I would like to ask you to have lunch or dinner on us.   It is the least we can do for all your help=21  Please = let us know if you have a free day.

 


>Early in the Intro, the various time/number fields are referred to as = "base metrics" themselves.
>I know you'll want to clarify that (they are just = fields).

 

Sure.

 

>In section 1.2: in addition to time and seq = number for current packet:

 >                PSNLR : = Packet Sequence Number Last Received
 >               TSLR  : = Timestamp Last Received

>the device supplying the header appears to need to maintain flow state = to add
>these "last packet" fields. A very strong justification is = probably needed.
>Later, I see that the Server host essentially has to store the fields = across
>request-response pairs. Lower and higher layers need to work = together,
>somehow.

The Destination Options Header is created only by the OS's at the end = points.  That is, the Microsofts, linuxes, and IBM's of the world. =  The OS at the end point already maintains state.   If you think = of TCP TimeWait status for example.   The connection is in TimeWait status for 2 * MSL.  So, obviously state is being = maintained.  Anyway, all the OS's have control blocks associated with = each active connection.

 

Now, there is going to be some discussion by the = OS vendors about non-TCP protocols=21  I have participated in those = discussions with IBM in a former life (when they OEMed a product of mine & I wanted them to do something=21)  but I believe that they are = persuadable.   I am guessing that this information is already being = maintained.  All we are asking for is for it to be = exposed.

 

Our header is not for middle boxes.  We are = not asking for router, etc. to maintain state in this way.


>In Section 3.1 and 3.2, it's not clear which PDM time-stamps support = the (round-trip delay
>and server delay) metrics. When you look at  RFC2681, it should = be fairly clear where
>the time stamps are applied, and that needs to carry though here = (though I see it later
>in the example).

 

I will clarify.

 

>Looking at the example in section 4, there = can be a significant delay between when
>the application layer transfers packets to TCP's send buffer and when = the packets are
>actually sent "on the wire" (as we say in IPPM), which = happens after the IP header is
>applied (or most of the header, in some cases). How would accuracy be = maintained
>across all the different layers?

>Maybe another way to phrase the question is this:
>How does the process that adds the PDM header (with last Seq number = 25) know
>which packet to add it to? 

 

There are 2 questions here.  First, it will = be the IP layer adding the times.  Yes, I know that it is a = "gross" measurement comprising of a number of components. =  But, then so is one-way delay.  That is,  there are multiple components within the = path.   The purpose of our measurements is to allow the diagnostician = to do very quick triage.  That is, to say, is the problem in the = network or the server?  Then, we hand the problem off to the right group who can runmore detailed diagnostic tests. =   

 

In our experience, this is a very valuable kind = of measurement to have.  A great deal of time, effort and money is = spent at large end user sites to determine just this.   Anecdotal = evidence tells me that this is true for home users of the Internet also.   My = working life has been spent at large data centers, so that I can answer to = without any hesitation.

 

> I note that there is IPR declared on = this draft, and licensing is not clear.

 

Yes, we do have IPR.  I hope I have = declared it properly=21  Please let me know if I have not.  We = have not decided on the exact nature of the licensing but it will be very = reasonable.  We want the technology adopted.    There are

more advanced metrics which can be created from = these which is the primary reason for the IPR.

 

We feel our metrics / header can help with a = unified Simple Congestion Control (SCC) and Inter-Layer Communication = (ILC).   That is some of our other work.   The above group = seems to feel that work would fit in with their efforts=21  I feel that the fields = we propose are simple yet very powerful.  Many uses can be made of = them.   I can tell you more on this, if you have = interest.

 


________________________________________
From: ippm-bounces=40ietf.org = =5Bippm-bounces=40ietf.org=5D = On Behalf Of Nalini Elkins =5Bnalini.elkins=40insi= dethestack.com=5D
Sent: Friday, October 04, 2013 9:10 AM
To: WG (v6ops=40ietf.org); = 6man WG; ippm=40ietf.org
Cc: Sigfrido Perdomo; keven.haining=40usbank.com; Bill Jouris; Ackermann Michael
Subject: =5Bippm=5D Fw: New Version Notification for      =   draft-elkins-ippm-pdm-metrics-00.txt

We have submitted a number of drafts.  Some are new and some are = updates to our existing PDM proposal.  We would appreciate any = comments, questions, and corrections from the lists.


The new ones are:

1.  In IPPM:

http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metric= s-00.txt

This describes the base and derived metrics which can be obtained from the = IPv6 PDM DO Extension Header.


2.  In TicToc:

http://www.ietf.org/internet-drafts/draft-ackermann-ticto= c-pdm-ntp-usage-00.txt

This describes how NTP may be implemented to support PDM.


The updates are as follows

1.  In 6man:

http://www.ietf.org/internet-drafts/draft-elkins-ippm= -pdm-metrics-00.txt

This is the layout of the PDM DO header.


2.  In v6ops:

http://www.ietf.org/internet-drafts/draft-elkin= s-v6ops-ipv6-packet-sequence-needed-01.txt

http://www.ietf.org/internet-drafts/draft-elkins= -v6ops-ipv6-pdm-recommended-usage-01.txt

http://www.ietf.org/internet-drafts/draft-elkins-= v6ops-ipv6-end-to-end-rt-needed-01.txt

These are background for the proposal.


Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

----- Forwarded Message -----
From: "internet-drafts=40ietf.org" <internet-drafts=40ietf.org>
To: Nalini Elkins <nalini.elkins=40insi= dethestack.com>; William Jouris <bill.jouris=40insideth= estack.com>
Sent: Thursday, October 3, 2013 8:04 PM
Subject: New Version Notification for = draft-elkins-ippm-pdm-metrics-00.txt


A new version of I-D, draft-elkins-ippm-pdm-metrics-00.txt
has been successfully submitted by Nalini Elkins and posted to the
IETF repository.

Filename:    draft-elkins-ippm-pdm-metrics
Revision:    00
Title:        IPPM Considerations for the IPv6 PDM = Extension Header
Creation date:    2013-10-03
Group:        Individual Submission
Number of pages: 14
URL:            http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt
Status:          http://datatracker.ietf.org/doc/draft-elkins-ippm-pdm-metrics
Htmlized:        http://tools.ietf.org/html/draft-elkins-ippm-pdm-metrics-00


Abstract:
  To diagnose performance and connectivity problems, metrics on = real
  (non-synthetic) transmission are critical for timely end-to-end
  problem resolution. Such diagnostics may be real-time or after = the
  fact, but must not impact an operational production network. = These
  metrics are defined in the IPv6 Performance and Diagnostic = Metrics
  Destination Option (PDM). The base metrics are: packet sequence
  number and packet timestamp. Other metrics may be derived from = these
  for use in diagnostics.  This document specifies such metrics, = their
  calculation, and usage.





Please note that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

The IETF Secretariat

 

The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please = notify the sender, by electronic mail or telephone, of any unintended = receipt and delete the original message without making any = copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.


The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

--_000_4FC37E442D05A748896589E468752CAA0CA85E57PWN401EA160entc_-- From mackermann@bcbsm.com Thu Oct 24 09:52:17 2013 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 EF7B511E835A for ; Thu, 24 Oct 2013 09:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.057 X-Spam-Level: X-Spam-Status: No, score=-6.057 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFeWgbWchgi8 for ; Thu, 24 Oct 2013 09:51:27 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id 794EC11E8194 for ; Thu, 24 Oct 2013 09:50:38 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id A70652FF69B for ; Thu, 24 Oct 2013 11:50:17 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id A162830743A; Thu, 24 Oct 2013 11:50:16 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 4EDEE4F8051; Thu, 24 Oct 2013 12:40:02 -0400 (EDT) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva1.bcbsm.com (Postfix) with ESMTP id 2FEE74F805A; Thu, 24 Oct 2013 12:40:02 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%13]) with mapi id 14.01.0438.000; Thu, 24 Oct 2013 12:50:02 -0400 From: "Ackermann, Michael" To: Ray Hunter , Nalini Elkins Thread-Topic: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt Thread-Index: AQHOyuiEsp3P94CgjEaaXBige+0sO5n9xySAgAJIKwCAAHiqAIAChzTA Date: Thu, 24 Oct 2013 16:50:01 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> In-Reply-To: <526616C4.40304@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 24 Oct 2013 23:51:37 -0700 Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [ippm] [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt 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, 24 Oct 2013 16:52:17 -0000 Hi Ray. And thanks again for all your insightful comments/questions.=20 I am a little late in responding, so let me just tack on a little to what = Nalini and others have already said.=20 Your point 4 seems to indicate that all nodes in a desired time = synchronization domain need to be synched to the same master clock. This = has not been my experience. As long as the required Stratum level is = realized, for the level of accuracy required by the situation or = application, the proper level of time synchronization is achieved. = Example would be that if one node in the NTP domain is referencing a GPS = Stratum 0 and another node is referencing a separate Stratum 0 source, the = two nodes should be Stratum 1 and within that level of accuracy. =20 This is something we have implemented across several disparate enterprises = and it has worked well for us. I am wondering if your experience has = yielded different results? You also had two other points/questions, that I believe Nalini already = responded to, but.............. 1. The possibility that =22Middleboxes=22 could utilize PDM, is very = intriguing to me. I believe this would be more difficult to = add/implement, but worth the effort if the Middlebox vendors would = perceive value and actually use PDM. Not sure how to determine if this = would be the case or not?=20 2. It would be ideal to have only 1 PDM format that handles both time = sycnronized and non synchronized situations. I do not readily see how to = achieve this. Would love to talk to you some more if you have some = ideas=21 =20 Again, thanks for your great input, thoughts and questions=21=21=21 (and = hopefully more to come). =20 Mike -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Ray Hunter Sent: Tuesday, October 22, 2013 2:10 AM To: Nalini Elkins Cc: v6ops WG; 6man WG; ippm=40ietf.org Subject: Re: =5Bv6ops=5D Fw: New Version Notification for = draft-elkins-6man-ipv6-pdm-dest-option-04.txt > Nalini Elkins > 22 October 2013 00:58 >> 1) encoding has to be fast, but decoding does not > > True > >> 2) a node's clock could be either in our out of synch with some=20 >> notional master clock (e.g. via NTP) >> 3) two clocks could be in synch to a master source, but the master =20 >> sources may themselves not share a common source (one sourced from=20 >> GPS, one from DCF77) >> 4) the key to being able to perform the end to end calculations is=20 >> whether two communicating nodes are synchronised to the same master=20 >> clock (within some level of error/jitter) >> 5) the absolute time is not particularly important > > > This is true for PDM 1 only. PDM 2 does not require time synchronization. > >> Q1. Why do you want to encode differences as deltas in the case of an = unsynchronised/ free running clock? >> Isn't that slow, and difficult for hardware implementations to achieve = (e.g. TCP offload)? Doesn't it also require maintaining large amounts of = state in the sending node. >> > > 1. I think that it is going to be interesting to see how hardware is = going to handle TCP offload with IPv6 extension headers. I do not see = why PDM 2 would be so much harder than PDM 1 for an OS. > Can you tell me which end host operating systems are doing TCP offload = in hardware? =20 IMHO Not a relevant question. As a standards body we should be looking to = the future. There are many operations that are delegated to microcode. If you specified the packet with one single way of encapsulating = timestamps, then hardware or interface microcode could add the timestamp = at the last possible moment before the packet reached the wire, without = having to examine the original packet contents, or knowing the context of = the communicating nodes. I think that's very desirable. > I know some OS's which process TCP segmentation in hardware. But at = this point, the packet is already crafted. Also some do IP checksum = offload in hardware but that does not apply to IPv6 as there is no IP = header checksum. > > > 2. End hosts already maintain quite a bit of state. Every OS has = control blocks to handle events such as TCP duplicate packets, round trip = time, congestion window, etc. We are NOT suggesting > that the PDM headers be used in middle boxes. That is, we are NOT = asking routers to maintain state. So what? Why add to the problem? Why does the timestamp require synchronisation with that other TCP state? Isn't it better to define a solution that is independent of the upper = layer header transport protocol? Why not allow middleboxes (or node hardware) to insert the = timestamp header on the fly? > >> Why not just encode the timestamp as-is and perform the appropriate = difference calculation during decoding? > > If clocks are out of synch, you could end up having it look like you = received the packet before you sent it. No. I'm not suggesting you use the same decoding algorithm: only that you = define a single common encoding algorithm that combines all the = information required for PDM 1 and PDM 2 calculations. Having to chose = which packet encoding to use in advance is problematic IMHO. >> Q2. Why do you need two separate packet formats at all? > >> Why not have a common format for all cases, containing a timestamp=20 >> based on the local clock, plus an optional field containing a flag=20 >> that states if the local timestamp is coordinated to some master=20 >> clock, plus an identifier for the master clock. > >> You could then encode whether a node had a free-running clock (case=20 >> 2), a synchronised clock (case 1), and whether it was synched via NTP=20 >> to some stratum 0 source e.g. GPS, and also some identification of=20 >> the stratum 1 source (IPv6 address). > >> Two communicating nodes could then use e.g. NTP trace to see if they=20 >> shared a common clock source or not, before performing their = calculations. > > We are trying to craft a solution with PDM 2 for those situations where = time synchronization is not practical, possible or desired. I understand the aim, but let me ask my question a different way. Imagine there are nodes A&B that with clocks synched to DCF77. Imagine there are nodes C&D that with clocks synched to GPS. Node E has free running clock (possibly because the GPS receiver is down). Which packet format PDM type 1 or PDM type 2 do you use between each pair = of nodes, and how does the sending node know that? Scale this solution to 100K hosts. > > ---------------------------------------------------------------------- > -- -- Regards, RayH _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From v6ops@globis.net Thu Oct 24 10:53:45 2013 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 BE93211E8389; Thu, 24 Oct 2013 10:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhAtgmm-MqFl; Thu, 24 Oct 2013 10:53:44 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0758C21E809F; Thu, 24 Oct 2013 10:52:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 08B7F8700B3; Thu, 24 Oct 2013 19:51:56 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZEcBsCHet+2; Thu, 24 Oct 2013 19:51:55 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id CED81870056; Thu, 24 Oct 2013 19:51:55 +0200 (CEST) Message-ID: <52695E3A.9090406@globis.net> Date: Thu, 24 Oct 2013 19:51:54 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: "Ackermann, Michael" References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 24 Oct 2013 23:51:37 -0700 Cc: v6ops WG , "ippm@ietf.org" , 6man WG Subject: Re: [ippm] [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt 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, 24 Oct 2013 17:53:46 -0000 > Ackermann, Michael > 24 October 2013 18:50 > Hi Ray. > And thanks again for all your insightful comments/questions. > > I am a little late in responding, so let me just tack on a little to what Nalini and others have already said. > > Your point 4 seems to indicate that all nodes in a desired time synchronization domain need to be synched to the same master clock. No. I think what I said was that the level of certainty in your measurements is dependent on the level of synchronisation of the 2 clock sources if you are calculating a delta of timestamp of clock 1 - timestamp clock 2. I think it might be instructive to go back and look at high school physics books on making measurements, precision, accuracy, and error estimations, especially when taking the difference of two measurements, or making other calculations on top of raw observations. For example, as far as I know, DFC-77 is not compensated for speed of light travel time from Frankfurt: that is a manual offset. So even if two nodes using DCF-77 that are geographically spread across Europe are perfectly synchronised to the incoming radio signal, they might have a constant offset compared to the "absolute" time in Frankfurt. That may or may not have an effect on one way trip measurement times you measure, depending on how you perform your calculations. I think this link might be instructive. http://www.hopf.com/en/dcf77-gps_en.html Equally a stratum 0 clock can be free running if it loses it's radio signal. I see time stamps in the picosecond range defined in the protocol, and errors on DCF-77 of up to 150mS...... completely different orders of magnitude of precision. > This has not been my experience. As long as the required Stratum level is realized, for the level of accuracy required by the situation or application, the proper level of time synchronization is achieved. Example would be that if one node in the NTP domain is referencing a GPS Stratum 0 and another node is referencing a separate Stratum 0 source, the two nodes should be Stratum 1 and within that level of accuracy. > This is something we have implemented across several disparate enterprises and it has worked well for us. I am wondering if your experience has yielded different results? Absolutely. Different NTP servers are not guaranteed to be synched to each other. They're close. But not in the picosecond range. > You also had two other points/questions, that I believe Nalini already responded to, but.............. > > 1. The possibility that "Middleboxes" could utilize PDM, is very intriguing to me. I believe this would be more difficult to add/implement, but worth the effort if the Middlebox vendors would perceive value and actually use PDM. Not sure how to determine if this would be the case or not? Why would it be difficult? If you can define the encoder in your protocol in terms of absolute local timestamps only, plus a provenance of the clock used for the timestamp, it would be a simple matter of inserting an additional destination header into every forwarded packet when the middlebox forwards it. > 2. It would be ideal to have only 1 PDM format that handles both time sycnronized and non synchronized situations. I do not readily see how to achieve this. Would love to talk to you some more if you have some ideas! Well for example, PDM 2 uses a local delta for the last packet transmission time: DELTALS. IMHO If you know absolute timestamp 1 of clock 1 @ last packet n sent from node 1, and absolute timestamp 2 of clock 1 @ last packet n+1 sent from node 1, I see it as a trivial matter to calculate the delta time between sending packet n and sending packet n+1 remotely at a decoder at a remote location (as observed at node 1), which will be identical to DELTALS, rather than calculating this value locally in the transmitting node 1 before sending the packet. [you can only encode this DELTALS value in packet 2.. anyway] I suspect the step that you are missing is coupling a timestamp to a clock and a packet ID and an event, and specifying only two timestamps in the packet, rather than both nodes timestamping the same events with their respective local clocks. You could also have timestamps for last received n from node 2 based on clock 1 sent in replies to packet n by node 1, and last received n+1 from node 2 based on clock1 sent in replies to packet n+1 by node 1, so that you can calculate DELTALR remotely too (as observed at the location of the receiving node 1). That way you avoid the need to calculate delta locally, or any need to track sessions in the transmitter (so that you can calculate a delta in the transmitter). You do obviously have to calculate a delta and track sessions in the decoder, but that is not time critical, and also can be applied to a subset of all traffic. > > Again, thanks for your great input, thoughts and questions!!! (and hopefully more to come). > > Mike > It seems to me that what you are essentially doing with this protocol is largely what NTP does anyway. So examining the NTP RFC might give you tips on what timestamps you need. And equally, since you are going to be sending high bandwidth synch traffic between 2 nodes, you might want to consider feeding the results back into NTP to see if you can improve the clock synchronisation between measuring nodes. -- Regards, RayH From mackermann@bcbsm.com Thu Oct 24 16:45:20 2013 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 E4BBD11E8269 for ; Thu, 24 Oct 2013 16:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.041 X-Spam-Level: X-Spam-Status: No, score=-6.041 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1JPM0mvHT6y for ; Thu, 24 Oct 2013 16:45:09 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id B101011E8249 for ; Thu, 24 Oct 2013 16:45:08 -0700 (PDT) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 09E2D9AD9F0 for ; Thu, 24 Oct 2013 18:45:08 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id EC5BF9AD9E9; Thu, 24 Oct 2013 18:45:06 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id DEE554F804D; Thu, 24 Oct 2013 19:34:51 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva1.bcbsm.com (Postfix) with ESMTP id D10194F8049; Thu, 24 Oct 2013 19:34:51 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([fe80::8db:9ce7:e2cf:8565%13]) with mapi id 14.01.0438.000; Thu, 24 Oct 2013 19:44:52 -0400 From: "Ackermann, Michael" To: Ray Hunter Thread-Topic: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt Thread-Index: AQHO0OGzc1wNgnhly0SIwwwBJHHHZZoEfl4g Date: Thu, 24 Oct 2013 23:44:51 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <52695E3A.9090406@globis.net> In-Reply-To: <52695E3A.9090406@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 24 Oct 2013 23:51:37 -0700 Cc: v6ops WG , 6man WG , "ippm@ietf.org" , "bill.jouris@insidethestack.com" Subject: Re: [ippm] [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt 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, 24 Oct 2013 23:45:20 -0000 Ray Your Comment:=20 No. I think what I said was that the level of certainty in your = measurements is dependent on the level of synchronisation of the 2 clock = sources if you are calculating a delta of timestamp of clock 1 - timestamp = clock 2. My Response: Then it sounds like we are in agreement. Given the appropriate stratum = level at both nodes, the desired level of time synchronization is = achieved.=20 Your Comment:=20 I think it might be instructive to go back and look at high school physics = books on making measurements, precision, accuracy, and error estimations, = especially when taking the difference of two measurements, or making other = calculations on top of raw observations My Response: Not sure exactly what this means but I can say that this = sounds like theoretical doubt that time synchronization will not work = properly in geographically dispersed environments? I can tell you that = it does in our experiences and that the surrounding = protocols/implementations are crafted to account for such vicissitudes. =20 I will say that I have no field experience with DCF-77 sources, only GPS = and Cesium. =20 Your Comment: Equally a stratum 0 clock can be free running if it loses it's radio signal. My Response:=20 This comment sort of confused me as well, but suffice to say, if any = component is broken, results will be impaired. Obviously this is not = limited to the time synch subject. =20 Finally, your comment about =22Middleboxes=22. I hope it can be as = simple to accommodate as you describe. My concern is that if there are = numerous middleboxes, the fields may get repetitively overlaid, or there = will need to be so many separate fields, we could incur excessive = complexity or overhead. Given that we can accomplish this with a = workable solution, I am certainly all for it. =20 The more information I can have to manage networks and solve problems, the = better=21 Thanks again for your thoughts, inputs and questions=21 Mike =20 -----Original Message----- From: Ray Hunter =5Bmailto:v6ops=40globis.net=5D=20 Sent: Thursday, October 24, 2013 1:52 PM To: Ackermann, Michael Cc: Nalini Elkins; v6ops WG; 6man WG; ippm=40ietf.org Subject: Re: =5Bv6ops=5D Fw: New Version Notification for = draft-elkins-6man-ipv6-pdm-dest-option-04.txt > Ackermann, Michael > 24 October 2013 18:50 > Hi Ray. > And thanks again for all your insightful comments/questions.=20 > > I am a little late in responding, so let me just tack on a little to = what Nalini and others have already said.=20 > > Your point 4 seems to indicate that all nodes in a desired time = synchronization domain need to be synched to the same master clock.=20 No. I think what I said was that the level of certainty in your = measurements is dependent on the level of synchronisation of the 2 clock = sources if you are calculating a delta of timestamp of clock 1 - timestamp = clock 2. I think it might be instructive to go back and look at high school physics = books on making measurements, precision, accuracy, and error estimations, = especially when taking the difference of two measurements, or making other = calculations on top of raw observations. For example, as far as I know, DFC-77 is not compensated for speed of = light travel time from Frankfurt: that is a manual offset. So even if two = nodes using DCF-77 that are geographically spread across Europe are = perfectly synchronised to the incoming radio signal, they might have a = constant offset compared to the =22absolute=22 time in Frankfurt. That may = or may not have an effect on one way trip measurement times you measure, = depending on how you perform your calculations. I think this link might be instructive. http://www.hopf.com/en/dcf77-gps_en.html Equally a stratum 0 clock can be free running if it loses it's radio signal. I see time stamps in the picosecond range defined in the protocol, and = errors on DCF-77 of up to 150mS...... completely different orders of = magnitude of precision. > This has not been my experience. As long as the required Stratum = level is realized, for the level of accuracy required by the situation or = application, the proper level of time synchronization is achieved. = Example would be that if one node in the NTP domain is referencing a GPS = Stratum 0 and another node is referencing a separate Stratum 0 source, the = two nodes should be Stratum 1 and within that level of accuracy. =20 > This is something we have implemented across several disparate = enterprises and it has worked well for us. I am wondering if your = experience has yielded different results? Absolutely. Different NTP servers are not guaranteed to be synched to each = other. They're close. But not in the picosecond range. > You also had two other points/questions, that I believe Nalini already = responded to, but.............. > > 1. The possibility that =22Middleboxes=22 could utilize PDM, is very = intriguing to me. I believe this would be more difficult to = add/implement, but worth the effort if the Middlebox vendors would = perceive value and actually use PDM. Not sure how to determine if this = would be the case or not?=20 Why would it be difficult? If you can define the encoder in your protocol = in terms of absolute local timestamps only, plus a provenance of the clock = used for the timestamp, it would be a simple matter of inserting an = additional destination header into every forwarded packet when the = middlebox forwards it. > 2. It would be ideal to have only 1 PDM format that handles both time = sycnronized and non synchronized situations. I do not readily see how to = achieve this. Would love to talk to you some more if you have some = ideas=21 =20 Well for example, PDM 2 uses a local delta for the last packet = transmission time: DELTALS. IMHO If you know absolute timestamp 1 of clock 1 =40 last packet n sent = from node 1, and absolute timestamp 2 of clock 1 =40 last packet n+1 sent = from node 1, I see it as a trivial matter to calculate the delta time = between sending packet n and sending packet n+1 remotely at a decoder at a = remote location (as observed at node 1), which will be identical to = DELTALS, rather than calculating this value locally in the transmitting = node 1 before sending the packet. =5Byou can only encode this DELTALS = value in packet 2.. anyway=5D I suspect the step that you are missing is coupling a timestamp to a clock = and a packet ID and an event, and specifying only two timestamps in the = packet, rather than both nodes timestamping the same events with their = respective local clocks. You could also have timestamps for last received n from node 2 based on = clock 1 sent in replies to packet n by node 1, and last received n+1 from = node 2 based on clock1 sent in replies to packet n+1 by node 1, so that = you can calculate DELTALR remotely too (as observed at the location of the = receiving node 1). That way you avoid the need to calculate delta locally, = or any need to track sessions in the transmitter (so that you can = calculate a delta in the transmitter). You do obviously have to calculate = a delta and track sessions in the decoder, but that is not time critical, = and also can be applied to a subset of all traffic. > > Again, thanks for your great input, thoughts and questions=21=21=21 = (and hopefully more to come). =20 > > Mike > It seems to me that what you are essentially doing with this protocol is = largely what NTP does anyway. So examining the NTP RFC might give you tips on what timestamps you need. = And equally, since you are going to be sending high bandwidth synch = traffic between 2 nodes, you might want to consider feeding the results = back into NTP to see if you can improve the clock synchronisation between = measuring nodes. -- Regards, RayH The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nalini.elkins@insidethestack.com Sun Oct 27 07:59:35 2013 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 B5FCB21E80C9 for ; Sun, 27 Oct 2013 07:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jUxzjrhXkNl for ; Sun, 27 Oct 2013 07:59:34 -0700 (PDT) Received: from nm11-vm10.access.bullet.mail.bf1.yahoo.com (nm11-vm10.access.bullet.mail.bf1.yahoo.com [216.109.114.233]) by ietfa.amsl.com (Postfix) with ESMTP id C775621E80CC for ; Sun, 27 Oct 2013 07:59:20 -0700 (PDT) Received: from [66.196.81.155] by nm11.access.bullet.mail.bf1.yahoo.com with NNFMP; 27 Oct 2013 14:59:10 -0000 Received: from [66.196.81.130] by tm1.access.bullet.mail.bf1.yahoo.com with NNFMP; 27 Oct 2013 14:59:10 -0000 Received: from [127.0.0.1] by omp1006.access.mail.bf1.yahoo.com with NNFMP; 27 Oct 2013 14:59:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 815595.41336.bm@omp1006.access.mail.bf1.yahoo.com Received: (qmail 35450 invoked by uid 60001); 27 Oct 2013 14:59:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1382885950; bh=wOKNkdars8PLDZG1U2pbwEK9JDzg+hQGDiwhUmbD9gU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=M9GqXRiO8q9arPfEFFHASp03HBz85vQSFFvRCF6shTKjyq4uVWdB6jXMwkhXAXkgjQAKUCoiIATJqmm1mVJs3b9yIXMHITxh3Hx9J9dx9fSy/u7rF/CocW/mm+pj7z4mRTla6FCeLXyARMcrLDAkqIED8ovNXo9rxrJDgXICjOQ= X-YMail-OSG: E3Q7NPIVM1mjLxS93qGStooceTupQQ440.tdN4CMPnzFe3I zCLYKlmGMdG1jbDG00jNE6DXuNBDOPrOzCC4ZiA077w.FwCFw3xLZ50sWFMs dSD6X1WoNwlDOy0NHkgeIK6dt3Z7ruzDuwdzCn.zqCuuqUGHtI_bao4nFVCs QDwJSXFEb_4gLOSlsAABbOHIdj7WoUTT8oMvU.a62DikDZdv09dkEegYmL8t HkSh_u0Z2wcmDF1Lu7rEbTiAKCqgq3F.WmvRFBMxwcqldGupxm01nuKH3WBG 1jCj3I1vz9mYY4FWBzgkzmAim.km4YECTpDBS9NkeWEPld4xA6OUjOs9rlO5 LuCpdUFhY0Jv9ieFmzupyOz0AgBBPpl4RJBYAcJtkE8JLY3CsBSG7er1bL9U 1Dv_TxRAQ5miJdJfpyaKUp4c.mGb.XGsNZTUPVyXKU93b9TkDEJIXv7q2sjg e3XNNz6.UddmWGS0OYLfishAECfDO9pNEmm.4Ol58jYSfF8NvMU1h0MUaQFX Zv.TSHkmynEfa6684duBuGek4lNMr3GNPgeJnGRH2.dqhviQxHXXRdOUMxNh 47h9hsyJx.oSHv97glGCT47BjSsXqerN2FJah5kbBTMwy0mFpAoqWyt5i606 AWspLK6tsLL2SYeYj_BcaBDXiJfJwdSm5Hz4CdUWXAU2oL6k.K_oYLtPI Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Sun, 27 Oct 2013 07:59:10 PDT X-Rocket-MIMEInfo: 002.001, PiA.WW91ciBwb2ludCA0IHNlZW1zIHRvIGluZGljYXRlIHRoYXQgYWxsIG5vZGVzIGluIGEgZGVzaXJlZCB0aW1lIHN5bmNocm9uaXphdGlvbiBkb21haW4gbmVlZCB0byBiZSBzeW5jaGVkIHRvIHRoZSBzYW1lIG1hc3RlciBjbG9jay7CoCBUaGlzIGhhcyBub3QgYmVlbiBteSBleHBlcmllbmNlLsKgIEFzIGxvbmcgYXMgdGhlIHJlcXVpcmVkIFN0cmF0dW0gbGV2ZWwgaXMgcmVhbGl6ZWQsIGZvciB0aGUgbGV2ZWwgPj5vZiBhY2N1cmFjeSByZXF1aXJlZCBieSB0aGUgc2l0dWF0aW9uIG9yIGFwcGxpY2F0aW8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <585D21EB-BD17-40C7-9C31-67F12EC6712F@bogus.com> Message-ID: <1382885950.30079.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Sun, 27 Oct 2013 07:59:10 -0700 (PDT) From: Nalini Elkins To: joel jaeggli , "Ackermann, Michael" In-Reply-To: <585D21EB-BD17-40C7-9C31-67F12EC6712F@bogus.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-557329641-1382885950=:30079" Cc: Ray Hunter , v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [ippm] [v6ops] New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 14:59:36 -0000 ---1551098171-557329641-1382885950=:30079 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > >Your point 4 seems to indicate that all nodes in a desired time synchron= ization domain need to be synched to the same master clock.=C2=A0 This has = not been my experience.=C2=A0 As long as the required Stratum level is real= ized, for the level >>of accuracy required by the situation or application,= the proper level of time synchronization is achieved.=C2=A0 Example would = be that if one node in the NTP domain is referencing a GPS Stratum 0 and an= other node is referencing a >>separate Stratum 0 source, the two nodes shou= ld be Stratum 1 and within that level of accuracy.=C2=A0=C2=A0=0A=0A>stratu= m is not an indication of either precision or accuracy it=E2=80=99s an inid= ication of a position within the NTP heirachary.=0A=0A=0AGuys, you know, I = wonder if this discussion of time synchronization is distracting us from th= e point of our proposal. =C2=A0=C2=A0=0A=0AWhat we are advocating for is a = capability for embedded diagnostics and performance for all upper layer pro= tocols that is relatively simple to implement. =C2=A0 I am thinking more an= d more that our PDM 2 proposal which does not require time synchronization = is the way to go. =C2=A0 Let me say that this is my opinion only! =C2=A0 Ot= hers on our team believe that they can indeed do time synch within their da= ta centers and want the enhanced capabilities of PDM 1 which requires time = synch.=0A=0ABTW, we have discussed the proposals for PDMs already with one = end host OS vendor who, on initial look, believes it will be easy to implem= ent and should be quite useful. =C2=A0 We are setting up more discussions w= ith their engineering team to see if they can tell us where the pit falls i= n our thinking might be. =C2=A0=C2=A0I hope I can get them to comment publi= cly. =C2=A0 But, that will take a while.=0A=0AAlso, one of my guys has alre= ady done a prototype implementation of PDM 1 going from a simple client to = server which I can show all who are interested in Vancouver. =C2=A0=C2=A0= =0A=C2=A0=0A=0AThanks,=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 6= 59-8360=0Awww.insidethestack.com=0A=0A=0A=0A_______________________________= _ ---1551098171-557329641-1382885950=:30079 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
> >Your point 4 = seems to indicate that all nodes in a desired time synchronization domain n= eed to be synched to the same master clock.  This has not been my expe= rience.  As long as the required Stratum level is realized, for the le= vel >>of accuracy required by the situation or application, the prope= r level of time synchronization is achieved.  Example would be that if= one node in the NTP domain is referencing a GPS Stratum 0 and another node= is referencing a >>separate Stratum 0 source, the two nodes should b= e Stratum 1 and within that level of accuracy.  

>st= ratum is not an indication of either precision or accuracy it=E2=80=99s an = inidication of a position within the NTP heirachary.

Guys, you know, I wonde= r if this discussion of time synchronization is distracting us from the poi= nt of our proposal.   

What we are advocating for is a capability for embe= dded diagnostics and performance for all upper layer protocols that is rela= tively simple to implement.   I am thinking more and more that our PDM= 2 proposal which does not require time synchronization is the way to go. &= nbsp; Let me say that this is my opinion only!   Others on our team be= lieve that they can indeed do time synch within their data centers and want= the enhanced capabilities of PDM 1 which requires time synch.

BTW, w= I hope I can get them to comment publicly.   But, that will take a whil= e.
<= br>
= Also, one of my guys has already done a prototype implementation of PDM 1 g= oing from a simple client to server which I can show all who are interested= in Vancouver.   
 
Thanks,

Nalini= Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.co= m

=
 
---1551098171-557329641-1382885950=:30079-- From v6ops@globis.net Fri Oct 25 10:38:37 2013 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 E3FFB11E8359; Fri, 25 Oct 2013 10:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNoxocoBg6cN; Fri, 25 Oct 2013 10:38:37 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id BD21E11E837F; Fri, 25 Oct 2013 10:38:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 7EB5787007C; Fri, 25 Oct 2013 19:38:11 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzFpEHYhKdgX; Fri, 25 Oct 2013 19:38:11 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 4C26387003F; Fri, 25 Oct 2013 19:38:11 +0200 (CEST) Message-ID: <526AAC81.3050402@globis.net> Date: Fri, 25 Oct 2013 19:38:09 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: "Ackermann, Michael" References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <52695E3A.9090406@globis.net> <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 27 Oct 2013 08:02:43 -0700 Cc: v6ops WG , 6man WG , "ippm@ietf.org" , "bill.jouris@insidethestack.com" Subject: Re: [ippm] [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt 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, 25 Oct 2013 17:38:38 -0000 > Ackermann, Michael > 25 October 2013 01:44 > Ray > > Your Comment: > No. I think what I said was that the level of certainty in your measurements is dependent on the level of synchronisation of the 2 clock sources if you are calculating a delta of timestamp of clock 1 - timestamp clock 2. > My Response: > Then it sounds like we are in agreement. Given the appropriate stratum level at both nodes, the desired level of time synchronization is achieved. > No. We are not in agreement. Stratum is an indication of how far down you are in the hierarchy from any NTP Stratum 0 clock. It says nothing about whether your stratum 0 and my stratum 0 are synchronised. We could both be running caesium clocks, and there could still be an offset if I don't set my reference time of my caesium clock the same as your reference time. When talking about microsecond or picosecond timing that will almost certainly be significant. You really need to know that the true provenance of the clock source is identical in order to make PDM 1 calculations, not just the stratum. Hence my comment to couple some sort of "clock ID" to the timestamp. > Your Comment: > I think it might be instructive to go back and look at high school physics books on making measurements, precision, accuracy, and error estimations, especially when taking the difference of two measurements, or making other calculations on top of raw observations > My Response: Not sure exactly what this means but I can say that this sounds like theoretical doubt that time synchronization will not work properly in geographically dispersed environments? I can tell you that it does in our experiences and that the surrounding protocols/implementations are crafted to account for such vicissitudes. > I will say that I have no field experience with DCF-77 sources, only GPS and Cesium. > > > Your Comment: > Equally a stratum 0 clock can be free running if it loses it's radio signal. > My Response: > This comment sort of confused me as well, but suffice to say, if any component is broken, results will be impaired. Obviously this is not limited to the time synch subject. > > > Finally, your comment about "Middleboxes". I hope it can be as simple to accommodate as you describe. My concern is that if there are numerous middleboxes, the fields may get repetitively overlaid, or there will need to be so many separate fields, we could incur excessive complexity or overhead. Given that we can accomplish this with a workable solution, I am certainly all for it. > The more information I can have to manage networks and solve problems, the better! > > Thanks again for your thoughts, inputs and questions! > > Mike > > > > > > > > > > > From mackermann@bcbsm.com Mon Oct 28 09:13:23 2013 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 CA53221E8095 for ; Mon, 28 Oct 2013 09:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.035 X-Spam-Level: X-Spam-Status: No, score=-6.035 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxoMnofndg9M for ; Mon, 28 Oct 2013 09:13:17 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id CDC0111E827C for ; Mon, 28 Oct 2013 09:13:17 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 267FE2FF69F for ; Mon, 28 Oct 2013 11:13:17 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 23FA3307427; Mon, 28 Oct 2013 11:13:16 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 0CF194F804D; Mon, 28 Oct 2013 12:02:52 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva1.bcbsm.com (Postfix) with ESMTP id E76C24F8049; Mon, 28 Oct 2013 12:02:51 -0400 (EDT) Received: from PWN401EA105.ent.corp.bcbsm.com (10.64.102.241) by PWN401EA100.ent.corp.bcbsm.com (10.64.80.217) with Microsoft SMTP Server (TLS) id 14.1.438.0; Mon, 28 Oct 2013 12:13:14 -0400 Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA105.ent.corp.bcbsm.com ([fe80::f13e:83e4:1dae:5345%10]) with mapi id 14.01.0438.000; Mon, 28 Oct 2013 12:13:13 -0400 From: "Ackermann, Michael" To: Ray Hunter Thread-Topic: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt Thread-Index: AQHO0OGzc1wNgnhly0SIwwwBJHHHZZoEfl4ggAF03YCABFViAA== Date: Mon, 28 Oct 2013 16:13:13 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <52695E3A.9090406@globis.net> <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> <526AAC81.3050402@globis.net> In-Reply-To: <526AAC81.3050402@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-20254.000 x-tm-as-result: No--39.910400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 28 Oct 2013 09:15:49 -0700 Cc: v6ops WG , 6man WG , "ippm@ietf.org" , "bill.jouris@insidethestack.com" Subject: Re: [ippm] [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt 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, 28 Oct 2013 16:13:24 -0000 Hey Ray It appears your experiences with Time Synch and Stratum levels are = different than mine. In the older Telecom and Voice World Stratum was a = great indicator of clocking accuracy. Still is as far as I know. This = was always true with or without NTP in the picture. =20 And whenever we had two Stratum 0's or 1's, be they the same or different = masters, they WOULD be in synch. We never had a situation that was an = exception to that, with or without NTP. =20 Thanks Mike -----Original Message----- From: Ray Hunter =5Bmailto:v6ops=40globis.net=5D=20 Sent: Friday, October 25, 2013 1:38 PM To: Ackermann, Michael Cc: Nalini Elkins; v6ops WG; 6man WG; ippm=40ietf.org; = bill.jouris=40insidethestack.com; keven.haining=40usbank.com Subject: Re: =5Bv6ops=5D Fw: New Version Notification for = draft-elkins-6man-ipv6-pdm-dest-option-04.txt > Ackermann, Michael > 25 October 2013 01:44 > Ray > > Your Comment:=20 > No. I think what I said was that the level of certainty in your = measurements is dependent on the level of synchronisation of the 2 clock = sources if you are calculating a delta of timestamp of clock 1 - timestamp = clock 2. > My Response: > Then it sounds like we are in agreement. Given the appropriate stratum = level at both nodes, the desired level of time synchronization is = achieved.=20 > No. We are not in agreement. Stratum is an indication of how far down you are in the hierarchy from any = NTP Stratum 0 clock. It says nothing about whether your stratum 0 and my stratum 0 are = synchronised. We could both be running caesium clocks, and there could still be an = offset if I don't set my reference time of my caesium clock the same as = your reference time. When talking about microsecond or picosecond timing = that will almost certainly be significant. You really need to know that the true provenance of the clock source is = identical in order to make PDM 1 calculations, not just the stratum. Hence my comment to couple some sort of =22clock ID=22 to the timestamp. > Your Comment:=20 > I think it might be instructive to go back and look at high school = physics books on making measurements, precision, accuracy, and error = estimations, especially when taking the difference of two measurements, or = making other calculations on top of raw observations > My Response: Not sure exactly what this means but I can say that this = sounds like theoretical doubt that time synchronization will not work = properly in geographically dispersed environments? I can tell you that = it does in our experiences and that the surrounding = protocols/implementations are crafted to account for such vicissitudes. =20 > I will say that I have no field experience with DCF-77 sources, only GPS = and Cesium. =20 > > > Your Comment: > Equally a stratum 0 clock can be free running if it loses it's radio = signal. > My Response:=20 > This comment sort of confused me as well, but suffice to say, if any = component is broken, results will be impaired. Obviously this is not = limited to the time synch subject. =20 > > > Finally, your comment about =22Middleboxes=22. I hope it can be as = simple to accommodate as you describe. My concern is that if there are = numerous middleboxes, the fields may get repetitively overlaid, or there = will need to be so many separate fields, we could incur excessive = complexity or overhead. Given that we can accomplish this with a = workable solution, I am certainly all for it. =20 > The more information I can have to manage networks and solve problems, = the better=21 > > Thanks again for your thoughts, inputs and questions=21 > > Mike > > > > > > > > > > > The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From brian@innovationslab.net Mon Oct 28 09:24:19 2013 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 69EA521F9F08; Mon, 28 Oct 2013 09:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJT9wXzC8fBb; Mon, 28 Oct 2013 09:24:13 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id EC8F421F9FE9; Mon, 28 Oct 2013 09:24:12 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 6B2A6880A4; Mon, 28 Oct 2013 09:24:12 -0700 (PDT) Received: from 102527254.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id D1EE3130003; Mon, 28 Oct 2013 09:24:11 -0700 (PDT) Message-ID: <526E8FA3.70506@innovationslab.net> Date: Mon, 28 Oct 2013 12:24:03 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Ackermann, Michael" , Ray Hunter References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <52695E3A.9090406@globis.net> <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> <526AAC81.3050402@globis.net> <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LXMC8R1hVTxIoGgRMCMvKvREBwr3bvGvq" Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [ippm] [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt 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, 28 Oct 2013 16:24:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LXMC8R1hVTxIoGgRMCMvKvREBwr3bvGvq Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael. On 10/28/13 12:13 PM, Ackermann, Michael wrote: > Hey Ray >=20 > It appears your experiences with Time Synch and Stratum levels are > different than mine. In the older Telecom and Voice World Stratum > was a great indicator of clocking accuracy. Still is as far as I > know. This was always true with or without NTP in the picture. And > whenever we had two Stratum 0's or 1's, be they the same or different > masters, they WOULD be in synch. We never had a situation that was > an exception to that, with or without NTP. The NTP definition of stratum is different from that used in the telecommunications domain. The primary feature of a NTP stratum 0 clock is the ability to generate accurate pulse per second signals, hence calling them reference clocks. It should be noted that in NTP, stratum 0 clocks are *not* NTP servers, they are the source of time information to stratum 1 servers that serve time via NTP. Regards, Brian --LXMC8R1hVTxIoGgRMCMvKvREBwr3bvGvq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSbo+oAAoJEBOZRqCi7goqJT8IANGmjK6dYI7nZ/3QdwAVIANj fVHFVQ/XBKDld0ZX37POiLxI8FwfqYYRmEEWeyRRrej2qcHiAyGD+d1YstctL/qw PVIZbBwZSHkZIGp/Sd6PZEm//R3opF8RhV/TFnJL35vEELyfClH0qb70BJaZ9Fxu EBfIoXI4IJB3YS7h+De/lD0VYd4JprdUVj3kbnVOI23UWR7OMUiG4o1nQy0rPkvP ItKZq4BzNUp8fhZovlwOb0GlocyBx1qmXl7Ptiij4SmM0BRBVHNhZ0uoRyyq7C73 PodrP7N68+VVszPfU9Xv5LgVGIE2iTyLQVt5QFdFl6dDfaAEM5N6Q36Cc0IY6f4= =tJLW -----END PGP SIGNATURE----- --LXMC8R1hVTxIoGgRMCMvKvREBwr3bvGvq-- From Joachim.Fabini@tuwien.ac.at Mon Oct 28 09:40:27 2013 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 B040B21E80A8; Mon, 28 Oct 2013 09:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.13 X-Spam-Level: X-Spam-Status: No, score=-5.13 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUV1h2jSDlYM; Mon, 28 Oct 2013 09:40:23 -0700 (PDT) Received: from mail1.zserv.tuwien.ac.at (mail1.zserv.tuwien.ac.at [128.130.35.37]) by ietfa.amsl.com (Postfix) with ESMTP id AFD7421F9E89; Mon, 28 Oct 2013 09:40:22 -0700 (PDT) Received: from [128.131.88.241] (priamos.ibk.tuwien.ac.at [128.131.88.241]) (authenticated bits=0) by mail1.zserv.tuwien.ac.at (8.13.8/8.13.8) with ESMTP id r9SGeFgY012631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Oct 2013 17:40:15 +0100 Message-ID: <526E936D.1000404@tuwien.ac.at> Date: Mon, 28 Oct 2013 17:40:13 +0100 From: Joachim Fabini User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Ackermann, Michael" , Ray Hunter References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <52695E3A.9090406@globis.net> <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> <526AAC81.3050402@globis.net> <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops WG , 6man WG , "bill.jouris@insidethestack.com" , "ippm@ietf.org" Subject: Re: [ippm] [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt 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, 28 Oct 2013 16:40:27 -0000 Mike, Nalini, please have a look at http://tools.ietf.org/html/rfc2330#section-10 and/or http://tools.ietf.org/html/rfc5905 for a detailed technical discussion on time issues/NTP. With respect to these parameters, the term "in sync" which you use is _purely_ theoretical and must be consolidated to a technical specification in terms of RFC2330 clock parameters (accuracy, resolution, etc.) to be usable in practice. I think this is what Ray meant. Stratum per se (in the NTP sense) is imho misleading/useless as a quality indicator. regards Joachim Am 28.10.2013 17:13, schrieb Ackermann, Michael: > Hey Ray > > It appears your experiences with Time Synch and Stratum levels are different than mine. In the older Telecom and Voice World Stratum was a great indicator of clocking accuracy. Still is as far as I know. This was always true with or without NTP in the picture. > And whenever we had two Stratum 0's or 1's, be they the same or different masters, they WOULD be in synch. We never had a situation that was an exception to that, with or without NTP. > > Thanks > > Mike > > > -----Original Message----- > From: Ray Hunter [mailto:v6ops@globis.net] > Sent: Friday, October 25, 2013 1:38 PM > To: Ackermann, Michael > Cc: Nalini Elkins; v6ops WG; 6man WG; ippm@ietf.org; bill.jouris@insidethestack.com; keven.haining@usbank.com > Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt > >> Ackermann, Michael >> 25 October 2013 01:44 >> Ray >> >> Your Comment: >> No. I think what I said was that the level of certainty in your measurements is dependent on the level of synchronisation of the 2 clock sources if you are calculating a delta of timestamp of clock 1 - timestamp clock 2. >> My Response: >> Then it sounds like we are in agreement. Given the appropriate stratum level at both nodes, the desired level of time synchronization is achieved. >> > No. We are not in agreement. > > Stratum is an indication of how far down you are in the hierarchy from any NTP Stratum 0 clock. > > It says nothing about whether your stratum 0 and my stratum 0 are synchronised. > > We could both be running caesium clocks, and there could still be an offset if I don't set my reference time of my caesium clock the same as your reference time. When talking about microsecond or picosecond timing that will almost certainly be significant. > > You really need to know that the true provenance of the clock source is identical in order to make PDM 1 calculations, not just the stratum. > > Hence my comment to couple some sort of "clock ID" to the timestamp. >> Your Comment: >> I think it might be instructive to go back and look at high school physics books on making measurements, precision, accuracy, and error estimations, especially when taking the difference of two measurements, or making other calculations on top of raw observations >> My Response: Not sure exactly what this means but I can say that this sounds like theoretical doubt that time synchronization will not work properly in geographically dispersed environments? I can tell you that it does in our experiences and that the surrounding protocols/implementations are crafted to account for such vicissitudes. >> I will say that I have no field experience with DCF-77 sources, only GPS and Cesium. >> >> >> Your Comment: >> Equally a stratum 0 clock can be free running if it loses it's radio signal. >> My Response: >> This comment sort of confused me as well, but suffice to say, if any component is broken, results will be impaired. Obviously this is not limited to the time synch subject. >> >> >> Finally, your comment about "Middleboxes". I hope it can be as simple to accommodate as you describe. My concern is that if there are numerous middleboxes, the fields may get repetitively overlaid, or there will need to be so many separate fields, we could incur excessive complexity or overhead. Given that we can accomplish this with a workable solution, I am certainly all for it. >> The more information I can have to manage networks and solve problems, the better! >> >> Thanks again for your thoughts, inputs and questions! >> >> Mike >> >> >> >> >> >> >> >> >> >> >> > > > > The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. > > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > From mackermann@bcbsm.com Mon Oct 28 09:49:54 2013 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 407DD21E80B8 for ; Mon, 28 Oct 2013 09:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.028 X-Spam-Level: X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NkdPACgdsxL for ; Mon, 28 Oct 2013 09:49:48 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id D997021E80AA for ; Mon, 28 Oct 2013 09:49:26 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 72BF32FF67B for ; Mon, 28 Oct 2013 11:49:26 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id BAD5230742E; Mon, 28 Oct 2013 11:49:25 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id C733D2F0049; Mon, 28 Oct 2013 12:38:42 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva2.bcbsm.com (Postfix) with ESMTP id BAB912F0043; Mon, 28 Oct 2013 12:38:42 -0400 (EDT) Received: from PWN401EA105.ent.corp.bcbsm.com (10.64.102.241) by PWN401EA100.ent.corp.bcbsm.com (10.64.80.217) with Microsoft SMTP Server (TLS) id 14.1.438.0; Mon, 28 Oct 2013 12:49:24 -0400 Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA105.ent.corp.bcbsm.com ([fe80::f13e:83e4:1dae:5345%10]) with mapi id 14.01.0438.000; Mon, 28 Oct 2013 12:49:23 -0400 From: "Ackermann, Michael" To: Brian Haberman , Ray Hunter Thread-Topic: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt Thread-Index: AQHO0OGzc1wNgnhly0SIwwwBJHHHZZoEfl4ggAF03YCABFViAIAATOiA///D2ZA= Date: Mon, 28 Oct 2013 16:49:21 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0CA8B261@PWN401EA160.ent.corp.bcbsm.com> References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <52695E3A.9090406@globis.net> <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> <526AAC81.3050402@globis.net> <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> <526E8FA3.70506@innovationslab.net> In-Reply-To: <526E8FA3.70506@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-20254.000 x-tm-as-result: No--36.829100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [ippm] [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt 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, 28 Oct 2013 16:49:54 -0000 Thank you Brian. What you say matches my understanding and experiences -----Original Message----- From: Brian Haberman =5Bmailto:brian=40innovationslab.net=5D=20 Sent: Monday, October 28, 2013 12:24 PM To: Ackermann, Michael; Ray Hunter Cc: v6ops WG; 6man WG; ippm=40ietf.org Subject: Re: =5Bv6ops=5D Fw: New Version Notification for = draft-elkins-6man-ipv6-pdm-dest-option-04.txt Hi Michael. On 10/28/13 12:13 PM, Ackermann, Michael wrote: > Hey Ray >=20 > It appears your experiences with Time Synch and Stratum levels are > different than mine. In the older Telecom and Voice World Stratum > was a great indicator of clocking accuracy. Still is as far as I > know. This was always true with or without NTP in the picture. And > whenever we had two Stratum 0's or 1's, be they the same or different > masters, they WOULD be in synch. We never had a situation that was > an exception to that, with or without NTP. The NTP definition of stratum is different from that used in the = telecommunications domain. The primary feature of a NTP stratum 0 clock = is the ability to generate accurate pulse per second signals, hence = calling them reference clocks. It should be noted that in NTP, stratum 0 clocks are *not* NTP servers, they are the source of time information to = stratum 1 servers that serve time via NTP. Regards, Brian The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From joelja@bogus.com Mon Oct 28 10:07:08 2013 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 7E44E21E80BA; Mon, 28 Oct 2013 10:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uORJfg7G7hd; Mon, 28 Oct 2013 10:07:02 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D150111E8286; Mon, 28 Oct 2013 10:06:56 -0700 (PDT) Received: from 00698a-hsutim.corp.zynga.com ([199.48.105.4]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r9SH6oA9084644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Oct 2013 17:06:51 GMT (envelope-from joelja@bogus.com) Content-Type: multipart/signed; boundary="Apple-Mail=_F0041254-84C3-481F-8877-236BC366790F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: joel jaeggli In-Reply-To: <4FC37E442D05A748896589E468752CAA0CA8B261@PWN401EA160.ent.corp.bcbsm.com> Date: Mon, 28 Oct 2013 10:06:44 -0700 Message-Id: <822EAF96-CFCF-4584-B590-08CAFE6AF260@bogus.com> References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <52695E3A.9090406@globis.net> <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> <526AAC81.3050402@globis.net> <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> <526E8FA3.70506@innovationslab.net> <4FC37E442D05A748896589E468752CAA0CA8B261@PWN401EA160.ent.corp.bcbsm.com> To: "Ackermann, Michael" X-Mailer: Apple Mail (2.1816) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 28 Oct 2013 17:06:52 +0000 (UTC) Cc: Ray Hunter , Brian Haberman , 6man WG , v6ops WG , "ippm@ietf.org" Subject: Re: [ippm] [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt 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, 28 Oct 2013 17:07:09 -0000 --Apple-Mail=_F0041254-84C3-481F-8877-236BC366790F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 28, 2013, at 9:49 AM, Ackermann, Michael = wrote: > Thank you Brian. >=20 > What you say matches my understanding and experiences >=20 Then you should revise your statement accordingly=85 >=20 >=20 > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net]=20 > Sent: Monday, October 28, 2013 12:24 PM > To: Ackermann, Michael; Ray Hunter > Cc: v6ops WG; 6man WG; ippm@ietf.org > Subject: Re: [v6ops] Fw: New Version Notification for = draft-elkins-6man-ipv6-pdm-dest-option-04.txt >=20 > Hi Michael. >=20 > On 10/28/13 12:13 PM, Ackermann, Michael wrote: >> Hey Ray >>=20 >> It appears your experiences with Time Synch and Stratum levels are >> different than mine. In the older Telecom and Voice World Stratum >> was a great indicator of clocking accuracy. Still is as far as I >> know. This was always true with or without NTP in the picture. And >> whenever we had two Stratum 0's or 1's, be they the same or different >> masters, they WOULD be in synch. We never had a situation that was >> an exception to that, with or without NTP. >=20 > The NTP definition of stratum is different from that used in the = telecommunications domain. The primary feature of a NTP stratum 0 clock = is the ability to generate accurate pulse per second signals, hence = calling them reference clocks. It should be noted that in NTP, stratum > 0 clocks are *not* NTP servers, they are the source of time = information to stratum 1 servers that serve time via NTP. >=20 > Regards, > Brian >=20 >=20 >=20 > The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you = are hereby notified that any viewing, copying, disclosure or = distribution of this information is prohibited. Please notify the = sender, by electronic mail or telephone, of any unintended receipt and = delete the original message without making any copies. >=20 > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross = and Blue Shield Association. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --Apple-Mail=_F0041254-84C3-481F-8877-236BC366790F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJumaQACgkQ8AA1q7Z/VrKNTwCeKwXEXH3o3mhMn6Nk+j9OFjSy hv8AniJHBe98K8aKQCwTjT/H6QszaUy9 =wjCb -----END PGP SIGNATURE----- --Apple-Mail=_F0041254-84C3-481F-8877-236BC366790F-- From nalini.elkins@insidethestack.com Mon Oct 28 10:18:43 2013 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 915A311E828D for ; Mon, 28 Oct 2013 10:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XPUvXORLLzn for ; Mon, 28 Oct 2013 10:18:38 -0700 (PDT) Received: from nm6-vm6.access.bullet.mail.gq1.yahoo.com (nm6-vm6.access.bullet.mail.gq1.yahoo.com [216.39.63.154]) by ietfa.amsl.com (Postfix) with ESMTP id D5EED11E8282 for ; Mon, 28 Oct 2013 10:18:34 -0700 (PDT) Received: from [216.39.60.172] by nm6.access.bullet.mail.gq1.yahoo.com with NNFMP; 28 Oct 2013 17:18:34 -0000 Received: from [216.39.60.235] by tm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 28 Oct 2013 17:18:34 -0000 Received: from [127.0.0.1] by omp1006.access.mail.gq1.yahoo.com with NNFMP; 28 Oct 2013 17:18:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 447468.39677.bm@omp1006.access.mail.gq1.yahoo.com Received: (qmail 33934 invoked by uid 60001); 28 Oct 2013 17:18:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1382980713; bh=rXSK8sW+3/5tdnyY0Sc8auV9s0yAGCkwsuBtqJmFW/A=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SM4NOdNvVxNHda879K2Amj/aMc01mozea4IvVNWrqYJ06m/lAM+O57tupP91OFQ0Dr3Hb5/2X5KIhq6qvRKfOlxUXV2TWREjtUov2wCnlcFmMycrTCTH/CoFKiA3/dpyYCLXQCjoK1HSDiKd4CDBqAAMCYvLK4gB+EYA/AePKqA= X-YMail-OSG: USF1x1wVM1lqW_gBckIC_LJIXQA4iP2lj3vtUpC5f.TD5Cv WGZYTTSFbmhu_ifAK2fO6IR3gclr8ESV4X05Z5JsRCOyKYswGVAFJprWvEVo PDZaqsftfM9V_Bf.tN8HDOok51CkgqkpX3WuNC5ENZck3VxRpTBiTEeKaN3I d0fxvLK9nR9nJ6SWrBX.SXbSkudpu63hG3nQTVnoP5IxOot5aIsz_TrOPGJ. qdDES5Qkf1F0qE2vw6mQEnsESYo0wtmPqsfmMRsZNaXArY3S4sxTC.dqN6xw CoAL4.8ERCXWflpMQ2Imd3c.agkJQDbrrh0qL31ARHcCXoqOs0DxZybDNJEH NJjZD3FN1wFGKv_fnicu9XfKI2Nab_QV7mN45QRXMKACed0DmXzDK8azfArw y7oUYFs36TYzJbslMFwgvKY7CN_oMEK_L.YfC2.KQS0BvS2fYmOYTYLMpeba 0HFiy9baTLNqcxxpOIeJ8IDksfpYnfR8RqVqIlrbRlJ0ZWdAMQWchs6bjFdj qiLhKZ2R_020HnmmnM5TjE0qVpFprMhG1v9AZYkQl95qdkfKYI2ybgHywSNF 9PApXtRRXTXIjuRJ3sGYYYPN0Mf02RKDPcH3U3_WgvA7bQGZzN5MlNvtQsaF ed5gThAd35Dql2blZvUu0W0slHsMkgUB04G_59f_swTr7iLyeF0ikiv_3ivh lX8iN Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Mon, 28 Oct 2013 10:18:33 PDT X-Rocket-MIMEInfo: 002.001, Sm9hY2hpbSwKwqAKVGhhbmtzIHZlcnkgbXVjaC4gwqBXZSB3aWxsIHRha2UgYSBsb29rIGFuZCByZXZpc2UgdGhlIGRyYWZ0cyBhY2NvcmRpbmdseS4KCk5hbGluaSBFbGtpbnMKSW5zaWRlIFByb2R1Y3RzLCBJbmMuCig4MzEpIDY1OS04MzYwCnd3dy5pbnNpZGV0aGVzdGFjay5jb20KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206IEpvYWNoaW0gRmFiaW5pIDxKb2FjaGltLkZhYmluaUB0dXdpZW4uYWMuYXQ.ClRvOiAiQWNrZXJtYW5uLCBNaWNoYWVsIiA8TUFja2VybWFubkBiY2IBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <52695E3A.9090406@globis.net> <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> <526AAC81.3050402@globis.net> <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> <526E936D.1000404@tuwien.ac.at> Message-ID: <1382980713.24463.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Mon, 28 Oct 2013 10:18:33 -0700 (PDT) From: Nalini Elkins To: Joachim Fabini , "Ackermann, Michael" , Ray Hunter In-Reply-To: <526E936D.1000404@tuwien.ac.at> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-1261008546-1382980713=:24463" Cc: v6ops WG , 6man WG , "bill.jouris@insidethestack.com" , "ippm@ietf.org" Subject: Re: [ippm] [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 17:18:43 -0000 --1619178251-1261008546-1382980713=:24463 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Joachim,=0A=A0=0AThanks very much. =A0We will take a look and revise the dr= afts accordingly.=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-83= 60=0Awww.insidethestack.com=0A=0A=0A=0A________________________________=0A = From: Joachim Fabini =0ATo: "Ackermann, Michae= l" ; Ray Hunter =0ACc: v6ops WG ; 6man WG ; "bill.jouris@insidethestack.com" <= bill.jouris@insidethestack.com>; "ippm@ietf.org" =0ASent: M= onday, October 28, 2013 9:40 AM=0ASubject: Re: [ippm] [v6ops] Fw: New Versi= on Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt=0A =0A=0A= Mike, Nalini,=0A=0Aplease have a look at http://tools.ietf.org/html/rfc2330= #section-10 =0Aand/or http://tools.ietf.org/html/rfc5905 for a detailed tec= hnical =0Adiscussion on time issues/NTP. With respect to these parameters, = the =0Aterm "in sync" which you use is _purely_ theoretical and must be =0A= consolidated to a technical specification in terms of RFC2330 clock =0Apara= meters (accuracy, resolution, etc.) to be usable in practice. I =0Athink th= is is what Ray meant. Stratum per se (in the NTP sense) is imho =0Amisleadi= ng/useless as a quality indicator.=0A=0Aregards=0AJoachim=0A=0A=0AAm 28.10.= 2013 17:13, schrieb Ackermann, Michael:=0A> Hey Ray=0A>=0A> It appears your= experiences with Time Synch and Stratum levels are different than mine.=A0= In the older Telecom and Voice World Stratum was a great indicator of clo= cking accuracy.=A0 Still is as far as I know.=A0 This was always true wit= h or without NTP in the picture.=0A> And whenever we had two Stratum 0's or= 1's, be they the same or different masters, they WOULD be in synch.=A0 We= never had a situation that was an exception to that, with or without NTP.= =0A>=0A> Thanks=0A>=0A> Mike=0A>=0A>=0A> -----Original Message-----=0A> Fro= m: Ray Hunter [mailto:v6ops@globis.net]=0A> Sent: Friday, October 25, 2013 = 1:38 PM=0A> To: Ackermann, Michael=0A> Cc: Nalini Elkins; v6ops WG; 6man WG= ; ippm@ietf.org; bill.jouris@insidethestack.com; keven.haining@usbank.com= =0A> Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6ma= n-ipv6-pdm-dest-option-04.txt=0A>=0A>> Ackermann, Michael =0A>> 25 October 2013 01:44=0A>> Ray=0A>>=0A>> Your Comment:=0A= >> No. I think what I said was that the level of certainty in your measurem= ents is dependent on the level of synchronisation of the 2 clock sources if= you are calculating a delta of timestamp of clock 1 - timestamp clock 2.= =0A>> My Response:=0A>> Then it sounds like we are in agreement.=A0 Given = the appropriate stratum level at both nodes, the desired level of time sync= hronization is achieved.=0A>>=0A> No. We are not in agreement.=0A>=0A> Stra= tum is an indication of how far down you are in the hierarchy from any NTP = Stratum 0 clock.=0A>=0A> It says nothing about whether your stratum 0 and m= y stratum 0 are synchronised.=0A>=0A> We could both be running caesium cloc= ks, and there could still be an offset if I don't set my reference time of = my caesium clock the same as your reference time. When talking about micros= econd or picosecond timing that will almost certainly be significant.=0A>= =0A> You really need to know that the true provenance of the clock source i= s identical in order to make PDM 1 calculations, not just the stratum.=0A>= =0A> Hence my comment to couple some sort of "clock ID" to the timestamp.= =0A>> Your Comment:=0A>> I think it might be instructive to go back and loo= k at high school physics books on making measurements, precision, accuracy,= and error estimations, especially when taking the difference of two measur= ements, or making other calculations on top of raw observations=0A>> My Res= ponse:=A0 Not sure exactly what this means but I can say that this sounds l= ike theoretical doubt that time synchronization will not work properly in g= eographically dispersed environments?=A0 =A0 I can tell you that it does in= our experiences and that the surrounding protocols/implementations are cra= fted to account for such vicissitudes.=0A>> I will say that I have no field= experience with DCF-77 sources, only GPS and Cesium.=0A>>=0A>>=0A>> Your C= omment:=0A>> Equally a stratum 0 clock can be free running if it loses it's= radio signal.=0A>> My Response:=0A>> This comment sort of confused me as w= ell, but suffice to say, if any component is broken, results will be impair= ed.=A0 Obviously this is not limited to the time synch subject.=0A>>=0A>>= =0A>> Finally, your comment about "Middleboxes".=A0 =A0 I hope it can be as= simple to accommodate as you describe.=A0 My concern is that if there are= numerous middleboxes, the fields may get repetitively overlaid, or there w= ill need to be so many separate fields, we could incur excessive complexity= or overhead.=A0 =A0 Given that we can accomplish this with a workable solu= tion, I am certainly all for it.=0A>> The more information I can have to ma= nage networks and solve problems, the better!=0A>>=0A>> Thanks again for yo= ur thoughts, inputs and questions!=0A>>=0A>> Mike=0A>>=0A>>=0A>>=0A>>=0A>>= =0A>>=0A>>=0A>>=0A>>=0A>>=0A>>=0A>=0A>=0A>=0A> The information contained in= this communication is highly confidential and is intended solely for the u= se of the individual(s) to whom this communication is directed. If you are = not the intended recipient, you are hereby notified that any viewing, copyi= ng, disclosure or distribution of this information is prohibited. Please no= tify the sender, by electronic mail or telephone, of any unintended receipt= and delete the original message without making any copies.=0A>=0A>=A0 Blu= e Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonpr= ofit corporations and independent licensees of the Blue Cross and Blue Shie= ld Association.=0A> _______________________________________________=0A> ipp= m mailing list=0A> ippm@ietf.org=0A> https://www.ietf.org/mailman/listinfo/= ippm=0A>=0A_______________________________________________=0Aippm mailing l= ist=0Aippm@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/ippm --1619178251-1261008546-1382980713=:24463 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Joachim,
=
 
Thanks very much.  We will take a loo= k and revise the drafts accordingly.

Nalini Elkins=
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

From: J= oachim Fabini <Joachim.Fabini@tuwien.ac.at>
To: "Ackermann, Michael" <MAckermann@bcbsm.c= om>; Ray Hunter <v6ops@globis.net>
Cc: v6ops WG <v6ops@ietf.org>; 6man WG <ipv6@ietf.org>; "bill.jouris@insidethestack.com" <bill.jouris@in= sidethestack.com>; "ippm@ietf.org" <ippm@ietf.org>
Sent: Monday, October 28, 2013 9:40 = AM
Subject: Re: [ippm]= [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-o= ption-04.txt

=0AMike,= Nalini,

please have a look at http://tools.ietf.org/html/rfc2330#se= ction-10
and/or http://tools.ietf.org/html/rfc5905 for a detailed techn= ical
discussion on time issues/NTP. With respect to these parameters, t= he
term "in sync" which you use is _purely_ theoretical and must be consolidated to a technical specification in terms of RFC2330 clock
pa= rameters (accuracy, resolution, etc.) to be usable in practice. I
think= this is what Ray meant. Stratum per se (in the NTP sense) is imho
misl= eading/useless as a quality indicator.

regards
Joachim

Am 28.10.2013 17:13, schrieb Ackermann, Michael:
> Hey Ray
>> It appears your experiences with Time Synch and Stratum levels are d= ifferent than mine.  In the older Telecom and Voice World Stratum was= a great indicator of clocking accuracy.  Still is as far as I know.&= nbsp; This was always true with or without NTP in the picture.
> And whenever we had two Stratum 0's or 1's, be they the s= ame or different masters, they WOULD be in synch.  We never had a sit= uation that was an exception to that, with or without NTP.
>
> = Thanks
>
> Mike
>
>
> -----Original Message--= ---
> From: Ray Hunter [mailto:v6ops@globis.net]
> Sent: Frida= y, October 25, 2013 1:38 PM
> To: Ackermann, Michael
> Cc: Nali= ni Elkins; v6ops WG; 6man WG; ippm@ietf.org; bill.jouri= s@insidethestack.com; keven.haining@usbank.com
>= Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt
>
>> Ackerman= n, Michael <mailto:MAckermann@bcbsm.com>
>> 25 Octo= ber 2013 01:44
>> Ray
>>
>> Your Comment:
>= ;> No. I think what I said was that the level of certainty in your measu= rements is dependent on the level of synchronisation of the 2 clock sources= if you are calculating a delta of timestamp of clock 1 - timestamp clock 2= .
>> My Response:
>> Then it sounds like we are in agreem= ent.  Given the appropriate stratum level at both nodes, the desired = level of time synchronization is achieved.
>>
> No. We are n= ot in agreement.
>
> Stratum is an indication of how far down y= ou are in the hierarchy from any NTP Stratum 0 clock.
>
> It sa= ys nothing about whether your stratum 0 and my stratum 0 are synchronised.
>
> We could both be running caesium clocks, and= there could still be an offset if I don't set my reference time of my caes= ium clock the same as your reference time. When talking about microsecond o= r picosecond timing that will almost certainly be significant.
>
&= gt; You really need to know that the true provenance of the clock source is= identical in order to make PDM 1 calculations, not just the stratum.
&g= t;
> Hence my comment to couple some sort of "clock ID" to the timest= amp.
>> Your Comment:
>> I think it might be instructive = to go back and look at high school physics books on making measurements, pr= ecision, accuracy, and error estimations, especially when taking the differ= ence of two measurements, or making other calculations on top of raw observ= ations
>> My Response:  Not sure exactly what this means but = I can say that this sounds like theoretical doubt that time synchronization will not work properly in geographically dispersed environ= ments?    I can tell you that it does in our experiences and that= the surrounding protocols/implementations are crafted to account for such = vicissitudes.
>> I will say that I have no field experience with D= CF-77 sources, only GPS and Cesium.
>>
>>
>> You= r Comment:
>> Equally a stratum 0 clock can be free running if it = loses it's radio signal.
>> My Response:
>> This comment = sort of confused me as well, but suffice to say, if any component is broken= , results will be impaired.  Obviously this is not limited to the tim= e synch subject.
>>
>>
>> Finally, your comment = about "Middleboxes".    I hope it can be as simple to accommodate= as you describe.  My concern is that if there are numerous middlebox= es, the fields may get repetitively overlaid, or there will need to be so many separate fields, we could incur excessive complexity or overhea= d.    Given that we can accomplish this with a workable solution,= I am certainly all for it.
>> The more information I can have to = manage networks and solve problems, the better!
>>
>> Tha= nks again for your thoughts, inputs and questions!
>>
>> = Mike
>>
>>
>>
>>
>>
>>= ;
>>
>>
>>
>>
>>
>
&g= t;
>
> The information contained in this communication is highl= y confidential and is intended solely for the use of the individual(s) to w= hom this communication is directed. If you are not the intended recipient, = you are hereby notified that any viewing, copying, disclosure or distributi= on of this information is prohibited. Please notify the sender, by electron= ic mail or telephone, of any unintended receipt and delete the original message without making any copies.
>
>  Blue Cr= oss Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit= corporations and independent licensees of the Blue Cross and Blue Shield A= ssociation.
> _______________________________________________
>= ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/list= info/ippm
>
_______________________________________________ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm<= /a>


--1619178251-1261008546-1382980713=:24463-- From james.cutler@consultant.com Mon Oct 28 09:58:36 2013 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 CB6C321E80DB for ; Mon, 28 Oct 2013 09:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovNynWcabHzo for ; Mon, 28 Oct 2013 09:58:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [74.208.4.201]) by ietfa.amsl.com (Postfix) with ESMTP id D65B221E80E9 for ; Mon, 28 Oct 2013 09:57:41 -0700 (PDT) Received: from [192.168.1.44] ([68.43.142.33]) by mail.gmx.com (mrgmxus001) with ESMTPSA (Nemesis) id 0MfEIW-1VKwus1j2o-00Oqxu for ; Mon, 28 Oct 2013 17:57:41 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_4131A7D2-A07B-4DA4-9414-BD6083408703"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Cutler James R In-Reply-To: <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> Date: Mon, 28 Oct 2013 12:57:36 -0400 Message-Id: <1B14CBF5-5F4D-4B92-B1BB-31E15AD7786D@consultant.com> References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <52695E3A.9090406@globis.net> <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> <526AAC81.3050402@globis.net> <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> To: "Ackermann, Michael" X-Mailer: Apple Mail (2.1816) X-Provags-ID: V03:K0:MlY06JvwwYwaiW8uiX9vttTkDt2RFcz02Vc5xMcnyl9ioBgxPI3 Q/fgsnhWf51ryakgPAmSsXmRzwrnFDM5omx/cqWGbQFdXFCB8tMra4/bcsPqRaIS7ZhxrBz rEuW3uqL2L+JgqI+3vf5Fiqav9iTzGHT3Bqisuq2JeY1AynDIqT3OR8+cEgvBCyMGKCJ4UO 5pJGYpgeOQgQviGoUMZMg== X-Mailman-Approved-At: Tue, 29 Oct 2013 08:11:35 -0700 Cc: Ray Hunter , v6ops WG , 6man WG , "bill.jouris@insidethestack.com" , "ippm@ietf.org" Subject: Re: [ippm] [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt 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, 28 Oct 2013 16:58:36 -0000 --Apple-Mail=_4131A7D2-A07B-4DA4-9414-BD6083408703 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 28, 2013, at 12:13 PM, Ackermann, Michael = wrote: > Hey Ray >=20 > It appears your experiences with Time Synch and Stratum levels are = different than mine. In the older Telecom and Voice World Stratum was = a great indicator of clocking accuracy. Still is as far as I know. = This was always true with or without NTP in the picture. =20 > And whenever we had two Stratum 0's or 1's, be they the same or = different masters, they WOULD be in synch. We never had a situation = that was an exception to that, with or without NTP. =20 >=20 > Thanks >=20 > Mike Before getting too deep into this particular argument, it would be good = to review documents at http://www.eecis.udel.edu/~mills/ntp.html and = ntp.org. =20 When discussion time synchronization using NTP, stratum refers to the = distance from reference clock. Accuracy is separately a function of = reference clock and there are many variants of reference clock. That = two systems are =93in synch=94 is the magic of NTP algorithms and is = orthogonal to accuracy. James R. Cutler james.cutler@consultant.com --Apple-Mail=_4131A7D2-A07B-4DA4-9414-BD6083408703 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJul4AACgkQHzETiNcaVPm/0gCgkKNJcGiI9JB5dp8MKjpgjhk7 Pq0An3M3/w1/+86pdlWThCMUlJkpQCTK =yNzd -----END PGP SIGNATURE----- --Apple-Mail=_4131A7D2-A07B-4DA4-9414-BD6083408703--