From mailman-bounces@ietf.org Sat Jan 1 08:47:04 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20376 for ; Sat, 1 Jan 2005 08:47:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkgUn-0007OE-KF for ippm-archive@lists.ietf.org; Sat, 01 Jan 2005 05:28:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ippm-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sat, 01 Jan 2005 05:12:56 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org ) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org . Thanks! Passwords for ippm-archive@lists.ietf.org: List Password // URL ---- -------- ippm@ietf.org wurudu https://www1.ietf.org/mailman/options/ippm/ippm-archive%40lists.ietf.org From NUSFVLIDCCFYPL@teknikrby.sigma.se Wed Jan 5 16:40:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21812; Wed, 5 Jan 2005 16:40:00 -0500 (EST) Received: from [211.243.68.48] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CmJ5V-0001cA-Sq; Wed, 05 Jan 2005 16:53:07 -0500 Received: from cancelling [192.28.176.242] (helo=minstrel.evacuate.dearriba.com) by smtp2.cistron.nl with esmtp (counterargument 3.35 #1 (pion)) id 960LFL-0042PT-57 Message-ID: <63455143144732.R37423@impassive.noc.seismic.gr> Sender: freeradius-devel-NUSFVLIDCCFYPL@teknikrby.sigma.se X-Mailman-Version: 2.0.1 Date: Wed, 05 Jan 2005 22:36:18 +0100 From: "Porfirio Giles" To: mmusic-admin@ietf.org Subject: Christmas Vicodin sale Chase X-Spam-Score: 6.7 (++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Christmas sale on Vicodin and other drugs. You won`t find better prices anywhere! V icodin - 90 PiIls - 178$ V iagra - 100 PilIs - 209.99$ C ialis - 90 PiIls - 324$ A mbien - 120 PilIs - 249$ X anax - 90 PiIls - 299$ and many more... Please click below and check out our offer. http://proportionate.bestviagras.info/in.php?aid=44 corrosion delinquent atypic yeasty blenheim cylinder glaswegian morris trill stodgy loveland labial veldt crosspoint puffery generic assimilable darling hydrology pilate midst earn dorothy neuroanotomy latitudinary bovine elute brewery sadism rill cationic hearty irredentist swenson earphone downstairs thirst reimburse discomfit alcmena correlate triode embedder propylene pedantic mesenteric precursor leasehold bologna plumbago puccini montague teet hardtack From GTDWVKQ@msn.com Sun Jan 9 12:26:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24978; Sun, 9 Jan 2005 12:26:21 -0500 (EST) Received: from [82.146.197.174] (helo=websud-bloc2-cust174.websud.ch) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cnh30-0008OO-Iw; Sun, 09 Jan 2005 12:40:17 -0500 Received: from [80.208.100.63] (helo=..dearriba.com) by smtp2.cistron.nl with esmtp ( 3.35 #1 ()) id 282LFL-0026PT-82 Message-ID: <52704673144732.R37446@.noc..gr> Sender: freeradius-devel-GTDWVKQ@msn.com X-Mailman-Version: 2.0.1 Date: Sun, 09 Jan 2005 16:24:56 -0100 From: "Donnie Grimm" To: imrg@ietf.org Cc: imrg-web-archive@ietf.org, internet-drafts@ietf.org, ipcdn@ietf.org, iporpr-admin@ietf.org, ipoverib@ietf.org, ipoverib-admin@ietf.org, ippm-archive@ietf.org, ipr-wg@ietf.org Subject: Woww..8o-% 0ff Imrg X-Spam-Score: 5.2 (+++++) X-Spam-Flag: YES X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Wide range of medss available to choose in our stores. Saveee uup to 7o % Viiagraa, Ciallis, Vallium, Xanaax and many moore.. http://www.newholidayplans.com Happy New Year sYp4kbnIIyEolpFU4wotBYuy2fzOSQU0yWxd3dNG7YZs4d From eexvunr@yahoo.com Mon Jan 10 14:38:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15895; Mon, 10 Jan 2005 14:38:23 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co5aX-0005WA-MY; Mon, 10 Jan 2005 14:52:32 -0500 Received: from pool-70-19-101-103.ny325.east.verizon.net ([70.19.101.103]) by mx2.foretec.com with smtp (Exim 4.24) id 1Co5Mk-0005jy-DX; Mon, 10 Jan 2005 14:38:14 -0500 Received: from [216.200.122.29] (helo=..dearriba.com) by smtp2.cistron.nl with esmtp ( 3.35 #1 ()) id 730LFL-0005PT-97 Message-ID: <30902663144732.R37438@.noc..gr> Sender: freeradius-devel-eexvunr@yahoo.com X-Mailman-Version: 2.0.1 Date: Mon, 10 Jan 2005 21:41:00 +0200 From: "Robbie Cole" To: iporpr-admin@ietf.org Cc: ipoverib@ietf.org, ipoverib-admin@ietf.org, ippm-archive@ietf.org, ipr-wg@ietf.org, ipr-wg-admin@ietf.org, iptel@ietf.org, iptel-admin@ietf.org, iptel-request@ietf.org Subject: Look...Here Iporpr-admin X-Spam-Score: 3.5 (+++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Huge offer for Viicodin, Viagraa, Vallium and lots moreee... savee up to 7o% meds on our stores. Visit uss today http://coolhealth.info/in.php?aid=56 Happy New Year HXHZrLLLPGzeJZ5e9e07lP9iHB1nhqLWWiBnIgr9h4Lh0wojV7 From CNBTNLQBFAJ@yahoo.com Tue Jan 11 19:16:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19113; Tue, 11 Jan 2005 19:16:51 -0500 (EST) Received: from ol29-176.fibertel.com.ar ([24.232.176.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoWPm-0005Fl-TC; Tue, 11 Jan 2005 19:31:17 -0500 Received: from 127.0.0.1 (AVG SMTP 7.0.300 [265.6.9]); Fri, 07 Jan 2005 22:05:58 -0300 Received: from [204.42.81.128] (helo=..dearriba.com) by smtp2.cistron.nl with esmtp ( 3.35 #1 ()) id 994LFL-0081PT-99 Message-ID: <27809393144732.R37476@.noc..gr> Sender: freeradius-devel-CNBTNLQBFAJ@yahoo.com X-Mailman-Version: 2.0.1 Date: Fri, 07 Jan 2005 23:02:50 -0200 From: "Josue Sparks" To: ipoverib-admin@ietf.org Subject: We Are the Best Ipoverib-admin Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.1 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Our very besstt price of medss: Pain Relief (from $99) (Viicodin, Hydrocodoone, Valliium) Men's Pillls (from $140) (Viiagra, Leviitra) Weight Losss (from $140) (Phentermiine, Xeniical) You Can't find this 0ffers available anywhere. Visit Us T0day! http://getitnowtoday.com/2/codeine.php?wid=200007 This is 1 -time mailing. N0-re m0val are re'qui-red bXpWQUUZ8ATKqVYxdczqj5vIhWiAjnwoZFgYFqX3ocodw -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005 From ippm-bounces@ietf.org Wed Jan 12 09:46:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17441 for ; Wed, 12 Jan 2005 09:46:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cojdp-0006ie-Gy; Wed, 12 Jan 2005 09:38:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CojWD-0004tT-SA for ippm@megatron.ietf.org; Wed, 12 Jan 2005 09:30:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16546 for ; Wed, 12 Jan 2005 09:30:40 -0500 (EST) Received: from smtp1.netlab.nec.de ([195.37.70.41]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CojkE-00076K-Bp for ippm@ietf.org; Wed, 12 Jan 2005 09:45:11 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp1.netlab.nec.de (Postfix) with ESMTP id E0F2AD73C for ; Wed, 12 Jan 2005 15:35:17 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Jan 2005 15:29:57 +0100 Message-ID: Thread-Topic: Way to store traceroutes Thread-Index: AcT4szMDhH1/LwhER+CFh7Im8SQ3Ag== From: "Saverio Niccolini" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Subject: [ippm] Way to store traceroutes X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Dear IPPM mailing list, here, at NEC Europe Network Laboratories, we have seen that the IPPM charter is requesting someone to contribute with a draft on "Way to store traceroutes". I would be glad to contribute to it together with Dr. Sandra Tartarelli (in CC). After brainstorming we wrote a simple Table of Contents for the draft. We would be glad if you could have a look at this in order to say if this is what the IPPM charter had in mind when speaking of "Way to store traceroutes". The ToC is still at a very initial state; in particular we are still working on the most important part: "Storing traceroute measurements". ToC: -- Introduction -- Motivation (of this draft) -- Definition of Traceroute -- Scope of traceroute -- Protocols (UDP/ICMP) -- Set of parameters (for major implementations: list of configurable parameters / default parameters) -- Known problems with traceroute -- Alternatives to traceroute (e.g. tcptraceroute) -- Report / Results -- Info typically reported by traceroute -- Storing traceroute measurements -- set of configuration parameters -- Results -- src -- dst -- hops -- number of traceroutes instances -- metrics (min, max, etc.) -- Security considerations Any comment is appreciated. Best regards, Saverio Niccolini =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Saverio Niccolini Research Staff Member Network Laboratories, NEC Europe Ltd. Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 90511-18 Fax: +49 (0)6221 90511-55 e-mail: saverio.niccolini@netlab.nec.de =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Jan 12 12:41:54 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01207 for ; Wed, 12 Jan 2005 12:41:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ComSJ-0004on-OQ; Wed, 12 Jan 2005 12:38:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ComOu-00040P-Co for ippm@megatron.ietf.org; Wed, 12 Jan 2005 12:35:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00904 for ; Wed, 12 Jan 2005 12:35:17 -0500 (EST) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Comcx-0002vW-BZ for ippm@ietf.org; Wed, 12 Jan 2005 12:49:52 -0500 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id BE2DB1CDA20; Wed, 12 Jan 2005 12:35:15 -0500 (EST) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10279-02; Wed, 12 Jan 2005 12:35:15 -0500 (EST) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 9D9C51CD6EB; Wed, 12 Jan 2005 12:35:15 -0500 (EST) To: Saverio Niccolini Subject: Re: [ippm] Way to store traceroutes References: From: stanislav shalunov Date: 12 Jan 2005 12:35:20 -0500 In-Reply-To: Message-ID: <86acreblev.fsf@abel.internet2.edu> Lines: 47 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Saverio, I think that, conceptually, the draft should define a standard representation (textual or binary) of a data structure that would hold the results of a traceroute measurement. It would seem to me that the data structure itself should look something like (using a made-up pseudocode): RECORD date and time of start of measurement duration of single running IP address version (4 or 6) source IP address destination IP address u_int8_t protocol version (1 for ICMP, 6 for TCP, 17 for UDP, etc.) u_int16_t source port (unused of not meaningful -- e.g., ICMP) u_int16_t destination port (unused of not meaningful -- e.g., ICMP) u_int8_t maximum TTL ARRAY with indices from 1 to maximum TTL LIST of individual probe results IP address u_int8_t protocol version of response (usually 1, except for last) ICMP message description (Time Exceeded, etc.; special value for NaN) delay (with a special value for infinity) Things to decide before sitting down to write the draft: * Is this the right data structure? * Are there any missing fields? Unnecessary fields? * How would it be represented? (My hunch would be to define either just a textual representation or both textual and binary representations.) One thing I'd argue against would be the use of XML for textual representations without a standard binary representation. That would encourage wasteful practices: XML is expensive to parse. A textual representation that doesn't require parsing without a binary representation would be fine as far as I am concerned. --Stanislav -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at room temperature. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Jan 12 14:44:18 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07947 for ; Wed, 12 Jan 2005 14:44:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CooNS-0006Km-W7; Wed, 12 Jan 2005 14:41:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CooKW-0005ma-DG for ippm@megatron.ietf.org; Wed, 12 Jan 2005 14:38:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07664 for ; Wed, 12 Jan 2005 14:38:55 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CooYY-0005Nv-9P for ippm@ietf.org; Wed, 12 Jan 2005 14:53:29 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 7EE9224B57; Wed, 12 Jan 2005 20:38:21 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 8999C24B51; Wed, 12 Jan 2005 20:38:19 +0100 (CET) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j0CJcH8R020468; Wed, 12 Jan 2005 20:38:19 +0100 Message-Id: <6.2.0.14.2.20050112173604.02b9c3f8@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 12 Jan 2005 17:44:50 +0100 To: "Saverio Niccolini" From: Henk Uijterwaal Subject: Re: [ippm] Way to store traceroutes In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000009 / -5.9 X-RIPE-Signature: 0245602e17deb8e6e57a7e238212d00a X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org IPPM group, >Dear IPPM mailing list, >here, at NEC Europe Network Laboratories, we have seen that the IPPM >charter is requesting someone to contribute with a draft on "Way to >store traceroutes". >I would be glad to contribute to it together with Dr. Sandra Tartarelli >(in CC). Saverio: thanks for the offer. Traceroutes are being used by lots of measurement efforts, either as an independent measurement or to get path information to support other measurement efforts. However, there is no document (AFAIK) describing the tool and the output that we like to store. >ToC: >-- Introduction > -- Motivation (of this draft) > >-- Definition of Traceroute > -- Scope of traceroute > -- Protocols (UDP/ICMP) > -- Set of parameters (for major implementations: list of >configurable parameters / default parameters) > >-- Known problems with traceroute > -- Alternatives to traceroute (e.g. tcptraceroute) > >-- Report / Results > -- Info typically reported by traceroute > >-- Storing traceroute measurements > -- set of configuration parameters > -- Results > -- src > -- dst > -- hops > -- number of traceroutes instances > -- metrics (min, max, etc.) Speaking as myself, I'd add: -- Time that the traceroute was collected -- Method (TCP/ICMP/UDP) and packet size -- Errors: (TR did not finish, errors returned by various implementations. Henk >-- Security considerations > >Any comment is appreciated. > >Best regards, >Saverio Niccolini > >============================================================ >Dr. Saverio Niccolini >Research Staff Member >Network Laboratories, NEC Europe Ltd. >Kurfuerstenanlage 36, D-69115 Heidelberg >Tel. +49 (0)6221 90511-18 >Fax: +49 (0)6221 90511-55 >e-mail: saverio.niccolini@netlab.nec.de >============================================================ > > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www1.ietf.org/mailman/listinfo/ippm ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Jan 12 16:23:06 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17957 for ; Wed, 12 Jan 2005 16:23:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Copaz-0004oJ-HH; Wed, 12 Jan 2005 16:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CopO2-0006GL-UT for ippm@megatron.ietf.org; Wed, 12 Jan 2005 15:46:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12819 for ; Wed, 12 Jan 2005 15:46:37 -0500 (EST) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Copc7-0006rD-Fx for ippm@ietf.org; Wed, 12 Jan 2005 16:01:12 -0500 Received: from h-66-167-207-234.snvacaid.dynamic.covad.net ([66.167.207.234] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CopNz-0003Yu-00 for ippm@ietf.org; Wed, 12 Jan 2005 12:46:35 -0800 Message-ID: <006701c4f8e7$ee707de0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ippm] Way to store traceroutes Date: Wed, 12 Jan 2005 12:47:29 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hi - > From: "Saverio Niccolini" > To: > Sent: Wednesday, January 12, 2005 6:29 AM > Subject: [ippm] Way to store traceroutes ... > The ToC is still at a very initial state; in particular we are still > working on the most important part: "Storing traceroute measurements". ... > Any comment is appreciated. ... You might take a look at RFC 2925 (http://www.ietf.org/rfc/rfc2925.txt) (http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-06.txt will soon replace it) to see how the disman WG addressed the problem of storing traceroute measurements. Comments on the RFC or the update would be welcome on the disman WG mailing list. Randy Presuhn disman WG chair _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Jan 13 08:04:41 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05479 for ; Thu, 13 Jan 2005 08:04:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp4SB-00040T-Jv; Thu, 13 Jan 2005 07:51:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp4NQ-0003Js-Ir for ippm@megatron.ietf.org; Thu, 13 Jan 2005 07:47:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04156 for ; Thu, 13 Jan 2005 07:46:59 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp4bb-0002PR-W4 for ippm@ietf.org; Thu, 13 Jan 2005 08:01:43 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 9201322894; Thu, 13 Jan 2005 13:32:06 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] Way to store traceroutes X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 13 Jan 2005 13:45:38 +0100 Message-ID: Thread-Topic: [ippm] Way to store traceroutes Thread-Index: AcT4zb2TLLCiAkXiTsSFKCPjMIAwTQAnkcmA From: "Saverio Niccolini" To: "stanislav shalunov" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Dear all, thanks a lot for your comments. > -----Original Message----- > From: stanislav shalunov [mailto:shalunov@internet2.edu] > Sent: 12 January 2005 18:35 > To: Saverio Niccolini > Cc: ippm@ietf.org > Subject: Re: [ippm] Way to store traceroutes >=20 > Saverio, >=20 > I think that, conceptually, the draft should define a standard > representation (textual or binary) of a data structure that would hold > the results of a traceroute measurement. It would seem to me that the > data structure itself should look something like (using a made-up > pseudocode): >=20 > RECORD > date and time of start of measurement > duration of single running > IP address version (4 or 6) > source IP address > destination IP address > u_int8_t protocol version (1 for ICMP, 6 for TCP, 17 for UDP, etc.) > u_int16_t source port (unused of not meaningful -- e.g., ICMP) > u_int16_t destination port (unused of not meaningful -- e.g., ICMP) > u_int8_t maximum TTL > ARRAY with indices from 1 to maximum TTL > LIST of individual probe results > IP address > u_int8_t protocol version of response (usually 1, except for last) > ICMP message description (Time Exceeded, etc.; special value for > NaN) > delay (with a special value for infinity) >=20 > Things to decide before sitting down to write the draft: >=20 > * Is this the right data structure? >=20 > * Are there any missing fields? Unnecessary fields? We agree, we are currently working on this and we will include your suggestions and the ones sent by Henk. =09 >=20 > * How would it be represented? (My hunch would be to define either > just a textual representation or both textual and binary > representations.) >=20 > One thing I'd argue against would be the use of XML for textual > representations without a standard binary representation. That would > encourage wasteful practices: XML is expensive to parse. A textual > representation that doesn't require parsing without a binary > representation would be fine as far as I am concerned. In our opinion the first thing to do is to define an information model that can be later mapped to one or more data model (be it XML or simpler text, or binary, or a combination of the two). We will first of all define the information model and in the meantime we can try to discuss on the list what the preferred data model is. Best regards, Saverio Niccolini _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Jan 13 08:11:15 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06294 for ; Thu, 13 Jan 2005 08:11:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp4bc-0006wX-JT; Thu, 13 Jan 2005 08:01:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp4OO-0003bv-Eb for ippm@megatron.ietf.org; Thu, 13 Jan 2005 07:48:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04235 for ; Thu, 13 Jan 2005 07:47:58 -0500 (EST) Received: from smtp1.netlab.nec.de ([195.37.70.41]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp4cb-0002Ry-Nm for ippm@ietf.org; Thu, 13 Jan 2005 08:02:43 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp1.netlab.nec.de (Postfix) with ESMTP id D3A9FD73E; Thu, 13 Jan 2005 13:52:51 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] Way to store traceroutes X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 13 Jan 2005 13:47:23 +0100 Message-ID: Thread-Topic: [ippm] Way to store traceroutes Thread-Index: AcT47PmIoasRNaoiR9+kMdZbbeR0ywAgDeMA From: "Saverio Niccolini" To: "Randy Presuhn" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Dear Randy, all, =09 thanks for your suggestion, actually we have already had a look at the disman draft (Juergen Quittek, the current author of the draft is working next door to us) and we will take it as a starting point for our work. Best regards, Saverio Niccolini > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Randy Presuhn > Sent: 12 January 2005 21:47 > To: ippm@ietf.org > Subject: Re: [ippm] Way to store traceroutes >=20 > Hi - >=20 > > From: "Saverio Niccolini" > > To: > > Sent: Wednesday, January 12, 2005 6:29 AM > > Subject: [ippm] Way to store traceroutes >=20 >=20 > ... > > The ToC is still at a very initial state; in particular we are still > > working on the most important part: "Storing traceroute measurements". > ... > > Any comment is appreciated. > ... >=20 > You might take a look at RFC 2925 (http://www.ietf.org/rfc/rfc2925.txt) > (http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2- > 06.txt > will soon replace it) to see how the disman WG addressed the > problem of storing traceroute measurements. Comments on the RFC or > the update would be welcome on the disman WG mailing list. >=20 > Randy Presuhn > disman WG chair >=20 >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Jan 13 09:47:54 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15280 for ; Thu, 13 Jan 2005 09:47:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp67Y-0004Yf-IU; Thu, 13 Jan 2005 09:38:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp5ts-00074E-4D for ippm@megatron.ietf.org; Thu, 13 Jan 2005 09:24:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13498 for ; Thu, 13 Jan 2005 09:24:33 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp685-0005KR-0l for ippm@ietf.org; Thu, 13 Jan 2005 09:39:19 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id DABEE25064; Thu, 13 Jan 2005 15:24:02 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id D50392455A; Thu, 13 Jan 2005 15:24:01 +0100 (CET) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j0DEO18R001442; Thu, 13 Jan 2005 15:24:01 +0100 Message-Id: <6.2.0.14.2.20050113151913.02c11ca8@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 13 Jan 2005 15:23:36 +0100 To: stanislav shalunov , Saverio Niccolini From: Henk Uijterwaal Subject: Re: [ippm] Way to store traceroutes In-Reply-To: <86acreblev.fsf@abel.internet2.edu> References: <86acreblev.fsf@abel.internet2.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000085 / -5.9 X-RIPE-Signature: 4ab9401118f18c4b677c1615468c3123 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 18:35 12/01/2005, stanislav shalunov wrote: >RECORD > date and time of start of measurement > duration of single running I assume that you mean the time it took to take the traceroute? > IP address version (4 or 6) > source IP address > destination IP address > u_int8_t protocol version (1 for ICMP, 6 for TCP, 17 for UDP, etc.) > u_int16_t source port (unused of not meaningful -- e.g., ICMP) > u_int16_t destination port (unused of not meaningful -- e.g., ICMP) > u_int8_t maximum TTL > ARRAY with indices from 1 to maximum TTL > LIST of individual probe results > IP address We should specify the value if a hop does not return a valid address. > u_int8_t protocol version of response (usually 1, except for last) > ICMP message description (Time Exceeded, etc.; special value for NaN) > delay (with a special value for infinity) Does anybody use the delay? Do we want to store the hostname and/or AS number for the host? Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Jan 13 12:21:05 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28107 for ; Thu, 13 Jan 2005 12:21:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp8Ki-000475-TF; Thu, 13 Jan 2005 12:00:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp86s-0007gv-F4 for ippm@megatron.ietf.org; Thu, 13 Jan 2005 11:46:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24443 for ; Thu, 13 Jan 2005 11:46:07 -0500 (EST) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp8L6-0008T9-Re for ippm@ietf.org; Thu, 13 Jan 2005 12:00:55 -0500 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 158981CDA57; Thu, 13 Jan 2005 11:46:07 -0500 (EST) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28716-08; Thu, 13 Jan 2005 11:46:06 -0500 (EST) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id BB2F01CDA4E; Thu, 13 Jan 2005 11:46:06 -0500 (EST) To: Henk Uijterwaal Subject: Re: [ippm] Way to store traceroutes References: <86acreblev.fsf@abel.internet2.edu> <6.2.0.14.2.20050113151913.02c11ca8@localhost> From: stanislav shalunov Date: 13 Jan 2005 11:46:05 -0500 In-Reply-To: <6.2.0.14.2.20050113151913.02c11ca8@localhost> Message-ID: <861xcp5lbm.fsf@abel.internet2.edu> Lines: 39 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Saverio Niccolini , ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Henk Uijterwaal writes: > > duration of single running > > I assume that you mean the time it took to take the traceroute? Yes. > > IP address > > We should specify the value if a hop does not return a valid address. Right. Special values are needed for IP address and delay here. > > delay (with a special value for infinity) > > Does anybody use the delay? It might get useful some day as a measure of network delay, and for now it's useful for estimating router load. And very roughly, it usually lets you tell if something is in the other hemisphere or in the basement. > Do we want to store the hostname and/or AS number for the host? We already have the source IP address, if you mean that. Do you already want hostname? Like a DNS name or just an opaque label? (If the latter, we might just say it's an opaque label.) I'm not sure why source AS should be in traceroutes. Could you say how you think it'd be used (and where it would come from in the first place)? --Stanislav -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed in boustrophedon. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Jan 13 13:23:39 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00925 for ; Thu, 13 Jan 2005 13:23:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp9Zv-0005ff-Qk; Thu, 13 Jan 2005 13:20:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp9Vq-0004c7-71 for ippm@megatron.ietf.org; Thu, 13 Jan 2005 13:16:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29822 for ; Thu, 13 Jan 2005 13:15:58 -0500 (EST) Received: from fw.si-intl.com ([65.195.121.66] helo=va03ex01.si.siroot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp9k4-0001zF-94 for ippm@ietf.org; Thu, 13 Jan 2005 13:30:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] Way to store traceroutes Date: Thu, 13 Jan 2005 12:56:36 -0500 Message-ID: <53325189A027E54A8ED72051B276D8BD024609FE@va03ex01.si.siroot.com> Thread-Topic: [ippm] Way to store traceroutes Thread-Index: AcT4szMDhH1/LwhER+CFh7Im8SQ3AgA5dzqg From: "Dunn, Jeffrey" To: "Saverio Niccolini" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Saverio, It might also be useful to add a text field for operator comments, such as machine and OS type, operator name, etc. Best Regards, =20 Jeffrey Dunn System Test Manager -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Saverio Niccolini Sent: Wednesday, January 12, 2005 9:30 AM To: ippm@ietf.org Subject: [ippm] Way to store traceroutes Dear IPPM mailing list, here, at NEC Europe Network Laboratories, we have seen that the IPPM charter is requesting someone to contribute with a draft on "Way to store traceroutes". I would be glad to contribute to it together with Dr. Sandra Tartarelli (in CC). After brainstorming we wrote a simple Table of Contents for the draft. We would be glad if you could have a look at this in order to say if this is what the IPPM charter had in mind when speaking of "Way to store traceroutes". The ToC is still at a very initial state; in particular we are still working on the most important part: "Storing traceroute measurements". ToC: -- Introduction -- Motivation (of this draft) -- Definition of Traceroute -- Scope of traceroute -- Protocols (UDP/ICMP) -- Set of parameters (for major implementations: list of configurable parameters / default parameters) -- Known problems with traceroute -- Alternatives to traceroute (e.g. tcptraceroute) -- Report / Results -- Info typically reported by traceroute -- Storing traceroute measurements -- set of configuration parameters -- Results -- src -- dst -- hops -- number of traceroutes instances -- metrics (min, max, etc.) -- Security considerations Any comment is appreciated. Best regards, Saverio Niccolini =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Saverio Niccolini Research Staff Member Network Laboratories, NEC Europe Ltd. Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 90511-18 Fax: +49 (0)6221 90511-55 e-mail: saverio.niccolini@netlab.nec.de =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ ippm mailing list ippm@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Jan 13 15:57:06 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15224 for ; Thu, 13 Jan 2005 15:57:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpBwN-0006nN-6W; Thu, 13 Jan 2005 15:51:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpBlC-00008A-NJ for ippm@megatron.ietf.org; Thu, 13 Jan 2005 15:40:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13488 for ; Thu, 13 Jan 2005 15:40:00 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpBzU-0005Yq-3z for ippm@ietf.org; Thu, 13 Jan 2005 15:54:49 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 622D42428B; Thu, 13 Jan 2005 21:39:30 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 7C4D624930; Thu, 13 Jan 2005 21:39:28 +0100 (CET) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j0DKdRZt024285; Thu, 13 Jan 2005 21:39:28 +0100 Message-Id: <6.2.0.14.2.20050113212738.02bcd400@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 13 Jan 2005 21:39:24 +0100 To: stanislav shalunov From: Henk Uijterwaal Subject: Re: [ippm] Way to store traceroutes In-Reply-To: <861xcp5lbm.fsf@abel.internet2.edu> References: <86acreblev.fsf@abel.internet2.edu> <6.2.0.14.2.20050113151913.02c11ca8@localhost> <861xcp5lbm.fsf@abel.internet2.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.015197 / -5.9 X-RIPE-Signature: d0a7acd91b19a389a22df7b790781fa5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Saverio Niccolini , ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 17:46 13/01/2005, stanislav shalunov wrote: > > Do we want to store the hostname and/or AS number for the host? > >We already have the source IP address, if you mean that. Do you >already want hostname? Like a DNS name or just an opaque label? (If >the latter, we might just say it's an opaque label.) > >I'm not sure why source AS should be in traceroutes. Could you say >how you think it'd be used (and where it would come from in the first >place)? To facilitate analysis of the data. AS# are very helpful to see which parts of a path are inside a single provider, and which parts are between providers. Data can be pulled from routing registries, BGP tables and possibly other sources. DNS names and some human intelligence can be used to see where a router is physically located. This is by no means perfect, though in PAM2002, we published a paper explaining delays by looking at names and guessing the location of the routers. This worked quite well. Just storing the IP address doesn't quite work, as address blocks are sometimes returned to the RIR's and recycled, and LIR's move blocks across their networks. I'm not saying that these fields should be filled, just that we should reserve space to store the data. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Jan 13 17:08:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28047 for ; Thu, 13 Jan 2005 17:08:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpCnJ-0002N9-J1; Thu, 13 Jan 2005 16:46:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpC3N-0002dQ-NE for ippm@megatron.ietf.org; Thu, 13 Jan 2005 15:58:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15380 for ; Thu, 13 Jan 2005 15:58:47 -0500 (EST) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpCHf-00069O-Ed for ippm@ietf.org; Thu, 13 Jan 2005 16:13:36 -0500 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 1680E1CDA95; Thu, 13 Jan 2005 15:58:47 -0500 (EST) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18501-09; Thu, 13 Jan 2005 15:58:46 -0500 (EST) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id E7C201CDAB7; Thu, 13 Jan 2005 15:58:46 -0500 (EST) To: Henk Uijterwaal Subject: Re: [ippm] Way to store traceroutes References: <86acreblev.fsf@abel.internet2.edu> <6.2.0.14.2.20050113151913.02c11ca8@localhost> <861xcp5lbm.fsf@abel.internet2.edu> <6.2.0.14.2.20050113212738.02bcd400@localhost> From: stanislav shalunov Date: 13 Jan 2005 15:58:52 -0500 In-Reply-To: <6.2.0.14.2.20050113212738.02bcd400@localhost> Message-ID: <864qhl2ghf.fsf@abel.internet2.edu> Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Saverio Niccolini , ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Oh, I misunderstood. I thought you were suggesting hostname and AS for the source of the traceroute rather than the intermediate points. Yes, for intermediate points, I agree completely: there should be space to keep ASN and hostname. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ But we must show them that they cannot terrorize the greatest nation on the face of the Earth. And we won't. -- George W. Bush, 20011017 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Jan 14 01:02:29 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00445 for ; Fri, 14 Jan 2005 01:02:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpKOI-0000HX-UR; Fri, 14 Jan 2005 00:52:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpKLw-0007ly-Nc for ippm@megatron.ietf.org; Fri, 14 Jan 2005 00:50:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29465 for ; Fri, 14 Jan 2005 00:50:29 -0500 (EST) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpKaG-0002lX-UR for ippm@ietf.org; Fri, 14 Jan 2005 01:05:24 -0500 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 1AF6A1CD9ED; Fri, 14 Jan 2005 00:50:28 -0500 (EST) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31257-07; Fri, 14 Jan 2005 00:50:28 -0500 (EST) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id D623B1CD6D6; Fri, 14 Jan 2005 00:50:27 -0500 (EST) To: "Saverio Niccolini" Subject: Re: [ippm] Way to store traceroutes References: From: stanislav shalunov Date: 14 Jan 2005 00:50:26 -0500 In-Reply-To: Message-ID: <86oefswod9.fsf@abel.internet2.edu> Lines: 14 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org "Saverio Niccolini" writes: > In our opinion the first thing to do is to define an information model > that can be later mapped to one or more data model (be it XML or simpler > text, or binary, or a combination of the two). > We will first of all define the information model and in the meantime we > can try to discuss on the list what the preferred data model is. Seems like a sound strategy to me. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "Nuclear war would really set back cable [television]." -- Ted Turner _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Jan 14 11:14:35 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24767 for ; Fri, 14 Jan 2005 11:14:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpU0H-0006U2-Oo; Fri, 14 Jan 2005 11:08:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpTuo-0005Po-FQ for ippm@megatron.ietf.org; Fri, 14 Jan 2005 11:03:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24250 for ; Fri, 14 Jan 2005 11:03:08 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpU9F-00061R-Va for ippm@ietf.org; Fri, 14 Jan 2005 11:18:07 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 699152126F for ; Fri, 14 Jan 2005 16:48:36 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] Way to store traceroutes Date: Fri, 14 Jan 2005 16:59:13 +0100 Message-ID: Thread-Topic: [ippm] Way to store traceroutes Thread-Index: AcT5/PTG8Lws3wo9Rl+IGpMe1rqyCAAUtICQ From: "Saverio Niccolini" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: Juergen Quittek X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Dear all, thanks a lot for your useful suggestions. We have tried to draft a "traceroute object" based on what we discussed on the list and what we had in mind. We think this will serve as a starting point of our information model. We have taken the disman draft as a starting point and we have erased some fields not useful in the scope of our draft (that we do not specify here), moreover we have added and changed other ones: NEW fields: 1) traceRouteResultsLastGoodPathDuration (duration of single running of the last good traceroute path determination) 2) traceRouteResultsLastRun (when the last traceroute with these characteristics was launched) 3) traceRouteHopsASNumber (AS number of the hop) CHANGED fields: 1) traceRouteProbeHistoryTime (timestamp of when the traceroute probe came back) was changed to traceRouteProbeHistorySentTime (timestamp of when the traceroute probe was sent) Please find here how the "traceroute object" looks like right now: --traceRouteObjects | +--traceRouteCtlTable | | | +--traceRouteCtlEntry | | | +--traceRouteCtlOwnerIndex | +--traceRouteCtlTestName | +--traceRouteCtlTargetAddressType | +--traceRouteCtlTargetAddress | +--traceRouteCtlByPassRouteTable | +--traceRouteCtlDataSize | +--traceRouteCtlTimeOut | +--traceRouteCtlProbesPerHop | +--traceRouteCtlPort | +--traceRouteCtlMaxTtl | +--traceRouteCtlDSField | +--traceRouteCtlSourceAddressType | +--traceRouteCtlSourceAddress | +--traceRouteCtlIfIndex | +--traceRouteCtlMiscOptions | +--traceRouteCtlMaxFailures | +--traceRouteCtlDontFragment | +--traceRouteCtlInitialTtl | +--traceRouteCtlDescr | +--traceRouteCtlMaxRows | +--traceRouteCtlCreateHopsEntries | +--traceRouteCtlType | +--traceRouteResultsTable | | | +--traceRouteResultsEntry | | | +--traceRouteResultsOperStatus | +--traceRouteResultsIpTgtAddrType | +--traceRouteResultsIpTgtAddr | +--traceRouteResultsTestAttempts | +--traceRouteResultsTestSuccesses | +--traceRouteResultsLastGoodPath | +--traceRouteResultsLastGoodPathDuration | +--traceRouteResultsLastRun | +--traceRouteProbeHistoryTable | | | +--traceRouteProbeHistoryEntry | | | +--traceRouteProbeHistoryIndex | +--traceRouteProbeHistoryHopIndex | +--traceRouteProbeHistoryProbeIndex | +--traceRouteProbeHistoryHAddrType | +--traceRouteProbeHistoryHAddr | +--traceRouteProbeHistoryResponse | +--traceRouteProbeHistoryStatus | +--traceRouteProbeHistorySentTime | +--traceRouteHopsTable | +--traceRouteHopsEntry | +--traceRouteHopsHopIndex +--traceRouteHopsIpTgtAddressType +--traceRouteHopsIpTgtAddress +--traceRouteHopsASNumber +--traceRouteHopsMinRtt +--traceRouteHopsMaxRtt +--traceRouteHopsAverageRtt +--traceRouteHopsRttSumOfSquares +--traceRouteHopsSentProbes +--traceRouteHopsProbeResponses We believe that most of the fields are self-explaining, for the unclear ones please refer to the disman draft: http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-06.t xt Looking forward to receive your comments. Best regards, Saverio Niccolini =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Saverio Niccolini Research Staff Member Network Laboratories, NEC Europe Ltd. Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 90511-18 Fax: +49 (0)6221 90511-55 e-mail: saverio.niccolini@netlab.nec.de =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Jan 14 11:28:24 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25634 for ; Fri, 14 Jan 2005 11:28:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpUDr-0002Pi-TE; Fri, 14 Jan 2005 11:22:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpU9Z-0000us-Ed for ippm@megatron.ietf.org; Fri, 14 Jan 2005 11:18:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25044 for ; Fri, 14 Jan 2005 11:18:22 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpUNy-0006I5-RU for ippm@ietf.org; Fri, 14 Jan 2005 11:33:22 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 7E16524861; Fri, 14 Jan 2005 17:17:48 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 40963247F9; Fri, 14 Jan 2005 17:17:47 +0100 (CET) Received: from ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j0EGHCZs016356; Fri, 14 Jan 2005 17:17:47 +0100 Received: (nullmailer pid 7888 invoked by uid 1001); Fri, 14 Jan 2005 16:16:35 -0000 Date: Fri, 14 Jan 2005 17:16:35 +0100 From: Mark Santcroos To: Saverio Niccolini Subject: Re: [ippm] Way to store traceroutes Message-ID: <20050114161635.GJ725@laptop.6bone.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Handles: MS6-6BONE, MS18417-RIPE X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.004382 / -5.9 X-RIPE-Signature: 68aac4a7a528e51d662fe7b1222e7f4f X-Spam-Score: 2.2 (++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Juergen Quittek , ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org How about (reserving) a field for geo/location info about each hop? Mark -- RIPE NCC - Delft University of Technology - The FreeBSD Project marks@ripe.net - m.a.santcroos@ewi.tudelft.nl - marks@freebsd.org _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Jan 14 11:57:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28249 for ; Fri, 14 Jan 2005 11:57:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpUcD-0000c6-P7; Fri, 14 Jan 2005 11:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpUZF-0007mZ-JH for ippm@megatron.ietf.org; Fri, 14 Jan 2005 11:44:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26921 for ; Fri, 14 Jan 2005 11:44:55 -0500 (EST) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpUnh-0006vP-Il for ippm@ietf.org; Fri, 14 Jan 2005 11:59:54 -0500 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id E3E041CD65A; Fri, 14 Jan 2005 11:44:54 -0500 (EST) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21173-02; Fri, 14 Jan 2005 11:44:54 -0500 (EST) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id C59221CD560; Fri, 14 Jan 2005 11:44:54 -0500 (EST) To: "Saverio Niccolini" Subject: Re: [ippm] Way to store traceroutes References: From: stanislav shalunov Date: 14 Jan 2005 11:44:54 -0500 In-Reply-To: Message-ID: <86hdlkufi1.fsf@abel.internet2.edu> Lines: 25 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Juergen Quittek , ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Saverio, Your object summarizes the data on each hop rather than presenting the raw list. This has the following problems: * Space for only one IP number is provided. What if different queries with the same TTL elicit replies from different IPs? * The statistics (such as average RTT, max RTT, and sum of squares of RTTs) are not robust. This is not in line with the treatment of delay in other IPPM documents, where percentiles are used. I believe that in the case of traceroute -- where the amount of data is small for each hop -- there's no reason to not store the individual delay, etc., values. I'd argue for a list of probes for each hop instead of a summary of the given TTL. --Stanislav -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "Computer Science is no more about computers than astronomy is about telescopes." -- E. W. Dijkstra _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Jan 14 14:45:03 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08745 for ; Fri, 14 Jan 2005 14:45:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpXBK-000421-92; Fri, 14 Jan 2005 14:32:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpX50-0002ij-8t; Fri, 14 Jan 2005 14:25:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07248; Fri, 14 Jan 2005 14:25:53 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpXJS-0001sU-FQ; Fri, 14 Jan 2005 14:40:53 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 14 Jan 2005 12:31:57 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0EJPEvl014441; Fri, 14 Jan 2005 11:25:15 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn1-595.cisco.com [10.21.98.83]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BCT25669; Fri, 14 Jan 2005 11:25:16 -0800 (PST) Message-Id: <4.3.2.7.2.20050114111849.02cacbe0@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jan 2005 11:25:16 -0800 To: "Saverio Niccolini" From: Andy Bierman Subject: RE: [ippm] Way to store traceroutes In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: Juergen Quittek , disman@ietf.org, ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 07:59 AM 1/14/2005, Saverio Niccolini wrote: >Dear all, >thanks a lot for your useful suggestions. This work is already established in the DISMAN WG. See RFC 2925, or its update (in progress): http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-06.txt I strongly urge you to work with the DISMAN WG to resolve perceived deficiencies with the RemOps MIB, rather than create a spin-off MIB. Andy >We have tried to draft a "traceroute object" based on what we discussed >on the list and what we had in mind. We think this will serve as a >starting point of our information model. > >We have taken the disman draft as a starting point and we have erased >some fields not useful in the scope of our draft (that we do not specify >here), moreover we have added and changed other ones: > >NEW fields: >1) traceRouteResultsLastGoodPathDuration (duration of single running of >the last good traceroute path determination) >2) traceRouteResultsLastRun (when the last traceroute with these >characteristics was launched) >3) traceRouteHopsASNumber (AS number of the hop) > >CHANGED fields: >1) traceRouteProbeHistoryTime (timestamp of when the traceroute probe >came back) was changed to traceRouteProbeHistorySentTime (timestamp of >when the traceroute probe was sent) > > >Please find here how the "traceroute object" looks like right now: > >--traceRouteObjects > | > +--traceRouteCtlTable > | | > | +--traceRouteCtlEntry > | | > | +--traceRouteCtlOwnerIndex > | +--traceRouteCtlTestName > | +--traceRouteCtlTargetAddressType > | +--traceRouteCtlTargetAddress > | +--traceRouteCtlByPassRouteTable > | +--traceRouteCtlDataSize > | +--traceRouteCtlTimeOut > | +--traceRouteCtlProbesPerHop > | +--traceRouteCtlPort > | +--traceRouteCtlMaxTtl > | +--traceRouteCtlDSField > | +--traceRouteCtlSourceAddressType > | +--traceRouteCtlSourceAddress > | +--traceRouteCtlIfIndex > | +--traceRouteCtlMiscOptions > | +--traceRouteCtlMaxFailures > | +--traceRouteCtlDontFragment > | +--traceRouteCtlInitialTtl > | +--traceRouteCtlDescr > | +--traceRouteCtlMaxRows > | +--traceRouteCtlCreateHopsEntries > | +--traceRouteCtlType > | > +--traceRouteResultsTable > | | > | +--traceRouteResultsEntry > | | > | +--traceRouteResultsOperStatus > | +--traceRouteResultsIpTgtAddrType > | +--traceRouteResultsIpTgtAddr > | +--traceRouteResultsTestAttempts > | +--traceRouteResultsTestSuccesses > | +--traceRouteResultsLastGoodPath > | +--traceRouteResultsLastGoodPathDuration > | +--traceRouteResultsLastRun > | > +--traceRouteProbeHistoryTable > | | > | +--traceRouteProbeHistoryEntry > | | > | +--traceRouteProbeHistoryIndex > | +--traceRouteProbeHistoryHopIndex > | +--traceRouteProbeHistoryProbeIndex > | +--traceRouteProbeHistoryHAddrType > | +--traceRouteProbeHistoryHAddr > | +--traceRouteProbeHistoryResponse > | +--traceRouteProbeHistoryStatus > | +--traceRouteProbeHistorySentTime > | > +--traceRouteHopsTable > | > +--traceRouteHopsEntry > | > +--traceRouteHopsHopIndex > +--traceRouteHopsIpTgtAddressType > +--traceRouteHopsIpTgtAddress > +--traceRouteHopsASNumber > +--traceRouteHopsMinRtt > +--traceRouteHopsMaxRtt > +--traceRouteHopsAverageRtt > +--traceRouteHopsRttSumOfSquares > +--traceRouteHopsSentProbes > +--traceRouteHopsProbeResponses > >We believe that most of the fields are self-explaining, for the unclear >ones please refer to the disman draft: >http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-06.t >xt > >Looking forward to receive your comments. > >Best regards, >Saverio Niccolini > >============================================================ >Dr. Saverio Niccolini >Research Staff Member >Network Laboratories, NEC Europe Ltd. >Kurfuerstenanlage 36, D-69115 Heidelberg >Tel. +49 (0)6221 90511-18 >Fax: +49 (0)6221 90511-55 >e-mail: saverio.niccolini@netlab.nec.de >============================================================ > > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Jan 14 14:54:47 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09353 for ; Fri, 14 Jan 2005 14:54:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpXRu-0000HX-NH; Fri, 14 Jan 2005 14:49:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpXNI-00076F-Ga; Fri, 14 Jan 2005 14:44:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08718; Fri, 14 Jan 2005 14:44:46 -0500 (EST) Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpXbl-0002Gi-Sl; Fri, 14 Jan 2005 14:59:47 -0500 Received: from mgate1.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id LAA07381; Fri, 14 Jan 2005 11:44:12 -0800 (PST) Received: (from daemon@localhost) by mgate1.riverstonenet.com (8.13.1/8.13.1) id j0EJiBSl027242; Fri, 14 Jan 2005 11:44:11 -0800 (PST) X-Authentication-Warning: mgate1.riverstonenet.com: Processed by daemon with -C /etc/mail/sendmail-simple.cf Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mgate1.riverstonenet.com (8.13.1/8.13.1) with ESMTP id j0EJi9O1027223 for ; Fri, 14 Jan 2005 11:44:09 -0800 (PST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpXBK-00041w-2N; Fri, 14 Jan 2005 14:32:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpX50-0002ij-8t; Fri, 14 Jan 2005 14:25:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07248; Fri, 14 Jan 2005 14:25:53 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpXJS-0001sU-FQ; Fri, 14 Jan 2005 14:40:53 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 14 Jan 2005 12:31:57 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0EJPEvl014441; Fri, 14 Jan 2005 11:25:15 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn1-595.cisco.com [10.21.98.83]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BCT25669; Fri, 14 Jan 2005 11:25:16 -0800 (PST) Message-Id: <4.3.2.7.2.20050114111849.02cacbe0@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jan 2005 11:25:16 -0800 To: "Saverio Niccolini" From: Andy Bierman In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Subject: [Disman] RE: [ippm] Way to store traceroutes X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on mgate1.riverstonenet.com X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: disman@ietf.org, ippm@ietf.org X-BeenThere: ippm@ietf.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 07:59 AM 1/14/2005, Saverio Niccolini wrote: >Dear all, >thanks a lot for your useful suggestions. This work is already established in the DISMAN WG. See RFC 2925, or its update (in progress): http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-06.txt I strongly urge you to work with the DISMAN WG to resolve perceived deficiencies with the RemOps MIB, rather than create a spin-off MIB. Andy >We have tried to draft a "traceroute object" based on what we discussed >on the list and what we had in mind. We think this will serve as a >starting point of our information model. > >We have taken the disman draft as a starting point and we have erased >some fields not useful in the scope of our draft (that we do not specify >here), moreover we have added and changed other ones: > >NEW fields: >1) traceRouteResultsLastGoodPathDuration (duration of single running of >the last good traceroute path determination) >2) traceRouteResultsLastRun (when the last traceroute with these >characteristics was launched) >3) traceRouteHopsASNumber (AS number of the hop) > >CHANGED fields: >1) traceRouteProbeHistoryTime (timestamp of when the traceroute probe >came back) was changed to traceRouteProbeHistorySentTime (timestamp of >when the traceroute probe was sent) > > >Please find here how the "traceroute object" looks like right now: > >--traceRouteObjects > | > +--traceRouteCtlTable > | | > | +--traceRouteCtlEntry > | | > | +--traceRouteCtlOwnerIndex > | +--traceRouteCtlTestName > | +--traceRouteCtlTargetAddressType > | +--traceRouteCtlTargetAddress > | +--traceRouteCtlByPassRouteTable > | +--traceRouteCtlDataSize > | +--traceRouteCtlTimeOut > | +--traceRouteCtlProbesPerHop > | +--traceRouteCtlPort > | +--traceRouteCtlMaxTtl > | +--traceRouteCtlDSField > | +--traceRouteCtlSourceAddressType > | +--traceRouteCtlSourceAddress > | +--traceRouteCtlIfIndex > | +--traceRouteCtlMiscOptions > | +--traceRouteCtlMaxFailures > | +--traceRouteCtlDontFragment > | +--traceRouteCtlInitialTtl > | +--traceRouteCtlDescr > | +--traceRouteCtlMaxRows > | +--traceRouteCtlCreateHopsEntries > | +--traceRouteCtlType > | > +--traceRouteResultsTable > | | > | +--traceRouteResultsEntry > | | > | +--traceRouteResultsOperStatus > | +--traceRouteResultsIpTgtAddrType > | +--traceRouteResultsIpTgtAddr > | +--traceRouteResultsTestAttempts > | +--traceRouteResultsTestSuccesses > | +--traceRouteResultsLastGoodPath > | +--traceRouteResultsLastGoodPathDuration > | +--traceRouteResultsLastRun > | > +--traceRouteProbeHistoryTable > | | > | +--traceRouteProbeHistoryEntry > | | > | +--traceRouteProbeHistoryIndex > | +--traceRouteProbeHistoryHopIndex > | +--traceRouteProbeHistoryProbeIndex > | +--traceRouteProbeHistoryHAddrType > | +--traceRouteProbeHistoryHAddr > | +--traceRouteProbeHistoryResponse > | +--traceRouteProbeHistoryStatus > | +--traceRouteProbeHistorySentTime > | > +--traceRouteHopsTable > | > +--traceRouteHopsEntry > | > +--traceRouteHopsHopIndex > +--traceRouteHopsIpTgtAddressType > +--traceRouteHopsIpTgtAddress > +--traceRouteHopsASNumber > +--traceRouteHopsMinRtt > +--traceRouteHopsMaxRtt > +--traceRouteHopsAverageRtt > +--traceRouteHopsRttSumOfSquares > +--traceRouteHopsSentProbes > +--traceRouteHopsProbeResponses > >We believe that most of the fields are self-explaining, for the unclear >ones please refer to the disman draft: >http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-06.t >xt > >Looking forward to receive your comments. > >Best regards, >Saverio Niccolini > >============================================================ >Dr. Saverio Niccolini >Research Staff Member >Network Laboratories, NEC Europe Ltd. >Kurfuerstenanlage 36, D-69115 Heidelberg >Tel. +49 (0)6221 90511-18 >Fax: +49 (0)6221 90511-55 >e-mail: saverio.niccolini@netlab.nec.de >============================================================ > > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Jan 17 08:19:28 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02977 for ; Mon, 17 Jan 2005 08:19:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqWfs-0002TO-J3; Mon, 17 Jan 2005 08:12:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqWZA-0001us-Fe; Mon, 17 Jan 2005 08:05:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01913; Mon, 17 Jan 2005 08:05:07 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqWoC-0003fE-TL; Mon, 17 Jan 2005 08:20:42 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 4A4BDD96D; Mon, 17 Jan 2005 13:51:17 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] Way to store traceroutes Date: Mon, 17 Jan 2005 14:03:42 +0100 Message-ID: Thread-Topic: [ippm] Way to store traceroutes Thread-Index: AcT8elJQiTEyHdb6SZ6YuQ3oIhMxaQAGhuqg From: "Saverio Niccolini" To: "Andy Bierman" X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Content-Transfer-Encoding: quoted-printable Cc: disman@ietf.org, ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Andy, the purpose of our draft is to define a file format in order to store traceroute measurements and not a MIB module. The confusion is maybe created by the fact that we just kept the names from the disman draft-RFC in order to facilitate comprehension of the fields itself. By the way, I do not know if the IPPM list agrees on this. Does the IPPM charter want to define a MIB module for traceroute measurements? Best regards, Saverio > -----Original Message----- > From: Juergen Quittek [mailto:quittek@netlab.nec.de] > Sent: 17 January 2005 10:53 > To: Andy Bierman; Saverio Niccolini > Cc: disman@ietf.org; ippm@ietf.org > Subject: RE: [ippm] Way to store traceroutes >=20 > Hi Andy, >=20 > --On 14.01.2005 20:25 Uhr +0100 Andy Bierman wrote: >=20 > > At 07:59 AM 1/14/2005, Saverio Niccolini wrote: > >> Dear all, > >> thanks a lot for your useful suggestions. > > > > This work is already established in the DISMAN WG. See RFC 2925, > > or its update (in progress): > > http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2- > 06.txt >=20 > Saverio and Sandra already had a look at the DISMAN-TRACEROUTE-MIB. >=20 > > I strongly urge you to work with the DISMAN WG to resolve > > perceived deficiencies with the RemOps MIB, rather than > > create a spin-off MIB. >=20 > As editor of draft-ietf-disman-remops-mib-v2-06.txt I wonder > what you consider as 'perceived deficiencies with the RemOps MIB'. >=20 > In the context of IPPM, there is certainly the deficiency, that > you can only store measurements that were performed locally and that > the tables for storing measurement results are read-only. >=20 > But anyway, does the IPPM WG plan to store traceroute results in a MIB? >=20 > Thanks, >=20 > Juergen > -- > Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > http://www.netlab.nec.de >=20 >=20 > > Andy > > > > > > > >> We have tried to draft a "traceroute object" based on what we discussed > >> on the list and what we had in mind. We think this will serve as a > >> starting point of our information model. > >> > >> We have taken the disman draft as a starting point and we have erased > >> some fields not useful in the scope of our draft (that we do not > specify > >> here), moreover we have added and changed other ones: > >> > >> NEW fields: > >> 1) traceRouteResultsLastGoodPathDuration (duration of single running of > >> the last good traceroute path determination) > >> 2) traceRouteResultsLastRun (when the last traceroute with these > >> characteristics was launched) > >> 3) traceRouteHopsASNumber (AS number of the hop) > >> > >> CHANGED fields: > >> 1) traceRouteProbeHistoryTime (timestamp of when the traceroute probe > >> came back) was changed to traceRouteProbeHistorySentTime (timestamp of > >> when the traceroute probe was sent) > >> > >> > >> Please find here how the "traceroute object" looks like right now: > >> > >> --traceRouteObjects > >> | > >> +--traceRouteCtlTable > >> | | > >> | +--traceRouteCtlEntry > >> | | > >> | +--traceRouteCtlOwnerIndex > >> | +--traceRouteCtlTestName > >> | +--traceRouteCtlTargetAddressType > >> | +--traceRouteCtlTargetAddress > >> | +--traceRouteCtlByPassRouteTable > >> | +--traceRouteCtlDataSize > >> | +--traceRouteCtlTimeOut > >> | +--traceRouteCtlProbesPerHop > >> | +--traceRouteCtlPort > >> | +--traceRouteCtlMaxTtl > >> | +--traceRouteCtlDSField > >> | +--traceRouteCtlSourceAddressType > >> | +--traceRouteCtlSourceAddress > >> | +--traceRouteCtlIfIndex > >> | +--traceRouteCtlMiscOptions > >> | +--traceRouteCtlMaxFailures > >> | +--traceRouteCtlDontFragment > >> | +--traceRouteCtlInitialTtl > >> | +--traceRouteCtlDescr > >> | +--traceRouteCtlMaxRows > >> | +--traceRouteCtlCreateHopsEntries > >> | +--traceRouteCtlType > >> | > >> +--traceRouteResultsTable > >> | | > >> | +--traceRouteResultsEntry > >> | | > >> | +--traceRouteResultsOperStatus > >> | +--traceRouteResultsIpTgtAddrType > >> | +--traceRouteResultsIpTgtAddr > >> | +--traceRouteResultsTestAttempts > >> | +--traceRouteResultsTestSuccesses > >> | +--traceRouteResultsLastGoodPath > >> | +--traceRouteResultsLastGoodPathDuration > >> | +--traceRouteResultsLastRun > >> | > >> +--traceRouteProbeHistoryTable > >> | | > >> | +--traceRouteProbeHistoryEntry > >> | | > >> | +--traceRouteProbeHistoryIndex > >> | +--traceRouteProbeHistoryHopIndex > >> | +--traceRouteProbeHistoryProbeIndex > >> | +--traceRouteProbeHistoryHAddrType > >> | +--traceRouteProbeHistoryHAddr > >> | +--traceRouteProbeHistoryResponse > >> | +--traceRouteProbeHistoryStatus > >> | +--traceRouteProbeHistorySentTime > >> | > >> +--traceRouteHopsTable > >> | > >> +--traceRouteHopsEntry > >> | > >> +--traceRouteHopsHopIndex > >> +--traceRouteHopsIpTgtAddressType > >> +--traceRouteHopsIpTgtAddress > >> +--traceRouteHopsASNumber > >> +--traceRouteHopsMinRtt > >> +--traceRouteHopsMaxRtt > >> +--traceRouteHopsAverageRtt > >> +--traceRouteHopsRttSumOfSquares > >> +--traceRouteHopsSentProbes > >> +--traceRouteHopsProbeResponses > >> > >> We believe that most of the fields are self-explaining, for the unclear > >> ones please refer to the disman draft: > >> http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2- > 06.t > >> xt > >> > >> Looking forward to receive your comments. > >> > >> Best regards, > >> Saverio Niccolini > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> Dr. Saverio Niccolini > >> Research Staff Member > >> Network Laboratories, NEC Europe Ltd. > >> Kurfuerstenanlage 36, D-69115 Heidelberg > >> Tel. +49 (0)6221 90511-18 > >> Fax: +49 (0)6221 90511-55 > >> e-mail: saverio.niccolini@netlab.nec.de > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> > >> _______________________________________________ > >> ippm mailing list > >> ippm@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ippm > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www1.ietf.org/mailman/listinfo/ippm >=20 >=20 >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Jan 17 11:35:25 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21331 for ; Mon, 17 Jan 2005 11:35:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZiL-0008Le-7I; Mon, 17 Jan 2005 11:26:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqTZn-0000Rj-4e; Mon, 17 Jan 2005 04:53:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21089; Mon, 17 Jan 2005 04:53:32 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqTon-0008NW-DO; Mon, 17 Jan 2005 05:09:07 -0500 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id E3BE41BAC9F; Mon, 17 Jan 2005 10:52:51 +0100 (CET) Date: Mon, 17 Jan 2005 10:52:53 +0100 From: Juergen Quittek To: Andy Bierman , Saverio Niccolini Subject: RE: [ippm] Way to store traceroutes Message-ID: <2147483647.1105959173@[10.1.1.171]> In-Reply-To: <4.3.2.7.2.20050114111849.02cacbe0@fedex.cisco.com> References: <4.3.2.7.2.20050114111849.02cacbe0@fedex.cisco.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 17 Jan 2005 11:26:47 -0500 Cc: disman@ietf.org, ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Andy, --On 14.01.2005 20:25 Uhr +0100 Andy Bierman wrote: > At 07:59 AM 1/14/2005, Saverio Niccolini wrote: >> Dear all, >> thanks a lot for your useful suggestions. > > This work is already established in the DISMAN WG. See RFC 2925, > or its update (in progress): > http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-06.txt Saverio and Sandra already had a look at the DISMAN-TRACEROUTE-MIB. > I strongly urge you to work with the DISMAN WG to resolve > perceived deficiencies with the RemOps MIB, rather than > create a spin-off MIB. As editor of draft-ietf-disman-remops-mib-v2-06.txt I wonder what you consider as 'perceived deficiencies with the RemOps MIB'. In the context of IPPM, there is certainly the deficiency, that you can only store measurements that were performed locally and that the tables for storing measurement results are read-only. But anyway, does the IPPM WG plan to store traceroute results in a MIB? Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de > Andy > > > >> We have tried to draft a "traceroute object" based on what we discussed >> on the list and what we had in mind. We think this will serve as a >> starting point of our information model. >> >> We have taken the disman draft as a starting point and we have erased >> some fields not useful in the scope of our draft (that we do not specify >> here), moreover we have added and changed other ones: >> >> NEW fields: >> 1) traceRouteResultsLastGoodPathDuration (duration of single running of >> the last good traceroute path determination) >> 2) traceRouteResultsLastRun (when the last traceroute with these >> characteristics was launched) >> 3) traceRouteHopsASNumber (AS number of the hop) >> >> CHANGED fields: >> 1) traceRouteProbeHistoryTime (timestamp of when the traceroute probe >> came back) was changed to traceRouteProbeHistorySentTime (timestamp of >> when the traceroute probe was sent) >> >> >> Please find here how the "traceroute object" looks like right now: >> >> --traceRouteObjects >> | >> +--traceRouteCtlTable >> | | >> | +--traceRouteCtlEntry >> | | >> | +--traceRouteCtlOwnerIndex >> | +--traceRouteCtlTestName >> | +--traceRouteCtlTargetAddressType >> | +--traceRouteCtlTargetAddress >> | +--traceRouteCtlByPassRouteTable >> | +--traceRouteCtlDataSize >> | +--traceRouteCtlTimeOut >> | +--traceRouteCtlProbesPerHop >> | +--traceRouteCtlPort >> | +--traceRouteCtlMaxTtl >> | +--traceRouteCtlDSField >> | +--traceRouteCtlSourceAddressType >> | +--traceRouteCtlSourceAddress >> | +--traceRouteCtlIfIndex >> | +--traceRouteCtlMiscOptions >> | +--traceRouteCtlMaxFailures >> | +--traceRouteCtlDontFragment >> | +--traceRouteCtlInitialTtl >> | +--traceRouteCtlDescr >> | +--traceRouteCtlMaxRows >> | +--traceRouteCtlCreateHopsEntries >> | +--traceRouteCtlType >> | >> +--traceRouteResultsTable >> | | >> | +--traceRouteResultsEntry >> | | >> | +--traceRouteResultsOperStatus >> | +--traceRouteResultsIpTgtAddrType >> | +--traceRouteResultsIpTgtAddr >> | +--traceRouteResultsTestAttempts >> | +--traceRouteResultsTestSuccesses >> | +--traceRouteResultsLastGoodPath >> | +--traceRouteResultsLastGoodPathDuration >> | +--traceRouteResultsLastRun >> | >> +--traceRouteProbeHistoryTable >> | | >> | +--traceRouteProbeHistoryEntry >> | | >> | +--traceRouteProbeHistoryIndex >> | +--traceRouteProbeHistoryHopIndex >> | +--traceRouteProbeHistoryProbeIndex >> | +--traceRouteProbeHistoryHAddrType >> | +--traceRouteProbeHistoryHAddr >> | +--traceRouteProbeHistoryResponse >> | +--traceRouteProbeHistoryStatus >> | +--traceRouteProbeHistorySentTime >> | >> +--traceRouteHopsTable >> | >> +--traceRouteHopsEntry >> | >> +--traceRouteHopsHopIndex >> +--traceRouteHopsIpTgtAddressType >> +--traceRouteHopsIpTgtAddress >> +--traceRouteHopsASNumber >> +--traceRouteHopsMinRtt >> +--traceRouteHopsMaxRtt >> +--traceRouteHopsAverageRtt >> +--traceRouteHopsRttSumOfSquares >> +--traceRouteHopsSentProbes >> +--traceRouteHopsProbeResponses >> >> We believe that most of the fields are self-explaining, for the unclear >> ones please refer to the disman draft: >> http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-06.t >> xt >> >> Looking forward to receive your comments. >> >> Best regards, >> Saverio Niccolini >> >> ============================================================ >> Dr. Saverio Niccolini >> Research Staff Member >> Network Laboratories, NEC Europe Ltd. >> Kurfuerstenanlage 36, D-69115 Heidelberg >> Tel. +49 (0)6221 90511-18 >> Fax: +49 (0)6221 90511-55 >> e-mail: saverio.niccolini@netlab.nec.de >> ============================================================ >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www1.ietf.org/mailman/listinfo/ippm > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Jan 17 11:36:30 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21450 for ; Mon, 17 Jan 2005 11:36:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZiL-0008Lj-O7; Mon, 17 Jan 2005 11:26:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqTpl-0002Pc-3G; Mon, 17 Jan 2005 05:10:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22444; Mon, 17 Jan 2005 05:10:02 -0500 (EST) Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqU4l-0000Kn-Mp; Mon, 17 Jan 2005 05:25:37 -0500 Received: from mgate1.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id CAA07093; Mon, 17 Jan 2005 02:09:21 -0800 (PST) Received: (from daemon@localhost) by mgate1.riverstonenet.com (8.13.1/8.13.1) id j0HA9L7p000790; Mon, 17 Jan 2005 02:09:21 -0800 (PST) X-Authentication-Warning: mgate1.riverstonenet.com: Processed by daemon with -C /etc/mail/sendmail-simple.cf Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mgate1.riverstonenet.com (8.13.1/8.13.1) with ESMTP id j0HA9EGb000775 for ; Mon, 17 Jan 2005 02:09:14 -0800 (PST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqThZ-0001FR-97; Mon, 17 Jan 2005 05:01:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqTZn-0000Rj-4e; Mon, 17 Jan 2005 04:53:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21089; Mon, 17 Jan 2005 04:53:32 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqTon-0008NW-DO; Mon, 17 Jan 2005 05:09:07 -0500 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id E3BE41BAC9F; Mon, 17 Jan 2005 10:52:51 +0100 (CET) Date: Mon, 17 Jan 2005 10:52:53 +0100 From: Juergen Quittek To: Andy Bierman , Saverio Niccolini Message-ID: <2147483647.1105959173@[10.1.1.171]> In-Reply-To: <4.3.2.7.2.20050114111849.02cacbe0@fedex.cisco.com> References: <4.3.2.7.2.20050114111849.02cacbe0@fedex.cisco.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: 7bit Subject: [Disman] RE: [ippm] Way to store traceroutes X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on mgate1.riverstonenet.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 17 Jan 2005 11:26:47 -0500 Cc: disman@ietf.org, ippm@ietf.org X-BeenThere: ippm@ietf.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Andy, --On 14.01.2005 20:25 Uhr +0100 Andy Bierman wrote: > At 07:59 AM 1/14/2005, Saverio Niccolini wrote: >> Dear all, >> thanks a lot for your useful suggestions. > > This work is already established in the DISMAN WG. See RFC 2925, > or its update (in progress): > http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-06.txt Saverio and Sandra already had a look at the DISMAN-TRACEROUTE-MIB. > I strongly urge you to work with the DISMAN WG to resolve > perceived deficiencies with the RemOps MIB, rather than > create a spin-off MIB. As editor of draft-ietf-disman-remops-mib-v2-06.txt I wonder what you consider as 'perceived deficiencies with the RemOps MIB'. In the context of IPPM, there is certainly the deficiency, that you can only store measurements that were performed locally and that the tables for storing measurement results are read-only. But anyway, does the IPPM WG plan to store traceroute results in a MIB? Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de > Andy > > > >> We have tried to draft a "traceroute object" based on what we discussed >> on the list and what we had in mind. We think this will serve as a >> starting point of our information model. >> >> We have taken the disman draft as a starting point and we have erased >> some fields not useful in the scope of our draft (that we do not specify >> here), moreover we have added and changed other ones: >> >> NEW fields: >> 1) traceRouteResultsLastGoodPathDuration (duration of single running of >> the last good traceroute path determination) >> 2) traceRouteResultsLastRun (when the last traceroute with these >> characteristics was launched) >> 3) traceRouteHopsASNumber (AS number of the hop) >> >> CHANGED fields: >> 1) traceRouteProbeHistoryTime (timestamp of when the traceroute probe >> came back) was changed to traceRouteProbeHistorySentTime (timestamp of >> when the traceroute probe was sent) >> >> >> Please find here how the "traceroute object" looks like right now: >> >> --traceRouteObjects >> | >> +--traceRouteCtlTable >> | | >> | +--traceRouteCtlEntry >> | | >> | +--traceRouteCtlOwnerIndex >> | +--traceRouteCtlTestName >> | +--traceRouteCtlTargetAddressType >> | +--traceRouteCtlTargetAddress >> | +--traceRouteCtlByPassRouteTable >> | +--traceRouteCtlDataSize >> | +--traceRouteCtlTimeOut >> | +--traceRouteCtlProbesPerHop >> | +--traceRouteCtlPort >> | +--traceRouteCtlMaxTtl >> | +--traceRouteCtlDSField >> | +--traceRouteCtlSourceAddressType >> | +--traceRouteCtlSourceAddress >> | +--traceRouteCtlIfIndex >> | +--traceRouteCtlMiscOptions >> | +--traceRouteCtlMaxFailures >> | +--traceRouteCtlDontFragment >> | +--traceRouteCtlInitialTtl >> | +--traceRouteCtlDescr >> | +--traceRouteCtlMaxRows >> | +--traceRouteCtlCreateHopsEntries >> | +--traceRouteCtlType >> | >> +--traceRouteResultsTable >> | | >> | +--traceRouteResultsEntry >> | | >> | +--traceRouteResultsOperStatus >> | +--traceRouteResultsIpTgtAddrType >> | +--traceRouteResultsIpTgtAddr >> | +--traceRouteResultsTestAttempts >> | +--traceRouteResultsTestSuccesses >> | +--traceRouteResultsLastGoodPath >> | +--traceRouteResultsLastGoodPathDuration >> | +--traceRouteResultsLastRun >> | >> +--traceRouteProbeHistoryTable >> | | >> | +--traceRouteProbeHistoryEntry >> | | >> | +--traceRouteProbeHistoryIndex >> | +--traceRouteProbeHistoryHopIndex >> | +--traceRouteProbeHistoryProbeIndex >> | +--traceRouteProbeHistoryHAddrType >> | +--traceRouteProbeHistoryHAddr >> | +--traceRouteProbeHistoryResponse >> | +--traceRouteProbeHistoryStatus >> | +--traceRouteProbeHistorySentTime >> | >> +--traceRouteHopsTable >> | >> +--traceRouteHopsEntry >> | >> +--traceRouteHopsHopIndex >> +--traceRouteHopsIpTgtAddressType >> +--traceRouteHopsIpTgtAddress >> +--traceRouteHopsASNumber >> +--traceRouteHopsMinRtt >> +--traceRouteHopsMaxRtt >> +--traceRouteHopsAverageRtt >> +--traceRouteHopsRttSumOfSquares >> +--traceRouteHopsSentProbes >> +--traceRouteHopsProbeResponses >> >> We believe that most of the fields are self-explaining, for the unclear >> ones please refer to the disman draft: >> http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-06.t >> xt >> >> Looking forward to receive your comments. >> >> Best regards, >> Saverio Niccolini >> >> ============================================================ >> Dr. Saverio Niccolini >> Research Staff Member >> Network Laboratories, NEC Europe Ltd. >> Kurfuerstenanlage 36, D-69115 Heidelberg >> Tel. +49 (0)6221 90511-18 >> Fax: +49 (0)6221 90511-55 >> e-mail: saverio.niccolini@netlab.nec.de >> ============================================================ >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www1.ietf.org/mailman/listinfo/ippm > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Jan 17 11:54:03 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23375 for ; Mon, 17 Jan 2005 11:54:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZxp-0002q1-Nm; Mon, 17 Jan 2005 11:42:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZse-0002Hw-AU; Mon, 17 Jan 2005 11:37:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21616; Mon, 17 Jan 2005 11:37:25 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqa7j-0000SL-HA; Mon, 17 Jan 2005 11:53:04 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id B560924F5E; Mon, 17 Jan 2005 17:36:56 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 93DE924F57; Mon, 17 Jan 2005 17:36:55 +0100 (CET) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j0HGasZt017684; Mon, 17 Jan 2005 17:36:55 +0100 Message-Id: <6.2.0.14.2.20050117173544.02bc24b0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 17 Jan 2005 17:36:48 +0100 To: "Saverio Niccolini" , "Andy Bierman" From: Henk Uijterwaal Subject: RE: [ippm] Way to store traceroutes In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000431 / -5.9 X-RIPE-Signature: 63d2c5d4a80ed0dd047f4bf2a33fe854 X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: disman@ietf.org, ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Saverio, >By the way, I do not know if the IPPM list agrees on this. >Does the IPPM charter want to define a MIB module for traceroute >measurements? Given the lack of interest in the previous MIB we discussed, and the lack of expertise to review any proposal, I'd say: NO. Henk >Best regards, >Saverio > > > -----Original Message----- > > From: Juergen Quittek [mailto:quittek@netlab.nec.de] > > Sent: 17 January 2005 10:53 > > To: Andy Bierman; Saverio Niccolini > > Cc: disman@ietf.org; ippm@ietf.org > > Subject: RE: [ippm] Way to store traceroutes > > > > Hi Andy, > > > > --On 14.01.2005 20:25 Uhr +0100 Andy Bierman wrote: > > > > > At 07:59 AM 1/14/2005, Saverio Niccolini wrote: > > >> Dear all, > > >> thanks a lot for your useful suggestions. > > > > > > This work is already established in the DISMAN WG. See RFC 2925, > > > or its update (in progress): > > > http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2- > > 06.txt > > > > Saverio and Sandra already had a look at the DISMAN-TRACEROUTE-MIB. > > > > > I strongly urge you to work with the DISMAN WG to resolve > > > perceived deficiencies with the RemOps MIB, rather than > > > create a spin-off MIB. > > > > As editor of draft-ietf-disman-remops-mib-v2-06.txt I wonder > > what you consider as 'perceived deficiencies with the RemOps MIB'. > > > > In the context of IPPM, there is certainly the deficiency, that > > you can only store measurements that were performed locally and that > > the tables for storing measurement results are read-only. > > > > But anyway, does the IPPM WG plan to store traceroute results in a >MIB? > > > > Thanks, > > > > Juergen > > -- > > Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 >90511-15 > > NEC Europe Ltd., Network Laboratories Fax: +49 6221 >90511-55 > > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > > http://www.netlab.nec.de > > > > > > > Andy > > > > > > > > > > > >> We have tried to draft a "traceroute object" based on what we >discussed > > >> on the list and what we had in mind. We think this will serve as a > > >> starting point of our information model. > > >> > > >> We have taken the disman draft as a starting point and we have >erased > > >> some fields not useful in the scope of our draft (that we do not > > specify > > >> here), moreover we have added and changed other ones: > > >> > > >> NEW fields: > > >> 1) traceRouteResultsLastGoodPathDuration (duration of single >running of > > >> the last good traceroute path determination) > > >> 2) traceRouteResultsLastRun (when the last traceroute with these > > >> characteristics was launched) > > >> 3) traceRouteHopsASNumber (AS number of the hop) > > >> > > >> CHANGED fields: > > >> 1) traceRouteProbeHistoryTime (timestamp of when the traceroute >probe > > >> came back) was changed to traceRouteProbeHistorySentTime (timestamp >of > > >> when the traceroute probe was sent) > > >> > > >> > > >> Please find here how the "traceroute object" looks like right now: > > >> > > >> --traceRouteObjects > > >> | > > >> +--traceRouteCtlTable > > >> | | > > >> | +--traceRouteCtlEntry > > >> | | > > >> | +--traceRouteCtlOwnerIndex > > >> | +--traceRouteCtlTestName > > >> | +--traceRouteCtlTargetAddressType > > >> | +--traceRouteCtlTargetAddress > > >> | +--traceRouteCtlByPassRouteTable > > >> | +--traceRouteCtlDataSize > > >> | +--traceRouteCtlTimeOut > > >> | +--traceRouteCtlProbesPerHop > > >> | +--traceRouteCtlPort > > >> | +--traceRouteCtlMaxTtl > > >> | +--traceRouteCtlDSField > > >> | +--traceRouteCtlSourceAddressType > > >> | +--traceRouteCtlSourceAddress > > >> | +--traceRouteCtlIfIndex > > >> | +--traceRouteCtlMiscOptions > > >> | +--traceRouteCtlMaxFailures > > >> | +--traceRouteCtlDontFragment > > >> | +--traceRouteCtlInitialTtl > > >> | +--traceRouteCtlDescr > > >> | +--traceRouteCtlMaxRows > > >> | +--traceRouteCtlCreateHopsEntries > > >> | +--traceRouteCtlType > > >> | > > >> +--traceRouteResultsTable > > >> | | > > >> | +--traceRouteResultsEntry > > >> | | > > >> | +--traceRouteResultsOperStatus > > >> | +--traceRouteResultsIpTgtAddrType > > >> | +--traceRouteResultsIpTgtAddr > > >> | +--traceRouteResultsTestAttempts > > >> | +--traceRouteResultsTestSuccesses > > >> | +--traceRouteResultsLastGoodPath > > >> | +--traceRouteResultsLastGoodPathDuration > > >> | +--traceRouteResultsLastRun > > >> | > > >> +--traceRouteProbeHistoryTable > > >> | | > > >> | +--traceRouteProbeHistoryEntry > > >> | | > > >> | +--traceRouteProbeHistoryIndex > > >> | +--traceRouteProbeHistoryHopIndex > > >> | +--traceRouteProbeHistoryProbeIndex > > >> | +--traceRouteProbeHistoryHAddrType > > >> | +--traceRouteProbeHistoryHAddr > > >> | +--traceRouteProbeHistoryResponse > > >> | +--traceRouteProbeHistoryStatus > > >> | +--traceRouteProbeHistorySentTime > > >> | > > >> +--traceRouteHopsTable > > >> | > > >> +--traceRouteHopsEntry > > >> | > > >> +--traceRouteHopsHopIndex > > >> +--traceRouteHopsIpTgtAddressType > > >> +--traceRouteHopsIpTgtAddress > > >> +--traceRouteHopsASNumber > > >> +--traceRouteHopsMinRtt > > >> +--traceRouteHopsMaxRtt > > >> +--traceRouteHopsAverageRtt > > >> +--traceRouteHopsRttSumOfSquares > > >> +--traceRouteHopsSentProbes > > >> +--traceRouteHopsProbeResponses > > >> > > >> We believe that most of the fields are self-explaining, for the >unclear > > >> ones please refer to the disman draft: > > >> >http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2- > > 06.t > > >> xt > > >> > > >> Looking forward to receive your comments. > > >> > > >> Best regards, > > >> Saverio Niccolini > > >> > > >> ============================================================ > > >> Dr. Saverio Niccolini > > >> Research Staff Member > > >> Network Laboratories, NEC Europe Ltd. > > >> Kurfuerstenanlage 36, D-69115 Heidelberg > > >> Tel. +49 (0)6221 90511-18 > > >> Fax: +49 (0)6221 90511-55 > > >> e-mail: saverio.niccolini@netlab.nec.de > > >> ============================================================ > > >> > > >> > > >> _______________________________________________ > > >> ippm mailing list > > >> ippm@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/ippm > > > > > > _______________________________________________ > > > ippm mailing list > > > ippm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ippm > > > > > > > > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www1.ietf.org/mailman/listinfo/ippm ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Jan 17 12:37:20 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27159 for ; Mon, 17 Jan 2005 12:37:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqaeb-0003nQ-V1; Mon, 17 Jan 2005 12:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqadg-0003c6-QL; Mon, 17 Jan 2005 12:26:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25392; Mon, 17 Jan 2005 12:26:01 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqasl-0001bd-Eq; Mon, 17 Jan 2005 12:41:41 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 Jan 2005 09:29:43 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0HHPSl2009001; Mon, 17 Jan 2005 09:25:28 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn1-481.cisco.com [10.21.97.225]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BCU45818; Mon, 17 Jan 2005 09:25:27 -0800 (PST) Message-Id: <4.3.2.7.2.20050117092146.02038530@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Jan 2005 09:25:27 -0800 To: Henk Uijterwaal From: Andy Bierman Subject: RE: [ippm] Way to store traceroutes In-Reply-To: <6.2.0.14.2.20050117173544.02bc24b0@localhost> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Cc: disman@ietf.org, Saverio Niccolini , ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 08:36 AM 1/17/2005, Henk Uijterwaal wrote: >Saverio, > >>By the way, I do not know if the IPPM list agrees on this. >>Does the IPPM charter want to define a MIB module for traceroute >>measurements? > >Given the lack of interest in the previous MIB we discussed, and >the lack of expertise to review any proposal, I'd say: NO. And since this seems to be an extension to a standard developed in the DISMAN WG, if this work belongs anywhere in the IETF, it's DISMAN. >Henk Andy >>Best regards, >>Saverio >> >>> -----Original Message----- >>> From: Juergen Quittek [mailto:quittek@netlab.nec.de] >>> Sent: 17 January 2005 10:53 >>> To: Andy Bierman; Saverio Niccolini >>> Cc: disman@ietf.org; ippm@ietf.org >>> Subject: RE: [ippm] Way to store traceroutes >>> >>> Hi Andy, >>> >>> --On 14.01.2005 20:25 Uhr +0100 Andy Bierman wrote: >>> >>> > At 07:59 AM 1/14/2005, Saverio Niccolini wrote: >>> >> Dear all, >>> >> thanks a lot for your useful suggestions. >>> > >>> > This work is already established in the DISMAN WG. See RFC 2925, >>> > or its update (in progress): >>> > http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2- >>> 06.txt >>> >>> Saverio and Sandra already had a look at the DISMAN-TRACEROUTE-MIB. >>> >>> > I strongly urge you to work with the DISMAN WG to resolve >>> > perceived deficiencies with the RemOps MIB, rather than >>> > create a spin-off MIB. >>> >>> As editor of draft-ietf-disman-remops-mib-v2-06.txt I wonder >>> what you consider as 'perceived deficiencies with the RemOps MIB'. >>> >>> In the context of IPPM, there is certainly the deficiency, that >>> you can only store measurements that were performed locally and that >>> the tables for storing measurement results are read-only. >>> >>> But anyway, does the IPPM WG plan to store traceroute results in a >>MIB? >>> >>> Thanks, >>> >>> Juergen >>> -- >>> Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 >>90511-15 >>> NEC Europe Ltd., Network Laboratories Fax: +49 6221 >>90511-55 >>> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany >>> http://www.netlab.nec.de >>> >>> >>> > Andy >>> > >>> > >>> > >>> >> We have tried to draft a "traceroute object" based on what we >>discussed >>> >> on the list and what we had in mind. We think this will serve as a >>> >> starting point of our information model. >>> >> >>> >> We have taken the disman draft as a starting point and we have >>erased >>> >> some fields not useful in the scope of our draft (that we do not >>> specify >>> >> here), moreover we have added and changed other ones: >>> >> >>> >> NEW fields: >>> >> 1) traceRouteResultsLastGoodPathDuration (duration of single >>running of >>> >> the last good traceroute path determination) >>> >> 2) traceRouteResultsLastRun (when the last traceroute with these >>> >> characteristics was launched) >>> >> 3) traceRouteHopsASNumber (AS number of the hop) >>> >> >>> >> CHANGED fields: >>> >> 1) traceRouteProbeHistoryTime (timestamp of when the traceroute >>probe >>> >> came back) was changed to traceRouteProbeHistorySentTime (timestamp >>of >>> >> when the traceroute probe was sent) >>> >> >>> >> >>> >> Please find here how the "traceroute object" looks like right now: >>> >> >>> >> --traceRouteObjects >>> >> | >>> >> +--traceRouteCtlTable >>> >> | | >>> >> | +--traceRouteCtlEntry >>> >> | | >>> >> | +--traceRouteCtlOwnerIndex >>> >> | +--traceRouteCtlTestName >>> >> | +--traceRouteCtlTargetAddressType >>> >> | +--traceRouteCtlTargetAddress >>> >> | +--traceRouteCtlByPassRouteTable >>> >> | +--traceRouteCtlDataSize >>> >> | +--traceRouteCtlTimeOut >>> >> | +--traceRouteCtlProbesPerHop >>> >> | +--traceRouteCtlPort >>> >> | +--traceRouteCtlMaxTtl >>> >> | +--traceRouteCtlDSField >>> >> | +--traceRouteCtlSourceAddressType >>> >> | +--traceRouteCtlSourceAddress >>> >> | +--traceRouteCtlIfIndex >>> >> | +--traceRouteCtlMiscOptions >>> >> | +--traceRouteCtlMaxFailures >>> >> | +--traceRouteCtlDontFragment >>> >> | +--traceRouteCtlInitialTtl >>> >> | +--traceRouteCtlDescr >>> >> | +--traceRouteCtlMaxRows >>> >> | +--traceRouteCtlCreateHopsEntries >>> >> | +--traceRouteCtlType >>> >> | >>> >> +--traceRouteResultsTable >>> >> | | >>> >> | +--traceRouteResultsEntry >>> >> | | >>> >> | +--traceRouteResultsOperStatus >>> >> | +--traceRouteResultsIpTgtAddrType >>> >> | +--traceRouteResultsIpTgtAddr >>> >> | +--traceRouteResultsTestAttempts >>> >> | +--traceRouteResultsTestSuccesses >>> >> | +--traceRouteResultsLastGoodPath >>> >> | +--traceRouteResultsLastGoodPathDuration >>> >> | +--traceRouteResultsLastRun >>> >> | >>> >> +--traceRouteProbeHistoryTable >>> >> | | >>> >> | +--traceRouteProbeHistoryEntry >>> >> | | >>> >> | +--traceRouteProbeHistoryIndex >>> >> | +--traceRouteProbeHistoryHopIndex >>> >> | +--traceRouteProbeHistoryProbeIndex >>> >> | +--traceRouteProbeHistoryHAddrType >>> >> | +--traceRouteProbeHistoryHAddr >>> >> | +--traceRouteProbeHistoryResponse >>> >> | +--traceRouteProbeHistoryStatus >>> >> | +--traceRouteProbeHistorySentTime >>> >> | >>> >> +--traceRouteHopsTable >>> >> | >>> >> +--traceRouteHopsEntry >>> >> | >>> >> +--traceRouteHopsHopIndex >>> >> +--traceRouteHopsIpTgtAddressType >>> >> +--traceRouteHopsIpTgtAddress >>> >> +--traceRouteHopsASNumber >>> >> +--traceRouteHopsMinRtt >>> >> +--traceRouteHopsMaxRtt >>> >> +--traceRouteHopsAverageRtt >>> >> +--traceRouteHopsRttSumOfSquares >>> >> +--traceRouteHopsSentProbes >>> >> +--traceRouteHopsProbeResponses >>> >> >>> >> We believe that most of the fields are self-explaining, for the >>unclear >>> >> ones please refer to the disman draft: >>> >> >>http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2- >>> 06.t >>> >> xt >>> >> >>> >> Looking forward to receive your comments. >>> >> >>> >> Best regards, >>> >> Saverio Niccolini >>> >> >>> >> ============================================================ >>> >> Dr. Saverio Niccolini >>> >> Research Staff Member >>> >> Network Laboratories, NEC Europe Ltd. >>> >> Kurfuerstenanlage 36, D-69115 Heidelberg >>> >> Tel. +49 (0)6221 90511-18 >>> >> Fax: +49 (0)6221 90511-55 >>> >> e-mail: saverio.niccolini@netlab.nec.de >>> >> ============================================================ >>> >> >>> >> >>> >> _______________________________________________ >>> >> ippm mailing list >>> >> ippm@ietf.org >>> >> https://www1.ietf.org/mailman/listinfo/ippm >>> > >>> > _______________________________________________ >>> > ippm mailing list >>> > ippm@ietf.org >>> > https://www1.ietf.org/mailman/listinfo/ippm >>> >>> >>> >> >> >>_______________________________________________ >>ippm mailing list >>ippm@ietf.org >>https://www1.ietf.org/mailman/listinfo/ippm > >------------------------------------------------------------------------------ >Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net >RIPE Network Coordination Centre http://www.amsterdamned.org/~henk >P.O.Box 10096 Singel 258 Phone: +31.20.5354414 >1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 >The Netherlands The Netherlands Mobile: +31.6.55861746 >------------------------------------------------------------------------------ > >Look here junior, don't you be so happy. >And for Heaven's sake, don't you be so sad. (Tom Verlaine) > >_______________________________________________ >ippm mailing list >ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Jan 17 12:48:26 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28317 for ; Mon, 17 Jan 2005 12:48:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqavL-0006Ha-D1; Mon, 17 Jan 2005 12:44:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqaq2-0005YN-N3; Mon, 17 Jan 2005 12:38:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27289; Mon, 17 Jan 2005 12:38:47 -0500 (EST) Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqb57-00022I-Oe; Mon, 17 Jan 2005 12:54:26 -0500 Received: from mgate1.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id JAA09222; Mon, 17 Jan 2005 09:38:17 -0800 (PST) Received: (from daemon@localhost) by mgate1.riverstonenet.com (8.13.1/8.13.1) id j0HHcHKh029015; Mon, 17 Jan 2005 09:38:17 -0800 (PST) X-Authentication-Warning: mgate1.riverstonenet.com: Processed by daemon with -C /etc/mail/sendmail-simple.cf Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mgate1.riverstonenet.com (8.13.1/8.13.1) with ESMTP id j0HHcGOj029003 for ; Mon, 17 Jan 2005 09:38:16 -0800 (PST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqaec-0003nX-Li; Mon, 17 Jan 2005 12:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqadg-0003c6-QL; Mon, 17 Jan 2005 12:26:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25392; Mon, 17 Jan 2005 12:26:01 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqasl-0001bd-Eq; Mon, 17 Jan 2005 12:41:41 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 Jan 2005 09:29:43 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0HHPSl2009001; Mon, 17 Jan 2005 09:25:28 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn1-481.cisco.com [10.21.97.225]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BCU45818; Mon, 17 Jan 2005 09:25:27 -0800 (PST) Message-Id: <4.3.2.7.2.20050117092146.02038530@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Jan 2005 09:25:27 -0800 To: Henk Uijterwaal From: Andy Bierman In-Reply-To: <6.2.0.14.2.20050117173544.02bc24b0@localhost> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Subject: [Disman] RE: [ippm] Way to store traceroutes X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: disman@ietf.org, Saverio Niccolini , ippm@ietf.org X-BeenThere: ippm@ietf.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 08:36 AM 1/17/2005, Henk Uijterwaal wrote: >Saverio, > >>By the way, I do not know if the IPPM list agrees on this. >>Does the IPPM charter want to define a MIB module for traceroute >>measurements? > >Given the lack of interest in the previous MIB we discussed, and >the lack of expertise to review any proposal, I'd say: NO. And since this seems to be an extension to a standard developed in the DISMAN WG, if this work belongs anywhere in the IETF, it's DISMAN. >Henk Andy >>Best regards, >>Saverio >> >>> -----Original Message----- >>> From: Juergen Quittek [mailto:quittek@netlab.nec.de] >>> Sent: 17 January 2005 10:53 >>> To: Andy Bierman; Saverio Niccolini >>> Cc: disman@ietf.org; ippm@ietf.org >>> Subject: RE: [ippm] Way to store traceroutes >>> >>> Hi Andy, >>> >>> --On 14.01.2005 20:25 Uhr +0100 Andy Bierman wrote: >>> >>> > At 07:59 AM 1/14/2005, Saverio Niccolini wrote: >>> >> Dear all, >>> >> thanks a lot for your useful suggestions. >>> > >>> > This work is already established in the DISMAN WG. See RFC 2925, >>> > or its update (in progress): >>> > http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2- >>> 06.txt >>> >>> Saverio and Sandra already had a look at the DISMAN-TRACEROUTE-MIB. >>> >>> > I strongly urge you to work with the DISMAN WG to resolve >>> > perceived deficiencies with the RemOps MIB, rather than >>> > create a spin-off MIB. >>> >>> As editor of draft-ietf-disman-remops-mib-v2-06.txt I wonder >>> what you consider as 'perceived deficiencies with the RemOps MIB'. >>> >>> In the context of IPPM, there is certainly the deficiency, that >>> you can only store measurements that were performed locally and that >>> the tables for storing measurement results are read-only. >>> >>> But anyway, does the IPPM WG plan to store traceroute results in a >>MIB? >>> >>> Thanks, >>> >>> Juergen >>> -- >>> Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 >>90511-15 >>> NEC Europe Ltd., Network Laboratories Fax: +49 6221 >>90511-55 >>> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany >>> http://www.netlab.nec.de >>> >>> >>> > Andy >>> > >>> > >>> > >>> >> We have tried to draft a "traceroute object" based on what we >>discussed >>> >> on the list and what we had in mind. We think this will serve as a >>> >> starting point of our information model. >>> >> >>> >> We have taken the disman draft as a starting point and we have >>erased >>> >> some fields not useful in the scope of our draft (that we do not >>> specify >>> >> here), moreover we have added and changed other ones: >>> >> >>> >> NEW fields: >>> >> 1) traceRouteResultsLastGoodPathDuration (duration of single >>running of >>> >> the last good traceroute path determination) >>> >> 2) traceRouteResultsLastRun (when the last traceroute with these >>> >> characteristics was launched) >>> >> 3) traceRouteHopsASNumber (AS number of the hop) >>> >> >>> >> CHANGED fields: >>> >> 1) traceRouteProbeHistoryTime (timestamp of when the traceroute >>probe >>> >> came back) was changed to traceRouteProbeHistorySentTime (timestamp >>of >>> >> when the traceroute probe was sent) >>> >> >>> >> >>> >> Please find here how the "traceroute object" looks like right now: >>> >> >>> >> --traceRouteObjects >>> >> | >>> >> +--traceRouteCtlTable >>> >> | | >>> >> | +--traceRouteCtlEntry >>> >> | | >>> >> | +--traceRouteCtlOwnerIndex >>> >> | +--traceRouteCtlTestName >>> >> | +--traceRouteCtlTargetAddressType >>> >> | +--traceRouteCtlTargetAddress >>> >> | +--traceRouteCtlByPassRouteTable >>> >> | +--traceRouteCtlDataSize >>> >> | +--traceRouteCtlTimeOut >>> >> | +--traceRouteCtlProbesPerHop >>> >> | +--traceRouteCtlPort >>> >> | +--traceRouteCtlMaxTtl >>> >> | +--traceRouteCtlDSField >>> >> | +--traceRouteCtlSourceAddressType >>> >> | +--traceRouteCtlSourceAddress >>> >> | +--traceRouteCtlIfIndex >>> >> | +--traceRouteCtlMiscOptions >>> >> | +--traceRouteCtlMaxFailures >>> >> | +--traceRouteCtlDontFragment >>> >> | +--traceRouteCtlInitialTtl >>> >> | +--traceRouteCtlDescr >>> >> | +--traceRouteCtlMaxRows >>> >> | +--traceRouteCtlCreateHopsEntries >>> >> | +--traceRouteCtlType >>> >> | >>> >> +--traceRouteResultsTable >>> >> | | >>> >> | +--traceRouteResultsEntry >>> >> | | >>> >> | +--traceRouteResultsOperStatus >>> >> | +--traceRouteResultsIpTgtAddrType >>> >> | +--traceRouteResultsIpTgtAddr >>> >> | +--traceRouteResultsTestAttempts >>> >> | +--traceRouteResultsTestSuccesses >>> >> | +--traceRouteResultsLastGoodPath >>> >> | +--traceRouteResultsLastGoodPathDuration >>> >> | +--traceRouteResultsLastRun >>> >> | >>> >> +--traceRouteProbeHistoryTable >>> >> | | >>> >> | +--traceRouteProbeHistoryEntry >>> >> | | >>> >> | +--traceRouteProbeHistoryIndex >>> >> | +--traceRouteProbeHistoryHopIndex >>> >> | +--traceRouteProbeHistoryProbeIndex >>> >> | +--traceRouteProbeHistoryHAddrType >>> >> | +--traceRouteProbeHistoryHAddr >>> >> | +--traceRouteProbeHistoryResponse >>> >> | +--traceRouteProbeHistoryStatus >>> >> | +--traceRouteProbeHistorySentTime >>> >> | >>> >> +--traceRouteHopsTable >>> >> | >>> >> +--traceRouteHopsEntry >>> >> | >>> >> +--traceRouteHopsHopIndex >>> >> +--traceRouteHopsIpTgtAddressType >>> >> +--traceRouteHopsIpTgtAddress >>> >> +--traceRouteHopsASNumber >>> >> +--traceRouteHopsMinRtt >>> >> +--traceRouteHopsMaxRtt >>> >> +--traceRouteHopsAverageRtt >>> >> +--traceRouteHopsRttSumOfSquares >>> >> +--traceRouteHopsSentProbes >>> >> +--traceRouteHopsProbeResponses >>> >> >>> >> We believe that most of the fields are self-explaining, for the >>unclear >>> >> ones please refer to the disman draft: >>> >> >>http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2- >>> 06.t >>> >> xt >>> >> >>> >> Looking forward to receive your comments. >>> >> >>> >> Best regards, >>> >> Saverio Niccolini >>> >> >>> >> ============================================================ >>> >> Dr. Saverio Niccolini >>> >> Research Staff Member >>> >> Network Laboratories, NEC Europe Ltd. >>> >> Kurfuerstenanlage 36, D-69115 Heidelberg >>> >> Tel. +49 (0)6221 90511-18 >>> >> Fax: +49 (0)6221 90511-55 >>> >> e-mail: saverio.niccolini@netlab.nec.de >>> >> ============================================================ >>> >> >>> >> >>> >> _______________________________________________ >>> >> ippm mailing list >>> >> ippm@ietf.org >>> >> https://www1.ietf.org/mailman/listinfo/ippm >>> > >>> > _______________________________________________ >>> > ippm mailing list >>> > ippm@ietf.org >>> > https://www1.ietf.org/mailman/listinfo/ippm >>> >>> >>> >> >> >>_______________________________________________ >>ippm mailing list >>ippm@ietf.org >>https://www1.ietf.org/mailman/listinfo/ippm > >------------------------------------------------------------------------------ >Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net >RIPE Network Coordination Centre http://www.amsterdamned.org/~henk >P.O.Box 10096 Singel 258 Phone: +31.20.5354414 >1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 >The Netherlands The Netherlands Mobile: +31.6.55861746 >------------------------------------------------------------------------------ > >Look here junior, don't you be so happy. >And for Heaven's sake, don't you be so sad. (Tom Verlaine) > >_______________________________________________ >ippm mailing list >ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Jan 17 12:57:21 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29116 for ; Mon, 17 Jan 2005 12:57:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqb59-0007sv-UK; Mon, 17 Jan 2005 12:54:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqb1e-0007BF-0y for ippm@megatron.ietf.org; Mon, 17 Jan 2005 12:50:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28477 for ; Mon, 17 Jan 2005 12:50:46 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqbGk-0002OR-5h for ippm@ietf.org; Mon, 17 Jan 2005 13:06:26 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id E5A8322638 for ; Mon, 17 Jan 2005 18:37:03 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] Way to store traceroutes Date: Mon, 17 Jan 2005 18:48:39 +0100 Message-ID: Thread-Topic: [ippm] Way to store traceroutes Thread-Index: AcT8uY4nhKMRxGvGTsmVF62HavaIrwAAvYxQ From: "Saverio Niccolini" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Ok, let's say like this: we agreed that we are not going to write a MIB module but rather to take inspiration from the DISMAN one in order to define a format to store traceroute measurements in the context of the IPPM working group. Best regards, Saverio > -----Original Message----- > From: Andy Bierman [mailto:abierman@cisco.com] > Sent: 17 January 2005 18:25 > To: Henk Uijterwaal > Cc: Saverio Niccolini; disman@ietf.org; ippm@ietf.org > Subject: RE: [ippm] Way to store traceroutes >=20 > At 08:36 AM 1/17/2005, Henk Uijterwaal wrote: > >Saverio, > > > >>By the way, I do not know if the IPPM list agrees on this. > >>Does the IPPM charter want to define a MIB module for traceroute > >>measurements? > > > >Given the lack of interest in the previous MIB we discussed, and > >the lack of expertise to review any proposal, I'd say: NO. >=20 > And since this seems to be an extension to a standard developed in the > DISMAN WG, if this work belongs anywhere in the IETF, it's DISMAN. >=20 > >Henk >=20 > Andy _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Jan 17 13:00:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29414 for ; Mon, 17 Jan 2005 13:00:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqb5A-0007t3-9v; Mon, 17 Jan 2005 12:54:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqb1e-0007BH-Se for ippm@megatron.ietf.org; Mon, 17 Jan 2005 12:50:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28483 for ; Mon, 17 Jan 2005 12:50:47 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqbGk-0002OQ-3y for ippm@ietf.org; Mon, 17 Jan 2005 13:06:27 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id D693922636 for ; Mon, 17 Jan 2005 18:37:03 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] Way to store traceroutes Date: Mon, 17 Jan 2005 18:46:24 +0100 Message-ID: Thread-Topic: [ippm] Way to store traceroutes Thread-Index: AcT6VJfIwYF83lHFQbqjYpaSjh/tBACZ9DMQ From: "Saverio Niccolini" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Yes, I think it is no problem. Saverio > -----Original Message----- > From: Mark Santcroos [mailto:marks@ripe.net] > Sent: 14 January 2005 17:17 > To: Saverio Niccolini > Cc: ippm@ietf.org; Juergen Quittek > Subject: Re: [ippm] Way to store traceroutes >=20 > How about (reserving) a field for geo/location info about each hop? >=20 > Mark >=20 > -- > RIPE NCC - Delft University of Technology - The FreeBSD Project > marks@ripe.net - m.a.santcroos@ewi.tudelft.nl - marks@freebsd.org _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Jan 17 13:08:17 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00159 for ; Mon, 17 Jan 2005 13:08:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqbEc-0000h0-M0; Mon, 17 Jan 2005 13:04:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqb8z-0008Kz-4u for ippm@megatron.ietf.org; Mon, 17 Jan 2005 12:58:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29179 for ; Mon, 17 Jan 2005 12:58:22 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqbO5-0002cO-EQ for ippm@ietf.org; Mon, 17 Jan 2005 13:14:01 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id A3BED22614 for ; Mon, 17 Jan 2005 18:44:39 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] Way to store traceroutes Date: Mon, 17 Jan 2005 18:57:11 +0100 Message-ID: Thread-Topic: [ippm] Way to store traceroutes Thread-Index: AcT6WGHHxcOUln7ZSDm0RSIXj8ivUACZBjlQ From: "Saverio Niccolini" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Stanislav and all, > -----Original Message----- > From: stanislav shalunov [mailto:shalunov@internet2.edu] > Sent: 14 January 2005 17:45 > To: Saverio Niccolini > Cc: ippm@ietf.org; Juergen Quittek > Subject: Re: [ippm] Way to store traceroutes >=20 > Saverio, >=20 > Your object summarizes the data on each hop rather than presenting the > raw list. This has the following problems: >=20 > * Space for only one IP number is provided. What if different queries > with the same TTL elicit replies from different IPs? I agree with you. With our representation we could have some problem if this happens. We have to insert a structure taking care of this. >=20 > * The statistics (such as average RTT, max RTT, and sum of squares of > RTTs) are not robust. This is not in line with the treatment of > delay in other IPPM documents, where percentiles are used. I > believe that in the case of traceroute -- where the amount of data > is small for each hop -- there's no reason to not store the > individual delay, etc., values. Ok. I see. Anyway I am not sure that not storing a summary for the hop itself is a good thing. I would rather add a field for storing the percentile of the delay for being in line with the treatment of delay in other IPPM documents. >=20 > I'd argue for a list of probes for each hop instead of a summary of > the given TTL. If we are defining just a way to dump traceroute results into a file then I completely agree with you. If we are trying to store some more complicated results as the outcome of some more complex summary representing the traceroute history then we need also other fields as we defined. Maybe we can review the record we had in mind to incorporate the two vision (a list of probes for each hop and a summary for each hop). Anyway I would like to ast the list for opinion on this. Any comment? Best regards, Saverio _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Jan 17 13:23:08 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01589 for ; Mon, 17 Jan 2005 13:23:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqbUu-0004lf-1o; Mon, 17 Jan 2005 13:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqbPp-00047E-Bf; Mon, 17 Jan 2005 13:15:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01046; Mon, 17 Jan 2005 13:15:46 -0500 (EST) Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqbev-00035Q-Cf; Mon, 17 Jan 2005 13:31:25 -0500 Received: from mgate1.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id KAA14722; Mon, 17 Jan 2005 10:15:13 -0800 (PST) Received: (from daemon@localhost) by mgate1.riverstonenet.com (8.13.1/8.13.1) id j0HIFCOx001693; Mon, 17 Jan 2005 10:15:12 -0800 (PST) X-Authentication-Warning: mgate1.riverstonenet.com: Processed by daemon with -C /etc/mail/sendmail-simple.cf Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mgate1.riverstonenet.com (8.13.1/8.13.1) with ESMTP id j0HIF9jj001682 for ; Mon, 17 Jan 2005 10:15:10 -0800 (PST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqbJe-0002tV-2q; Mon, 17 Jan 2005 13:09:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqWZA-0001us-Fe; Mon, 17 Jan 2005 08:05:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01913; Mon, 17 Jan 2005 08:05:07 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqWoC-0003fE-TL; Mon, 17 Jan 2005 08:20:42 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 4A4BDD96D; Mon, 17 Jan 2005 13:51:17 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Jan 2005 14:03:42 +0100 Message-ID: Thread-Topic: [ippm] Way to store traceroutes Thread-Index: AcT8elJQiTEyHdb6SZ6YuQ3oIhMxaQAGhuqg From: "Saverio Niccolini" To: "Andy Bierman" X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 X-Mailman-Approved-At: Mon, 17 Jan 2005 13:09:24 -0500 Subject: [Disman] RE: [ippm] Way to store traceroutes X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mgate1.riverstonenet.com id j0HIF9jj001682 X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Content-Transfer-Encoding: 8bit Cc: disman@ietf.org, ippm@ietf.org X-BeenThere: ippm@ietf.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 8bit Hi Andy, the purpose of our draft is to define a file format in order to store traceroute measurements and not a MIB module. The confusion is maybe created by the fact that we just kept the names from the disman draft-RFC in order to facilitate comprehension of the fields itself. By the way, I do not know if the IPPM list agrees on this. Does the IPPM charter want to define a MIB module for traceroute measurements? Best regards, Saverio > -----Original Message----- > From: Juergen Quittek [mailto:quittek@netlab.nec.de] > Sent: 17 January 2005 10:53 > To: Andy Bierman; Saverio Niccolini > Cc: disman@ietf.org; ippm@ietf.org > Subject: RE: [ippm] Way to store traceroutes > > Hi Andy, > > --On 14.01.2005 20:25 Uhr +0100 Andy Bierman wrote: > > > At 07:59 AM 1/14/2005, Saverio Niccolini wrote: > >> Dear all, > >> thanks a lot for your useful suggestions. > > > > This work is already established in the DISMAN WG. See RFC 2925, > > or its update (in progress): > > http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2- > 06.txt > > Saverio and Sandra already had a look at the DISMAN-TRACEROUTE-MIB. > > > I strongly urge you to work with the DISMAN WG to resolve > > perceived deficiencies with the RemOps MIB, rather than > > create a spin-off MIB. > > As editor of draft-ietf-disman-remops-mib-v2-06.txt I wonder > what you consider as 'perceived deficiencies with the RemOps MIB'. > > In the context of IPPM, there is certainly the deficiency, that > you can only store measurements that were performed locally and that > the tables for storing measurement results are read-only. > > But anyway, does the IPPM WG plan to store traceroute results in a MIB? > > Thanks, > > Juergen > -- > Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > http://www.netlab.nec.de > > > > Andy > > > > > > > >> We have tried to draft a "traceroute object" based on what we discussed > >> on the list and what we had in mind. We think this will serve as a > >> starting point of our information model. > >> > >> We have taken the disman draft as a starting point and we have erased > >> some fields not useful in the scope of our draft (that we do not > specify > >> here), moreover we have added and changed other ones: > >> > >> NEW fields: > >> 1) traceRouteResultsLastGoodPathDuration (duration of single running of > >> the last good traceroute path determination) > >> 2) traceRouteResultsLastRun (when the last traceroute with these > >> characteristics was launched) > >> 3) traceRouteHopsASNumber (AS number of the hop) > >> > >> CHANGED fields: > >> 1) traceRouteProbeHistoryTime (timestamp of when the traceroute probe > >> came back) was changed to traceRouteProbeHistorySentTime (timestamp of > >> when the traceroute probe was sent) > >> > >> > >> Please find here how the "traceroute object" looks like right now: > >> > >> --traceRouteObjects > >> | > >> +--traceRouteCtlTable > >> | | > >> | +--traceRouteCtlEntry > >> | | > >> | +--traceRouteCtlOwnerIndex > >> | +--traceRouteCtlTestName > >> | +--traceRouteCtlTargetAddressType > >> | +--traceRouteCtlTargetAddress > >> | +--traceRouteCtlByPassRouteTable > >> | +--traceRouteCtlDataSize > >> | +--traceRouteCtlTimeOut > >> | +--traceRouteCtlProbesPerHop > >> | +--traceRouteCtlPort > >> | +--traceRouteCtlMaxTtl > >> | +--traceRouteCtlDSField > >> | +--traceRouteCtlSourceAddressType > >> | +--traceRouteCtlSourceAddress > >> | +--traceRouteCtlIfIndex > >> | +--traceRouteCtlMiscOptions > >> | +--traceRouteCtlMaxFailures > >> | +--traceRouteCtlDontFragment > >> | +--traceRouteCtlInitialTtl > >> | +--traceRouteCtlDescr > >> | +--traceRouteCtlMaxRows > >> | +--traceRouteCtlCreateHopsEntries > >> | +--traceRouteCtlType > >> | > >> +--traceRouteResultsTable > >> | | > >> | +--traceRouteResultsEntry > >> | | > >> | +--traceRouteResultsOperStatus > >> | +--traceRouteResultsIpTgtAddrType > >> | +--traceRouteResultsIpTgtAddr > >> | +--traceRouteResultsTestAttempts > >> | +--traceRouteResultsTestSuccesses > >> | +--traceRouteResultsLastGoodPath > >> | +--traceRouteResultsLastGoodPathDuration > >> | +--traceRouteResultsLastRun > >> | > >> +--traceRouteProbeHistoryTable > >> | | > >> | +--traceRouteProbeHistoryEntry > >> | | > >> | +--traceRouteProbeHistoryIndex > >> | +--traceRouteProbeHistoryHopIndex > >> | +--traceRouteProbeHistoryProbeIndex > >> | +--traceRouteProbeHistoryHAddrType > >> | +--traceRouteProbeHistoryHAddr > >> | +--traceRouteProbeHistoryResponse > >> | +--traceRouteProbeHistoryStatus > >> | +--traceRouteProbeHistorySentTime > >> | > >> +--traceRouteHopsTable > >> | > >> +--traceRouteHopsEntry > >> | > >> +--traceRouteHopsHopIndex > >> +--traceRouteHopsIpTgtAddressType > >> +--traceRouteHopsIpTgtAddress > >> +--traceRouteHopsASNumber > >> +--traceRouteHopsMinRtt > >> +--traceRouteHopsMaxRtt > >> +--traceRouteHopsAverageRtt > >> +--traceRouteHopsRttSumOfSquares > >> +--traceRouteHopsSentProbes > >> +--traceRouteHopsProbeResponses > >> > >> We believe that most of the fields are self-explaining, for the unclear > >> ones please refer to the disman draft: > >> http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2- > 06.t > >> xt > >> > >> Looking forward to receive your comments. > >> > >> Best regards, > >> Saverio Niccolini > >> > >> ============================================================ > >> Dr. Saverio Niccolini > >> Research Staff Member > >> Network Laboratories, NEC Europe Ltd. > >> Kurfuerstenanlage 36, D-69115 Heidelberg > >> Tel. +49 (0)6221 90511-18 > >> Fax: +49 (0)6221 90511-55 > >> e-mail: saverio.niccolini@netlab.nec.de > >> ============================================================ > >> > >> > >> _______________________________________________ > >> ippm mailing list > >> ippm@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ippm > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www1.ietf.org/mailman/listinfo/ippm > > > _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Jan 17 13:28:35 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02037 for ; Mon, 17 Jan 2005 13:28:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqbUw-0004nE-Py; Mon, 17 Jan 2005 13:21:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqbQn-0004BJ-3s; Mon, 17 Jan 2005 13:16:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01156; Mon, 17 Jan 2005 13:16:45 -0500 (EST) Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqbft-00036x-2X; Mon, 17 Jan 2005 13:32:25 -0500 Received: from mgate1.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id KAA14930; Mon, 17 Jan 2005 10:16:16 -0800 (PST) Received: (from daemon@localhost) by mgate1.riverstonenet.com (8.13.1/8.13.1) id j0HIGGHX001752; Mon, 17 Jan 2005 10:16:16 -0800 (PST) X-Authentication-Warning: mgate1.riverstonenet.com: Processed by daemon with -C /etc/mail/sendmail-simple.cf Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mgate1.riverstonenet.com (8.13.1/8.13.1) with ESMTP id j0HIGFhv001742 for ; Mon, 17 Jan 2005 10:16:16 -0800 (PST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqbJe-0002ti-HA; Mon, 17 Jan 2005 13:09:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZse-0002Hw-AU; Mon, 17 Jan 2005 11:37:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21616; Mon, 17 Jan 2005 11:37:25 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqa7j-0000SL-HA; Mon, 17 Jan 2005 11:53:04 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id B560924F5E; Mon, 17 Jan 2005 17:36:56 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 93DE924F57; Mon, 17 Jan 2005 17:36:55 +0100 (CET) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j0HGasZt017684; Mon, 17 Jan 2005 17:36:55 +0100 Message-Id: <6.2.0.14.2.20050117173544.02bc24b0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 17 Jan 2005 17:36:48 +0100 To: "Saverio Niccolini" , "Andy Bierman" From: Henk Uijterwaal In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000431 / -5.9 X-RIPE-Signature: 63d2c5d4a80ed0dd047f4bf2a33fe854 X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 X-Mailman-Approved-At: Mon, 17 Jan 2005 13:09:24 -0500 Subject: [Disman] RE: [ippm] Way to store traceroutes X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: disman@ietf.org, ippm@ietf.org X-BeenThere: ippm@ietf.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Saverio, >By the way, I do not know if the IPPM list agrees on this. >Does the IPPM charter want to define a MIB module for traceroute >measurements? Given the lack of interest in the previous MIB we discussed, and the lack of expertise to review any proposal, I'd say: NO. Henk >Best regards, >Saverio > > > -----Original Message----- > > From: Juergen Quittek [mailto:quittek@netlab.nec.de] > > Sent: 17 January 2005 10:53 > > To: Andy Bierman; Saverio Niccolini > > Cc: disman@ietf.org; ippm@ietf.org > > Subject: RE: [ippm] Way to store traceroutes > > > > Hi Andy, > > > > --On 14.01.2005 20:25 Uhr +0100 Andy Bierman wrote: > > > > > At 07:59 AM 1/14/2005, Saverio Niccolini wrote: > > >> Dear all, > > >> thanks a lot for your useful suggestions. > > > > > > This work is already established in the DISMAN WG. See RFC 2925, > > > or its update (in progress): > > > http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2- > > 06.txt > > > > Saverio and Sandra already had a look at the DISMAN-TRACEROUTE-MIB. > > > > > I strongly urge you to work with the DISMAN WG to resolve > > > perceived deficiencies with the RemOps MIB, rather than > > > create a spin-off MIB. > > > > As editor of draft-ietf-disman-remops-mib-v2-06.txt I wonder > > what you consider as 'perceived deficiencies with the RemOps MIB'. > > > > In the context of IPPM, there is certainly the deficiency, that > > you can only store measurements that were performed locally and that > > the tables for storing measurement results are read-only. > > > > But anyway, does the IPPM WG plan to store traceroute results in a >MIB? > > > > Thanks, > > > > Juergen > > -- > > Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 >90511-15 > > NEC Europe Ltd., Network Laboratories Fax: +49 6221 >90511-55 > > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > > http://www.netlab.nec.de > > > > > > > Andy > > > > > > > > > > > >> We have tried to draft a "traceroute object" based on what we >discussed > > >> on the list and what we had in mind. We think this will serve as a > > >> starting point of our information model. > > >> > > >> We have taken the disman draft as a starting point and we have >erased > > >> some fields not useful in the scope of our draft (that we do not > > specify > > >> here), moreover we have added and changed other ones: > > >> > > >> NEW fields: > > >> 1) traceRouteResultsLastGoodPathDuration (duration of single >running of > > >> the last good traceroute path determination) > > >> 2) traceRouteResultsLastRun (when the last traceroute with these > > >> characteristics was launched) > > >> 3) traceRouteHopsASNumber (AS number of the hop) > > >> > > >> CHANGED fields: > > >> 1) traceRouteProbeHistoryTime (timestamp of when the traceroute >probe > > >> came back) was changed to traceRouteProbeHistorySentTime (timestamp >of > > >> when the traceroute probe was sent) > > >> > > >> > > >> Please find here how the "traceroute object" looks like right now: > > >> > > >> --traceRouteObjects > > >> | > > >> +--traceRouteCtlTable > > >> | | > > >> | +--traceRouteCtlEntry > > >> | | > > >> | +--traceRouteCtlOwnerIndex > > >> | +--traceRouteCtlTestName > > >> | +--traceRouteCtlTargetAddressType > > >> | +--traceRouteCtlTargetAddress > > >> | +--traceRouteCtlByPassRouteTable > > >> | +--traceRouteCtlDataSize > > >> | +--traceRouteCtlTimeOut > > >> | +--traceRouteCtlProbesPerHop > > >> | +--traceRouteCtlPort > > >> | +--traceRouteCtlMaxTtl > > >> | +--traceRouteCtlDSField > > >> | +--traceRouteCtlSourceAddressType > > >> | +--traceRouteCtlSourceAddress > > >> | +--traceRouteCtlIfIndex > > >> | +--traceRouteCtlMiscOptions > > >> | +--traceRouteCtlMaxFailures > > >> | +--traceRouteCtlDontFragment > > >> | +--traceRouteCtlInitialTtl > > >> | +--traceRouteCtlDescr > > >> | +--traceRouteCtlMaxRows > > >> | +--traceRouteCtlCreateHopsEntries > > >> | +--traceRouteCtlType > > >> | > > >> +--traceRouteResultsTable > > >> | | > > >> | +--traceRouteResultsEntry > > >> | | > > >> | +--traceRouteResultsOperStatus > > >> | +--traceRouteResultsIpTgtAddrType > > >> | +--traceRouteResultsIpTgtAddr > > >> | +--traceRouteResultsTestAttempts > > >> | +--traceRouteResultsTestSuccesses > > >> | +--traceRouteResultsLastGoodPath > > >> | +--traceRouteResultsLastGoodPathDuration > > >> | +--traceRouteResultsLastRun > > >> | > > >> +--traceRouteProbeHistoryTable > > >> | | > > >> | +--traceRouteProbeHistoryEntry > > >> | | > > >> | +--traceRouteProbeHistoryIndex > > >> | +--traceRouteProbeHistoryHopIndex > > >> | +--traceRouteProbeHistoryProbeIndex > > >> | +--traceRouteProbeHistoryHAddrType > > >> | +--traceRouteProbeHistoryHAddr > > >> | +--traceRouteProbeHistoryResponse > > >> | +--traceRouteProbeHistoryStatus > > >> | +--traceRouteProbeHistorySentTime > > >> | > > >> +--traceRouteHopsTable > > >> | > > >> +--traceRouteHopsEntry > > >> | > > >> +--traceRouteHopsHopIndex > > >> +--traceRouteHopsIpTgtAddressType > > >> +--traceRouteHopsIpTgtAddress > > >> +--traceRouteHopsASNumber > > >> +--traceRouteHopsMinRtt > > >> +--traceRouteHopsMaxRtt > > >> +--traceRouteHopsAverageRtt > > >> +--traceRouteHopsRttSumOfSquares > > >> +--traceRouteHopsSentProbes > > >> +--traceRouteHopsProbeResponses > > >> > > >> We believe that most of the fields are self-explaining, for the >unclear > > >> ones please refer to the disman draft: > > >> >http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2- > > 06.t > > >> xt > > >> > > >> Looking forward to receive your comments. > > >> > > >> Best regards, > > >> Saverio Niccolini > > >> > > >> ============================================================ > > >> Dr. Saverio Niccolini > > >> Research Staff Member > > >> Network Laboratories, NEC Europe Ltd. > > >> Kurfuerstenanlage 36, D-69115 Heidelberg > > >> Tel. +49 (0)6221 90511-18 > > >> Fax: +49 (0)6221 90511-55 > > >> e-mail: saverio.niccolini@netlab.nec.de > > >> ============================================================ > > >> > > >> > > >> _______________________________________________ > > >> ippm mailing list > > >> ippm@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/ippm > > > > > > _______________________________________________ > > > ippm mailing list > > > ippm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ippm > > > > > > > > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www1.ietf.org/mailman/listinfo/ippm ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Jan 17 15:23:31 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11098 for ; Mon, 17 Jan 2005 15:23:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqdMc-0004iq-IM; Mon, 17 Jan 2005 15:20:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqdKe-00042W-5n for ippm@megatron.ietf.org; Mon, 17 Jan 2005 15:18:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10590 for ; Mon, 17 Jan 2005 15:18:33 -0500 (EST) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqdZj-0005yy-UV for ippm@ietf.org; Mon, 17 Jan 2005 15:34:13 -0500 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id E75E61CD956; Mon, 17 Jan 2005 15:18:30 -0500 (EST) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09961-02; Mon, 17 Jan 2005 15:18:30 -0500 (EST) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 9F6DD1CD946; Mon, 17 Jan 2005 15:18:30 -0500 (EST) To: "Saverio Niccolini" Subject: Re: [ippm] Way to store traceroutes References: From: stanislav shalunov Date: 17 Jan 2005 15:18:28 -0500 In-Reply-To: Message-ID: <867jmbg67f.fsf@abel.internet2.edu> Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org "Saverio Niccolini" writes: > Maybe we can review the record we had in mind to incorporate the two > vision (a list of probes for each hop and a summary for each hop). I think it could be OK to store both the individual results and a summary for each hop (even if I'd prefer simply the dump of the raw data). Could you perhaps explain where it would be useful to have a standard format for both a summary and a list of individual replies for a given TTL? (This is an honest question; I really can't see any real scenarios where such a standard format would come in handy. OK, here's one [not real]: one constantly runs traceroute in a full mesh of 100 nodes with 10000 probes per TTL and accumulates a huge database over the course of 10 years; then this database needs to be shared with a different organization for the purposes of analysis. This is a really strained example, because the amount of data per hop is so large.) -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at room temperature. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Jan 18 05:39:53 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10611 for ; Tue, 18 Jan 2005 05:39:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqqiE-0005Ob-4F; Tue, 18 Jan 2005 05:35:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqqWs-0003dY-Va; Tue, 18 Jan 2005 05:24:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09649; Tue, 18 Jan 2005 05:24:04 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqqm5-0003qh-Vi; Tue, 18 Jan 2005 05:39:52 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 658B825529; Tue, 18 Jan 2005 11:23:31 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 69176254DC; Tue, 18 Jan 2005 11:23:29 +0100 (CET) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j0IANSeu021821; Tue, 18 Jan 2005 11:23:29 +0100 Message-Id: <6.2.0.14.2.20050118111153.02bd3550@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 18 Jan 2005 11:23:28 +0100 To: stanislav shalunov , ippm@ietf.org, mankin@psg.com, jon.peterson@neustar.biz, iesg@ietf.org From: Henk Uijterwaal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000049 / -5.9 X-RIPE-Signature: f19bde31f499e7efa6a70cd2e73f0d76 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Tue, 18 Jan 2005 05:35:49 -0500 Subject: [ippm] Request to advance draft-ietf-ippm-owdp-14.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Allison, Jon, The IPPM WG would like to submit draft-ietf-ippm-owdp-14.txt for consideration as an RFC by the IESG. This draft has been extensively discussed in the WG for the last 3 years, the latest draft includes all issues that were raised over the last year. A WG LC has been done and no issues were raised. Henk ps. Please let me know if I have to send this anywhere else other than the two of you. This is the first time I'm doing this :-) ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From XBFTILVOD@oedp.de Wed Jan 19 19:46:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14322; Wed, 19 Jan 2005 19:46:34 -0500 (EST) Received: from cablep-179-173-113.cablep.bezeqint.net ([212.179.173.113]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CrQiW-0004Lu-OM; Wed, 19 Jan 2005 20:02:43 -0500 Received: from currant [118.199.21.109] (helo=belshazzar.adverse.dearriba.com) by smtp2.cistron.nl with esmtp (daylight 3.35 #1 (dapper)) id 476LFL-0057PT-78 Message-ID: <81958703144732.R37449@abscess.noc.wallaby.gr> Sender: freeradius-devel-XBFTILVOD@oedp.de X-Mailman-Version: 2.0.1 Date: Wed, 19 Jan 2005 18:49:07 -0600 From: "Lyman Calvert" To: ippm-archive@ietf.org Subject: stop paying thousands for meds Billy X-Spam-Score: 5.7 (+++++) X-Spam-Flag: YES X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Offshore pharm wish you all best in New Year! We will offer you best prices on any meds you need Via gra Cia 1is Va1 ium Xan ax and much more.. Please click below and check out our offer. http://erode.getitquickly2.biz/?wid=100069 multitude travelogue swish tyler contradictory volume chase belvidere rheum prospector erwin kennecott riffle spit cohen negligee eighty bowfin bloodstain seclusion cigar desk archae clipboard bonito regrettable jawbreak abstruse adrienne zigging shingle defrock ta perchlorate divulge matins malpractice dedicate laue euphorbia innate tricky troglodyte larch absent octogenarian pretty rebut fisk naivete downs hydro mildew belittle http://ad.getitquickly2.biz/nomore.html From qswdzcj@yahoo.com Wed Jan 19 22:32:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26715; Wed, 19 Jan 2005 22:32:28 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrTJD-0008Mg-1T; Wed, 19 Jan 2005 22:48:35 -0500 Received: from [80.112.229.7] (helo=TILBURG-58QA2I2) by mx2.foretec.com with smtp (Exim 4.24) id 1CrT3K-00039e-Ex; Wed, 19 Jan 2005 22:32:11 -0500 Received: from blimp [92.4.8.0] (helo=erasure.galapagos.dearriba.com) by smtp2.cistron.nl with esmtp (calcify 3.35 #1 (seduce)) id 582LFL-0050PT-29 Message-ID: <74515983144732.R37482@assurance.noc.amalgam.gr> Sender: freeradius-devel-qswdzcj@yahoo.com X-Mailman-Version: 2.0.1 Date: Thu, 20 Jan 2005 00:31:58 -0300 From: "Elisabeth Land" To: ipoverib-admin@ietf.org Subject: Viic0din for 0nly $90 XAsz X-Spam-Score: 2.7 (++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Huge offer for Viicodin, Viagraa, Vallium and lots moreee... savee up to 7o% meds on our stores. Visit uss today http://uhviagra.info/in.php?aid=56 This is 1 -time mailing. N0-re m0val are re'qui-red U2TN1bxtb70vd0pHKJ8p1ndFLBrayx5P8l3cxlIfN1UvUeMwRFsEjThXt From ippm-bounces@ietf.org Thu Jan 20 13:44:03 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23500 for ; Thu, 20 Jan 2005 13:44:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrhBW-0007z9-8o; Thu, 20 Jan 2005 13:37:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crh21-0005xl-Us for ippm@megatron.ietf.org; Thu, 20 Jan 2005 13:27:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22446 for ; Thu, 20 Jan 2005 13:27:42 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrhHh-0006BL-F3 for ippm@ietf.org; Thu, 20 Jan 2005 13:44:01 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Jan 2005 19:27:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Jan 2005 19:27:17 +0100 Message-ID: Thread-Topic: 'IPPM' IDs on multicast an spatial measure Thread-Index: AcT/HavCg1QX8wx/S8KyvH8U88/ELQ== From: "STEPHAN Emile RD-CORE-LAN" To: X-OriginalArrivalTime: 20 Jan 2005 18:27:18.0217 (UTC) FILETIME=[AC3F2390:01C4FF1D] X-Spam-Score: 0.1 (/) X-Scan-Signature: 916029c14bdb340aa234d3ec4cd24f52 Cc: Henk Uijterwaal , Matthew J Zekauskas Subject: [ippm] 'IPPM' IDs on multicast an spatial measure X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0871442641==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org This is a multi-part message in MIME format. --===============0871442641== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FF1D.AC00529C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4FF1D.AC00529C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear All During the last WG meeting Matt asked me to reread the draft draft-liang-multiparty-para-00.txt while considering the previous IDs I posted on spatial and multicast metrics. I reread them. Following is the list of metrics I found. I can make further classifications, comparisons or comments if needed. Regards Emile --------------- draft-stephan-ippm-multicast-metrics-00.txt ---------------- The draft defines 1 network metrics: + Type-P-spatial-hop-one-way-delay =09 The draft defines several aggregation metrics: + Type-P-spatial-one-way-delay-stream + Type-P-spatial-one-way-delay=09 + Type-P-Multicast-Instantaneous-Hop-One-way-Delay=20 + Type-P-Multicast-Instantaneous-One-way-Delay-Percentile=20 + Type-P-Multicast-Instantaneous-One-way-Delay-Median=20 + Type-P-Multicast-Instantaneous-One-way-Delay-Inverse Percentile=20 + Type-P-Multicast-Instantaneous-Packet-Loss-Stream + Type-P-Multicast-Instantaneous-Packet-Loss-Percentile=20 + Type-P-Multicast-Instantaneous-Packet-Loss-Median=20 + Type-P-Multicast-Instantaneous-Packet-Loss-Inverse Percentile + Type-P-Multicast-Instantaneous-Connectivity =20 --------------- draft-stephan-ippm-spatial-metrics-01.txt ---------------=20 =20 The draft defines 2 network metrics: + Type-P-spatial-one-way-delay + Type-P-Spatial-packet-loss=20 =09 The draft defines several path aggregation metrics : + Type-P-one-way-delay-trajectory =20 + Type-P-aggregated-one-way-delay =20 + Type-P-asynchronous-one-way-delay-trajectory + Type-P-asynchronous-aggregated-one-way-delay + Type-P-Spatial-packet-loss-stream =20 + Type-P-Spatial-packet-loss-Average =09 --------------- draft-liang-multiparty-para-00.txt ---------------=20 The draft defines statistics for end to end multicast performance, mainly to identify the variation of the performance between the member of a group. Actually the draft has 4 groups of statistics metrics: One-to-group-Mean-Paramater One-to-group-Variation-Paramater Group-to-one-Mean-Paramater Group-to-one-Variation-Paramater=20 The value of Parameter depends on what one-way metric is used from delay, loss ot jitter. =20 To permit comparison I extended the list of metrics defined using IPPM metrics terminology: + Type-P-One-to-group-Mean-one-way-delay; + Type-P-One-to-group-Mean-Packet-Loss; + Type-P-One-to-group-Mean-ipdv; =09 + Type-P-One-to-group-Variation-one-way-delay; + Type-P-One-to-group-Variation-Packet-Loss; + Type-P-One-to-group-Variation-ipdv; =20 + Type-P-Group-to-one-Mean-one-way-delay; + Type-P-Group-to-one-Mean-Packet-Loss; + Type-P-Group-to-one-Mean-ipdv; =09 + Type-P-Group-to-one-Variation-one-way-delay; + Type-P-Group-to-one-Variation-Packet-Loss; + Type-P-Group-to-one-Variation-ipdv; ------_=_NextPart_001_01C4FF1D.AC00529C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable 'IPPM' IDs on multicast an spatial measure

Dear = All

During the last WG meeting Matt = asked me to = reread the draft draft-liang-multiparty-para-00.txt while = considering the previous IDs I = posted on spatial and multicast metrics.

I reread = them. Following = is the = list of metrics I found. I can make further classifications, comparisons or comments if = needed.

Regards

Emile

--------------- = draft-stephan-ippm-multicast-metrics-00.txt = ----------------

The = draft defines 1 network metrics:

        + Type-P-spatial-hop-one-way-delay

       

The = draft defines several aggregation metrics:

        + Type-P-spatial-one-way-delay-stream

        + Type-P-spatial-one-way-delay 

        + = Type-P-Multicast-Instantaneous-Hop-One-way-Delay

        + = Type-P-Multicast-Instantaneous-One-way-Delay-Percentile =

        + = Type-P-Multicast-Instantaneous-One-way-Delay-Median

        + = Type-P-Multicast-Instantaneous-One-way-Delay-Inverse Percentile =

        + = Type-P-Multicast-Instantaneous-Packet-Loss-Stream

        + Type-P-Multicast-Instantaneous-Packet-Loss-Percentile =

        + Type-P-Multicast-Instantaneous-Packet-Loss-Median =

        + Type-P-Multicast-Instantaneous-Packet-Loss-Inverse = Percentile

        + = Type-P-Multicast-Instantaneous-Connectivity

  

--------------- draft-stephan-ippm-spatial-metrics-01.txt = ---------------

  

The = draft defines 2 network metrics:

        + Type-P-spatial-one-way-delay

        + Type-P-Spatial-packet-loss

       

The = draft defines several = path aggregation metrics = :

        + Type-P-one-way-delay-trajectory  =

        + Type-P-aggregated-one-way-delay  =

        + = Type-P-asynchronous-one-way-delay-trajectory

        + = Type-P-asynchronous-aggregated-one-way-delay

        + Type-P-Spatial-packet-loss-stream 

        + Type-P-Spatial-packet-loss-Average

       

--------------- draft-liang-multiparty-para-00.txt = ---------------

The = draft defines statistics for end to end multicast = performance, mainly to identify the variation of the performance = between the member of a group.

Actually the draft has 4 groups of statistics = metrics:

        One-to-group-Mean-Paramater

        One-to-group-Variation-Paramater

        Group-to-one-Mean-Paramater

        Group-to-one-Variation-Paramater

The = value of Parameter depends on what one-way metric is used from delay, = loss ot jitter.  

To = permit = comparison I extended the = list of metrics = defined using IPPM metrics = terminology:

        + = Type-P-One-to-group-Mean-one-way-delay;

        + Type-P-One-to-group-Mean-Packet-Loss;

        + Type-P-One-to-group-Mean-ipdv;

       

        + = Type-P-One-to-group-Variation-one-way-delay;

        + = Type-P-One-to-group-Variation-Packet-Loss;

        + Type-P-One-to-group-Variation-ipdv;

 

        + = Type-P-Group-to-one-Mean-one-way-delay;

        + Type-P-Group-to-one-Mean-Packet-Loss;

        + Type-P-Group-to-one-Mean-ipdv;

       

        + = Type-P-Group-to-one-Variation-one-way-delay;

        + = Type-P-Group-to-one-Variation-Packet-Loss;

        + Type-P-Group-to-one-Variation-ipdv;

------_=_NextPart_001_01C4FF1D.AC00529C-- --===============0871442641== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============0871442641==-- From ippm-bounces@ietf.org Fri Jan 21 09:50:42 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16081 for ; Fri, 21 Jan 2005 09:50:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crzxb-00026j-AG; Fri, 21 Jan 2005 09:40:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrztQ-0000f7-W3 for ippm@megatron.ietf.org; Fri, 21 Jan 2005 09:36:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14534 for ; Fri, 21 Jan 2005 09:36:07 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs09J-000510-Mi for ippm@ietf.org; Fri, 21 Jan 2005 09:52:35 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id B71982289E; Fri, 21 Jan 2005 15:23:18 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] Way to store traceroutes Date: Fri, 21 Jan 2005 15:31:17 +0100 Message-ID: Thread-Topic: [ippm] Way to store traceroutes Thread-Index: AcT80ojL0Y3VVIRtTMSM/xaQMmBBywC76yLe From: "Sandra Tartarelli" To: "stanislav shalunov" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Dear Stanislav, =20 from your (and others') comments, it seems to us that what we are trying = to define here is a file format (rather than some data structures). In = this case, we agree that we can omit storing per hop summaries. =20 We are also fine with storing simply the dump of the raw data, but we = would like to receive some more comments on this from the IPPM list. =20 If there's a general agreement on storing the raw data, then we will = revise our initial proposal accordingly and submit it to the list again. =20 Regards, Sandra =20 ________________________________ From: ippm-bounces@ietf.org on behalf of stanislav shalunov Sent: Mon 1/17/2005 9:18 PM To: Saverio Niccolini Cc: ippm@ietf.org Subject: Re: [ippm] Way to store traceroutes "Saverio Niccolini" writes: > Maybe we can review the record we had in mind to incorporate the two > vision (a list of probes for each hop and a summary for each hop). I think it could be OK to store both the individual results and a summary for each hop (even if I'd prefer simply the dump of the raw data). Could you perhaps explain where it would be useful to have a standard format for both a summary and a list of individual replies for a given TTL? (This is an honest question; I really can't see any real scenarios where such a standard format would come in handy. OK, here's one [not real]: one constantly runs traceroute in a full mesh of 100 nodes with 10000 probes per TTL and accumulates a huge database over the course of 10 years; then this database needs to be shared with a different organization for the purposes of analysis. This is a really strained example, because the amount of data per hop is so large.) -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at room temperature. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --- Dr. Sandra Tartarelli Network Laboratories NEC Europe Ltd. Kurf=FCrsten-Anlage 36 D-69115 Heidelberg, Germany Phone: +49 (0)6221 90511-32 Fax: +49 (0)6221 90511-55 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Jan 21 11:55:46 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27056 for ; Fri, 21 Jan 2005 11:55:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1yk-0004bi-Pw; Fri, 21 Jan 2005 11:49:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1xC-0004Hf-Rc for ippm@megatron.ietf.org; Fri, 21 Jan 2005 11:48:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26123 for ; Fri, 21 Jan 2005 11:48:08 -0500 (EST) Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2D5-0000po-RP for ippm@ietf.org; Fri, 21 Jan 2005 12:04:38 -0500 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 835571CD870; Fri, 21 Jan 2005 11:48:07 -0500 (EST) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01945-05; Fri, 21 Jan 2005 11:48:07 -0500 (EST) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 3C7621CD6CB; Fri, 21 Jan 2005 11:48:07 -0500 (EST) To: "Sandra Tartarelli" Subject: Re: [ippm] Way to store traceroutes References: From: stanislav shalunov Date: 21 Jan 2005 11:48:06 -0500 In-Reply-To: Message-ID: <86ekgepw3d.fsf@abel.internet2.edu> Lines: 29 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org "Sandra Tartarelli" writes: > from your (and others') comments, it seems to us that what we are > trying to define here is a file format Note that the subject line says ``Way to store traceroutes''. That's what the question was asked about. > (rather than some data structures). I think it's both, but there can be working things that one might use in a real implementation that need no standardization. For example, you might store the time it took you to read the file so far, but there's no need to standardize format for that. Or, you might store a ring of last 1024 traceroutes, but there's no need to define precisely how that ring should be organized. The standardized data structure would benefit from having per-hop summaries only if the amount of per-hop data is large. Traditionally, traceroute uses three packets per hop. Storing their actual delays seems like a better deal than storing the median, some interquintile distance, and minimum. Even if the sample is has a size of 5 or some other small number, why would one even want these statistics stored instead of the actual data? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at room temperature. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Jan 21 14:28:42 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08210 for ; Fri, 21 Jan 2005 14:28:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs4JE-0004bn-Kv; Fri, 21 Jan 2005 14:19:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs4Ia-0004M8-Bv; Fri, 21 Jan 2005 14:18:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07407; Fri, 21 Jan 2005 14:18:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs4YV-000535-Sa; Fri, 21 Jan 2005 14:34:53 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1Cs4CI-00033R-Vi; Fri, 21 Jan 2005 14:11:54 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 21 Jan 2005 14:11:54 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ippm@ietf.org Subject: [ippm] Last Call: 'IP Performance Metrics (IPPM) metrics registry' to BCP X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org The IESG has received a request from the IP Performance Metrics WG to consider the following document: - 'IP Performance Metrics (IPPM) metrics registry ' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-02-04. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ippm-metrics-registry-08.txt _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From GVOIDEBYPFZ@globaldist.com Sat Jan 22 02:55:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15193; Sat, 22 Jan 2005 02:55:45 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsGNY-0007QV-PB; Sat, 22 Jan 2005 03:12:22 -0500 Received: from [61.83.83.103] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CsGHP-0002FR-Nb; Sat, 22 Jan 2005 03:06:01 -0500 Received: from liechtenstein.anu.calypso.au ([216.4.112.37] helo=anu.ciceronian.au) by smtp9.asphalt.co with esmtp id 1A5Ys6-534182-78 Message-ID: Sender: freeradius-devel-GVOIDEBYPFZ@globaldist.com X-Mailman-Version: 2.0.1 Date: Sat, 22 Jan 2005 13:56:06 +0600 From: "Booker Whittaker" To: proceedings@ietf.org Subject: don`t be an asshole Millicent X-Spam-Score: 10.4 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Offshore pharm wish you all best in New Year! We will offer you best prices on any meds you need Via gra Cia 1is Va1 ium Xan ax and much more.. Please click below and check out our offer. http://sedge.getitquickly2.biz/?wid=100069 cartesian bunsen alcoholism designate chock wrapup radiochemistry connivance ecclesiastic breadroot blum few liverpool clove avocado glycine acclimate cosine gaugeable arena abort sedulous urea valediction confocal canton quasar whichever degrease toiletry kiva design caught transcribe cryptanalyst ineducable topmost offbeat diacritic chemisorb jig bitten sidelight utopian deliquesce bisect cloture visa diverse meadowsweet irresponsible swipe concentric latin http://arianism.getitquickly2.biz/nomore.html From ippm-bounces@ietf.org Mon Jan 24 07:52:49 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04013 for ; Mon, 24 Jan 2005 07:52:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct3g2-0000B4-MR; Mon, 24 Jan 2005 07:50:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct3db-0008MN-DM for ippm@megatron.ietf.org; Mon, 24 Jan 2005 07:48:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03793 for ; Mon, 24 Jan 2005 07:48:09 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct3u5-0001eL-NO for ippm@ietf.org; Mon, 24 Jan 2005 08:05:15 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C11BB228D2; Mon, 24 Jan 2005 13:36:03 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ippm] Way to store traceroutes Date: Mon, 24 Jan 2005 13:47:05 +0100 Message-ID: Thread-Topic: [ippm] Way to store traceroutes Thread-Index: AcT/2P1jndfc04beTQ+6u0I7UHCnJACGtoFg From: "Sandra Tartarelli" To: "stanislav shalunov" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Stanislav, > The standardized data structure would benefit from having per-hop > summaries only if the amount of per-hop data is large. Traditionally, > traceroute uses three packets per hop. Storing their actual delays > seems like a better deal than storing the median, some interquintile > distance, and minimum. Even if the sample is has a size of 5 or some > other small number, why would one even want these statistics stored > instead of the actual data? There seems to be a misunderstanding on this point. We assume that for instance a network administrator might want to repeat at different times (over days, weeks, months....) the same traceroute (i.e. with the same parameters) to a certain destination.=20 Given this, when we talk about per-hop summaries (e.g. average_RTT), we mean a summary for all probes sent in the past to the same destination and with the same parameters and not a summary for the three (or any other number of) probes of the last run.=20 The idea behind such a summary is to have an immediate comparison of the current with the past network conditions, to detect possible changes. Sandra =20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Jan 25 17:20:20 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19961 for ; Tue, 25 Jan 2005 17:20:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtYsn-0007do-Mb; Tue, 25 Jan 2005 17:09:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtYcq-0006mb-Li for ippm@megatron.ietf.org; Tue, 25 Jan 2005 16:53:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14366 for ; Tue, 25 Jan 2005 16:53:26 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtYtd-0002Ud-C6 for ippm@ietf.org; Tue, 25 Jan 2005 17:10:49 -0500 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id j0PLrQ1x063918 for ; Tue, 25 Jan 2005 13:53:26 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 6E66677AB67 for ; Tue, 25 Jan 2005 16:53:24 -0500 (EST) To: ippm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Fat Bottom Girls MIME-Version: 1.0 Date: Tue, 25 Jan 2005 16:53:24 -0500 Message-Id: <20050125215324.6E66677AB67@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Subject: [ippm] thoughts on reordering draft (-08) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1368597139==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --===============1368597139== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Folks- I read through the reordering i-d again today and have some comments (to followup my comments from November). Some of them are small, some less small. Section 2: * I'd really like to see the word "successfully" removed from the first sentence. It's just confusing, IMO. * Second sentence: "Internet Protocol" --> "The Internet Protocol" * "other protocols" --> "protocols at higher layers of the stack than IP" Section 2.2: * I like point #2, but I think it could be made a bit more crisp. Something like: We define a number of methods for quantifying reordering because various applications are impacted by packet reordering in different ways and the characteristics of the metric must be well matched with the application's behavior. (Or, something a little more like that than what's in the document.) * I still don't like the "relevance to TCP" bullet. (More below.) Section 3.2: * This just doesn't look like it was buffed to talk about only message numbers (and not bytes or time). E.g., the definition of NextExp is bogus. And, it would seem as if SrcByte and PayloadSize and SrcTime should be noted as optional. Section 3.4: * I'd like to see a small note that indicates that loss and reordering cannot be completely untangled without observing the packets at each hop along the path. E.g., a packet could be reordered and then lost. I don't think there is really much one can do about this, but I think it should be explicitly called out so that people are aware of this form of skewing. Section 4: * This entire section needs a scrubbing. The section is pretty haphazard in its definitions. Some definitions are pretty informal (like the ratio) and some are very formal (like the extent) - forgetting all about the notation developed in the previous section and some definitions are given in pseudo-code (reordering free run). Sometimes we see s[i] and sometimes s(i). Etc., etc. It looks like this was written by committee. I'd suggest that one person takes a pass at this section and makes it a bit more uniform and a bit easier for the reader to follow. Section 4.2.4: * "A receiver must possess storage to restore order to packets that are reordered." I think this needs tamed a bit. *IF* an application cares to keep all data in order they need buffer. But, late packets might be as good as lost. Section 4.3: * One could argue for or wonder about interpolation here. I.e., if I see 1,10,5 then the amount of lateness is really not quite right as measured from either of the known arrivals. I would think a note would at least be in order here --- if not thinking about trying to add a little cleverness. Section 4.6.4: * I am not sure I would consider this a discussion. It's more of an example. Section 5: * Well, I still really think this section is sort of bogus. It's not as bogus as in the last version since requiring BTC. But, the document basically argues that this is important for a couple of reasons. First, because it will help us "[determine] the portion of reordered packets that can or cannot be restored to order in a typical TCP receiver buffer based on their arrival order alone". But, since we require BTC the sending is all window-based. We can certainly tell if the reordering puzzles itself out within that window. But, we cannot tell how big the window would need to be to disambiguate things because we don't have such a window. I am pretty skeptical that there is a solid inference algorithm you could use, but the document needs that algorithm if its going to make this claim because otherwise it's a big damn handwave. And, what's more we don't need n-reordering to tell this. We just have to look at the BTC stream and figure it out. Second, the document says that by looking at n=3 reordering we can figure out how often we needlessly trigger fast retransmit. However, BTC can measure this directly because it *will* botch fast retransmit. All we have to do is to count the number of times we botch fast retransmit. We don't need the reordering algorithm to get this information. I basically buy neither of these. Below I provide something I do buy in this space. * The document notes that n-reordering is nice because it's less complicated than a TCP. But, once you layer it on top of BTC (which is necessary) I don't think it is much less complicated. I'd remove this statement. * "For n=3..." the document should cite RFC2581 (about halving the cwnd and the three duplicate ACKs). NewReno also uses three duplicate ACKs, but the definition comes from the base CC spec. I'd also note that n=3 is the "magic number" for SCTP and DCCP, as well. * In this space I would buy one application of n-reordering. I think it'd be fine to rip out the explanation that is there and leave one thing. The one thing is that it'd be nice to assess the duplicate ACK threshold that would have kept the TCP from spuriously retransmitting. E.g., if we see no n=6 reordering events, but lots of n=1--5 events then n=6 seems like the magic number. This, in some sense, gives an idea about how far the path is "off" from being able to stay out of TCP's way. Section 6: * I don't buy the notion that test packets should be emitted as fast as possible to catch reordering to the "greatest extent". I would very much rather the document advocated sending in a pattern as similar to the particular application one cares about as possible. Measuring reordering to the greatest extent possible by sending every millisecond doesn't really help dimension buffers in an app that sends every 10msec. I don't think the goal should be some somehow "catch" reordering, but rather to accurately assess reordering in a situation someone cares about. * This section also has some old artifacts about clocks and bytes that are no longer required. * I like the note that with TCP one could use time to help disambiguate reordering and retransmits. I would suggest mention the TCP timestamp option and citing it (RFC1323). * Again, "some in-order packet arrivals may not be useful to TCP" is bogus in the context of using a BTC stream to measure reordering. Overall, I think it's getting better. Good work! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFB9r/UWyrrWs4yIs4RAhp0AKCeOnIl0n+3+UOBWWKzjguZC5rF4ACdH8rf CQbeYPqY5NzhKyCRbNeeF3Y= =ZILM -----END PGP SIGNATURE----- --=-=-=-- --===============1368597139== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============1368597139==-- From ippm-bounces@ietf.org Wed Jan 26 03:49:03 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01875 for ; Wed, 26 Jan 2005 03:49:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctip3-0007Gg-Up; Wed, 26 Jan 2005 03:46:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctijz-0005uQ-AC for ippm@megatron.ietf.org; Wed, 26 Jan 2005 03:41:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01391 for ; Wed, 26 Jan 2005 03:41:28 -0500 (EST) Received: from rose.man.poznan.pl ([150.254.173.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctj0p-0005sX-NF for ippm@ietf.org; Wed, 26 Jan 2005 03:58:57 -0500 Received: from [150.254.160.189] ([150.254.160.189]) (authenticated bits=0) by rose.man.poznan.pl (8.12.10/8.12.10/auth/ldap/milter/tls) with ESMTP id j0Q8emOd009859; Wed, 26 Jan 2005 09:40:50 +0100 (CET) Message-ID: <41F75793.4060405@man.poznan.pl> Date: Wed, 26 Jan 2005 09:40:51 +0100 From: =?ISO-8859-2?Q?Micha=B3_Przybylski?= Organization: PSNC User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: pl, en-us, en MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [ippm] thoughts on reordering draft (-08) References: <20050125215324.6E66677AB67@guns.icir.org> In-Reply-To: <20050125215324.6E66677AB67@guns.icir.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by PSNC antivirus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear Mark, Let me just add one answer to your comment: > Section 6: > > * I don't buy the notion that test packets should be emitted as fast > as possible to catch reordering to the "greatest extent". I would > very much rather the document advocated sending in a pattern as > similar to the particular application one cares about as possible. > Measuring reordering to the greatest extent possible by sending > every millisecond doesn't really help dimension buffers in an app > that sends every 10msec. I don't think the goal should be some > somehow "catch" reordering, but rather to accurately assess > reordering in a situation someone cares about. This is the comment resulting from our practical study. I understand that for the particular application *reordering buffer tuning* one would want to simulate an application stream (we have tested this as well and it helps a lot). On the other hand the "line speed" sending helps to reveal many sources of reordering that would probably not influence this application, but may have impact on another, for example faster. This is especially useful for estimating the reordering for highly demanding applications, such as those of HEP or VLBI, using >1Gbit/s datastreams. It allows to have some insight into future network use, providing the information on "what is the worst reordering scenario that may happen to me?". So this is not intended to dimension reordering buffers but to establish the "reordering fingerprint" of the network, which helps to understand how to use it with future applications. Regards, Michal -- ______________________________________________________________________ Michal Przybylski Network Research and Development michalp@man.poznan.pl Poznan Supercomputing and Networking Center +48 61 858 20 27 http://www.man.poznan.pl ______________________________________________________________________ _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Jan 26 09:12:28 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26554 for ; Wed, 26 Jan 2005 09:12:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtnoR-0006aB-Od; Wed, 26 Jan 2005 09:06:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtngX-0004U9-G3 for ippm@megatron.ietf.org; Wed, 26 Jan 2005 08:58:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25325 for ; Wed, 26 Jan 2005 08:58:15 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtnxS-00073B-1l for ippm@ietf.org; Wed, 26 Jan 2005 09:15:47 -0500 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id j0QDwD1x075069; Wed, 26 Jan 2005 05:58:13 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id B11DC77ABAF; Wed, 26 Jan 2005 08:58:12 -0500 (EST) To: =?ISO-8859-2?Q?Micha=B3_Przybylski?= From: Mark Allman Subject: Re: [ippm] thoughts on reordering draft (-08) In-Reply-To: <41F75793.4060405@man.poznan.pl> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Dance the Night Away MIME-Version: 1.0 Date: Wed, 26 Jan 2005 08:58:12 -0500 Message-Id: <20050126135812.B11DC77ABAF@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0194803550==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --===============0194803550== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain > So this is not intended to dimension reordering buffers but to > establish the "reordering fingerprint" of the network, which helps to > understand how to use it with future applications. I am not sure I buy all of this. Determining a worst case reordering may, indeed, have some benefit. But, there is also cost. What I don't buy is that one could somehow easily extrapolate how some other app would work based on such a test. I think I would like to see more explanation of this in the document. I.e., * Not a recommendation to send as fast as possible. One could offer that as a possibility to stress test a path. And, certainly that could help tease out all the reordering that a path is capable of. However, you have to be pretty careful here because I don't think we want to advocate blasting test streams across the big-I Internet at arbitrarily high rates. And, we want the reader to understand that such a sending pattern is not terribly acceptable. So, it seems to me this is sort of thorny. * A clear recommendation that says that to gauge reordering for any particular application the best way to do that is to send using the same pattern as that application. E.g., using a BCP scheme for assessing how reordering impacts bulk FTP transfers. Or, a periodic sending rate that mirrors real-time apps. Or, whatever. Basically, it's better to *measure* than to try to *infer* because inference is really, really difficult to get right. Thanks! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFB96H0WyrrWs4yIs4RAqAmAJ9P0F5RPbWwZkHJjeUNavmlnLyIYwCeNurK wvY8Ql5KKh+JyEmv86x9+jU= =uq+c -----END PGP SIGNATURE----- --=-=-=-- --===============0194803550== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============0194803550==-- From ippm-bounces@ietf.org Wed Jan 26 09:34:22 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29156 for ; Wed, 26 Jan 2005 09:34:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cto2e-0001v9-IA; Wed, 26 Jan 2005 09:21:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctnv8-0008GH-Cq for ippm@megatron.ietf.org; Wed, 26 Jan 2005 09:13:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26622 for ; Wed, 26 Jan 2005 09:13:20 -0500 (EST) Received: from rose.man.poznan.pl ([150.254.173.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtoC2-0007SL-Oe for ippm@ietf.org; Wed, 26 Jan 2005 09:30:52 -0500 Received: from [150.254.160.189] ([150.254.160.189]) (authenticated bits=0) by rose.man.poznan.pl (8.12.10/8.12.10/auth/ldap/milter/tls) with ESMTP id j0QECeOd028584; Wed, 26 Jan 2005 15:12:41 +0100 (CET) Message-ID: <41F7A55B.1090909@man.poznan.pl> Date: Wed, 26 Jan 2005 15:12:43 +0100 From: =?ISO-8859-2?Q?Micha=B3_Przybylski?= Organization: PSNC User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: pl, en-us, en MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [ippm] thoughts on reordering draft (-08) References: <20050126135812.B11DC77ABAF@guns.icir.org> In-Reply-To: <20050126135812.B11DC77ABAF@guns.icir.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by PSNC antivirus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Content-Transfer-Encoding: 7bit > I don't think we > want to advocate blasting test streams across the big-I Internet at > arbitrarily high rates. And, we want the reader to understand that > such a sending pattern is not terribly acceptable. So, it seems to > me this is sort of thorny. Well, if you are interested in measuring the reordering extent up to 10 positions, you have to send only 10 packets at a full speed - not much, but still abusive if measurement continued in longer intervals or too often. Anyway, sending at full rate was very usefull for us - even for finding out the equipment "impairments" that we were not aware of before measuring. And if the end user (FEth? ADSL?) sends across Big-I Internet (10Gbit/s) his maximum speed stream, probably noone will notice. > * A clear recommendation that says that to gauge reordering for any > particular application the best way to do that is to send using the > same pattern as that application. I also think that this is the best way for measuring the *possible reordering* for particular applications. All the best, Michal -- ______________________________________________________________________ Michal Przybylski Network Research and Development michalp@man.poznan.pl Poznan Supercomputing and Networking Center +48 61 858 20 27 http://www.man.poznan.pl ______________________________________________________________________ _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Jan 31 03:28:51 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01803 for ; Mon, 31 Jan 2005 03:28:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvWti-0004nO-Ta; Mon, 31 Jan 2005 03:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvWrH-0004bo-3k for ippm@megatron.ietf.org; Mon, 31 Jan 2005 03:24:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01367 for ; Mon, 31 Jan 2005 03:24:29 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvX9B-0004yF-Cx for ippm@ietf.org; Mon, 31 Jan 2005 03:43:01 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 2E886267F9; Mon, 31 Jan 2005 09:23:59 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 46CC724DAB; Mon, 31 Jan 2005 09:23:58 +0100 (CET) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j0V8Naf0004876; Mon, 31 Jan 2005 09:23:58 +0100 Message-Id: <6.2.0.14.2.20050131082334.02b801f0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 31 Jan 2005 08:25:38 +0100 To: "STEPHAN Emile RD-CORE-LAN" , From: Henk Uijterwaal In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000315 / -5.9 X-RIPE-Signature: 05213a5ee9480cc2fcc25fd605c90d8e X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: Matthew J Zekauskas Subject: [ippm] Re: 'IPPM' IDs on multicast an spatial measure X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Dear Emile, >During the last WG meeting Matt asked me to reread the draft >draft-liang-multiparty-para-00.txt while considering the previous IDs I >posted on spatial and multicast metrics. > >I reread them. Following is the list of metrics I found. I can make >further classifications, comparisons or comments if needed. Based on your reading of this draft, do you have any opinion on how we should proceed with draft-liang-multiparty... Pick it up as a WG item? Leave it to the authors to pursue as an individual submission? Kind regards, Henk >Regards > >Emile >--------------- draft-stephan-ippm-multicast-metrics-00.txt ---------------- > >The draft defines 1 network metrics: > > + Type-P-spatial-hop-one-way-delay > > > >The draft defines several aggregation metrics: > > + Type-P-spatial-one-way-delay-stream > > + Type-P-spatial-one-way-delay > > + Type-P-Multicast-Instantaneous-Hop-One-way-Delay > > + Type-P-Multicast-Instantaneous-One-way-Delay-Percentile > > + Type-P-Multicast-Instantaneous-One-way-Delay-Median > > + Type-P-Multicast-Instantaneous-One-way-Delay-Inverse Percentile > > + Type-P-Multicast-Instantaneous-Packet-Loss-Stream > > + Type-P-Multicast-Instantaneous-Packet-Loss-Percentile > > + Type-P-Multicast-Instantaneous-Packet-Loss-Median > > + Type-P-Multicast-Instantaneous-Packet-Loss-Inverse Percentile > > + Type-P-Multicast-Instantaneous-Connectivity > > > >--------------- draft-stephan-ippm-spatial-metrics-01.txt --------------- > > > >The draft defines 2 network metrics: > > + Type-P-spatial-one-way-delay > > + Type-P-Spatial-packet-loss > > > >The draft defines several path aggregation metrics : > > + Type-P-one-way-delay-trajectory > > + Type-P-aggregated-one-way-delay > > + Type-P-asynchronous-one-way-delay-trajectory > > + Type-P-asynchronous-aggregated-one-way-delay > > + Type-P-Spatial-packet-loss-stream > > + Type-P-Spatial-packet-loss-Average > > > >--------------- draft-liang-multiparty-para-00.txt --------------- > >The draft defines statistics for end to end multicast performance, mainly >to identify the variation of the performance between the member of a group. > >Actually the draft has 4 groups of statistics metrics: > > One-to-group-Mean-Paramater > > One-to-group-Variation-Paramater > > Group-to-one-Mean-Paramater > > Group-to-one-Variation-Paramater > >The value of Parameter depends on what one-way metric is used from delay, >loss ot jitter. > >To permit comparison I extended the list of metrics defined using IPPM >metrics terminology: > > + Type-P-One-to-group-Mean-one-way-delay; > > + Type-P-One-to-group-Mean-Packet-Loss; > > + Type-P-One-to-group-Mean-ipdv; > > > > + Type-P-One-to-group-Variation-one-way-delay; > > + Type-P-One-to-group-Variation-Packet-Loss; > > + Type-P-One-to-group-Variation-ipdv; > > > > + Type-P-Group-to-one-Mean-one-way-delay; > > + Type-P-Group-to-one-Mean-Packet-Loss; > > + Type-P-Group-to-one-Mean-ipdv; > > > > + Type-P-Group-to-one-Variation-one-way-delay; > > + Type-P-Group-to-one-Variation-Packet-Loss; > > + Type-P-Group-to-one-Variation-ipdv; ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Jan 31 11:32:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20409 for ; Mon, 31 Jan 2005 11:32:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CveM9-0001YQ-JU; Mon, 31 Jan 2005 11:24:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cve67-0006HF-Fu for ippm@megatron.ietf.org; Mon, 31 Jan 2005 11:08:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16854 for ; Mon, 31 Jan 2005 11:08:16 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CveO4-00072S-Bf for ippm@ietf.org; Mon, 31 Jan 2005 11:26:53 -0500 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id j0VG8B1x057965; Mon, 31 Jan 2005 08:08:11 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 33F1277AB67; Mon, 31 Jan 2005 11:08:10 -0500 (EST) To: =?ISO-8859-2?Q?Micha=B3_Przybylski?= From: Mark Allman Subject: Re: [ippm] thoughts on reordering draft (-08) In-Reply-To: <41F7A55B.1090909@man.poznan.pl> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Under the Bridge MIME-Version: 1.0 Date: Mon, 31 Jan 2005 11:08:10 -0500 Message-Id: <20050131160810.33F1277AB67@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ippm@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1472482629==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --===============1472482629== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain > > I don't think we want to advocate blasting test streams across > > the big-I Internet at arbitrarily high rates. And, we want the > > reader to understand that such a sending pattern is not terribly > > acceptable. So, it seems to me this is sort of thorny. > > Well, if you are interested in measuring the reordering extent up to > 10 positions, you have to send only 10 packets at a full speed - not > much, but still abusive if measurement continued in longer intervals > or too often. Exactly. If you send only one volley of 10 packets then that's fine - I have no problem with it. But, the trouble is that's not a very solid assessment of the network. And, given that this is intended to be a standard way to assess reordering I think there should be some words to the effect that one needs to be quite careful. > Anyway, sending at full rate was very usefull for us - even for > finding out the equipment "impairments" that we were not aware of > before measuring. And if the end user (FEth? ADSL?) sends across > Big-I Internet (10Gbit/s) his maximum speed stream, probably noone > will notice. I think it would be fine to divided things into application-oriented assessment and stress testing and discuss each in more detail than either is touched upon now. > > * A clear recommendation that says that to gauge reordering for any > > particular application the best way to do that is to send using the > > same pattern as that application. > > I also think that this is the best way for measuring the *possible > reordering* for particular applications. I disagree with that phrasing (but, maybe not the intent). If my application only sends one packet every 10 seconds then there is no way that a stress test can predict the "possible" reordering my application will observe. I would buy that sending at line rate may provide an upper bound on the amount of reordering that *some* application could conceivably observe. And, that might be useful. But, I think trying to tie such a notion to any "particular application" is very thorny and quite tenuous. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFB/lfqWyrrWs4yIs4RAmIMAJ4hz7DAzWX61ten5i3UbemLCIUdXQCglIoA RcqPfcnmEA5PXS5Evfh0CGM= =WAkJ -----END PGP SIGNATURE----- --=-=-=-- --===============1472482629== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm --===============1472482629==--