From test-admin@advanced.org Thu Feb 1 06:52:19 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23750 for ; Thu, 1 Feb 2001 06:52:18 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f11BqFh21868 for ; Thu, 1 Feb 2001 06:52:15 -0500 Date: Thu, 1 Feb 2001 06:52:15 -0500 Message-Id: <200102011152.f11BqFh21868@mailhost.advanced.org> Subject: advanced.org mailing list memberships reminder From: mailman-owner@advanced.org To: ippm-archive@ietf.org X-No-Archive: yes Sender: test-admin@advanced.org Errors-To: test-admin@advanced.org X-BeenThere: test@mailhost.advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: This is a reminder, sent out once a month, about your advanced.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, ippm-request@advanced.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@advanced.org. Thanks! Passwords for ippm-archive@lists.ietf.org: List Password // URL ---- -------- ippm@advanced.org jTPE http://mailhost.advanced.org/mailman/options/ippm/ippm-archive@lists.ietf.org From ippm-admin@advanced.org Thu Feb 1 08:58:30 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27325 for ; Thu, 1 Feb 2001 08:58:30 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f11Dtmh29339; Thu, 1 Feb 2001 08:55:48 -0500 Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f11Drxh29111 for ; Thu, 1 Feb 2001 08:54:00 -0500 Received: from zuurtje.surfnet.nl ([192.87.109.5]) by survis.surfnet.nl with ESMTP (exPP) for ippm@advanced.org id 14OKBV-0003rc-00; Thu, 1 Feb 2001 14:54:01 +0100 Received: from surfnet.nl (reijs.tunnel.surfnet.nl [192.87.108.139]) by zuurtje.surfnet.nl (8.9.3/8.9.3/ZUURTJE-0.8) with ESMTP id OAA07775 for ; Thu, 1 Feb 2001 14:54:00 +0100 (MET) Message-ID: <3A796A78.97B818A5@surfnet.nl> Date: Thu, 01 Feb 2001 13:54:00 +0000 From: Victor Reijs Organization: SURFnet bv X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org Subject: Re: [ippm] New ipdv draft (attached) References: <3A78AD0D.13214834@torrentnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Hello Phil, Because I am quiet new to this subject just an issue that still pops in my writings/thoughts: 'Accuracy' seems to be a defined term in RFC2679 (has to do with the clock) Sometimes I want to talk about the accuracy of the result of a measurement (like you also do on page 7), but is that the correct wording because of this 'reservation' of the term? Perhaps I should use 'error' or 'standard variation' or ??? Hoep you can help me with this basic naive question. All the best, Victor "P.F. Chimento" wrote: > > Hello all: > > I have attached a new ipdv draft which has been modified according to > many of the comments that I received on the mailing list in November. I > did not submit it as an ID yet, because I wanted to get comments from > the mailing list before officially submitting it as a new draft. > _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 1 10:11:38 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28942 for ; Thu, 1 Feb 2001 10:11:38 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f11F7oh00505; Thu, 1 Feb 2001 10:07:50 -0500 Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f11F4Jh32668 for ; Thu, 1 Feb 2001 10:04:20 -0500 X-Authentication-Warning: mailhost.advanced.org: Host almso1.att.com [192.128.167.69] claimed to be almso1.proxy.att.com Received: from flf960r1.ems.att.com ([135.71.244.37]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f11F4AO15664; Thu, 1 Feb 2001 10:04:10 -0500 (EST) Received: from njb140bh1.ems.att.com by flf960r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA24790; Thu, 1 Feb 2001 10:02:26 -0500 (EST) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Feb 2001 10:04:09 -0500 Message-ID: From: "Cole, Robert G (Bob), ALSVC" To: ippm@advanced.org, stanislav shalunov Cc: "'henk@ripe.net'" Subject: RE: [ippm] Re: draft-ietf-ippm-owdp: should it be split? Date: Thu, 1 Feb 2001 10:04:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Joan, I am not suggesting that OWDP-test will be developed and deployed with no means to set up the parameters for the test-plane. > > Therefore, some vendors may not implement OWDP-Control at all. > > I disagree here. The control-plane (at least as far as the > draft-ietf-ippm-owdp-01.txt is concerned) sets up parameters for the > test-plane. > Rather, there will be other means to set up the parameters, e.g., thru the draft-kalbfleisch-sspmmib-00.txt ( sorry but I incorretly wrote the reference to this last time). Clearly, we must ensure that the other means support the correct and sufficient set of parameters necessary to run OWDP-test. Thanks, Bob _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 1 11:47:33 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01072 for ; Thu, 1 Feb 2001 11:47:33 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f11Ge2h06064; Thu, 1 Feb 2001 11:40:02 -0500 Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f11Gaxh05656 for ; Thu, 1 Feb 2001 11:37:00 -0500 Received: from zuurtje.surfnet.nl ([192.87.109.5]) by survis.surfnet.nl with ESMTP (exPP) for ippm@advanced.org id 14OMjE-0005fA-00; Thu, 1 Feb 2001 17:37:00 +0100 Received: from surfnet.nl (reijs.tunnel.surfnet.nl [192.87.108.139]) by zuurtje.surfnet.nl (8.9.3/8.9.3/ZUURTJE-0.8) with ESMTP id RAA16247 for ; Thu, 1 Feb 2001 17:36:59 +0100 (MET) Message-ID: <3A7990A7.7C0D8008@surfnet.nl> Date: Thu, 01 Feb 2001 16:36:55 +0000 From: Victor Reijs Organization: SURFnet bv X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org Subject: Re: [ippm] New ipdv draft (attached) References: <3A78AD0D.13214834@torrentnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Hello Phil, One addition perhaps. There are now One-way-ipdv statistics defined (section 6). Is it not good also define in this section the statistics used within the RTP protocol (RFC1889, section 6.3.1)? Looking at RTP; it uses at least the same method of determining some sort of 'Type-P-One-way-ipdv' -> (D(i-1,i)) The 'Type-P-One-way-ipdv-interarrival-rtp???' (J) is determined by: J=J+(|D(i-1,i)|-J)/16 What do you think? This provides links between RFC... All the best, Victor "P.F. Chimento" wrote: > > Hello all: > > I have attached a new ipdv draft which has been modified according to > many of the comments that I received on the mailing list in November. I > did not submit it as an ID yet, because I wanted to get comments from > the mailing list before officially submitting it as a new draft. > > _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 1 11:58:21 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03176 for ; Thu, 1 Feb 2001 11:58:21 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f11Gv2h07648; Thu, 1 Feb 2001 11:57:02 -0500 Received: from brixcorp2.brixnet.com ([216.91.233.5]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f11Gu5h07589 for ; Thu, 1 Feb 2001 11:56:06 -0500 X-Authentication-Warning: mailhost.advanced.org: Host [216.91.233.5] claimed to be brixcorp2.brixnet.com Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Feb 2001 11:56:07 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB9B7F3A@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'ippm@advanced.org'" , stanislav shalunov Cc: "'henk@ripe.net'" Subject: RE: [ippm] Re: draft-ietf-ippm-owdp: should it be split? Date: Thu, 1 Feb 2001 11:56:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List > -----Original Message----- > From: Cole, Robert G (Bob), ALSVC [mailto:rgcole@att.com] > Sent: Thursday, February 01, 2001 10:04 AM > To: ippm@advanced.org; stanislav shalunov > Cc: 'henk@ripe.net' > Subject: RE: [ippm] Re: draft-ietf-ippm-owdp: should it be split? > > > Joan, > > I am not suggesting that OWDP-test will be developed and deployed with > no means to set up the parameters for the test-plane. > > > > > Therefore, some vendors may not implement OWDP-Control at all. > > > > I disagree here. The control-plane (at least as far as the > > draft-ietf-ippm-owdp-01.txt is concerned) sets up parameters for the > > test-plane. > > > Rather, there will be other means to set up the parameters, > e.g., thru the > draft-kalbfleisch-sspmmib-00.txt ( sorry but I incorretly wrote the > reference to this > last time). Clearly, we must ensure that the other means support > the correct and sufficient set of parameters necessary to run > OWDP-test. Hi Bob, Thank you for the clarification, I understand now what you mean by vendors may not support the OWDP control-plane at all and may opt for some other control mechanism. I don't really see any problem with having multiple methods of control to set up the test-plane. So basically, I think we agree. However, for an IETF standard, I think that one method of setting up the test needs to be the adopted for the standard. If I'm Vendor A and your Vendor B and I want to act as the sender and communicate to you are a receiver, without a definitive method of control, how does Vendor A communicate with Vendor B? Assuming Vendor B supports all methods of control seems overly complex. Assuming that Vendor A attempts different methods of control until Vendor B responds to one of them, seems very inefficient. I am concerned that this approach is going to drag out the adoption of any control method and the hope of ever getting a one-way delay mechanism as "commonplace" as PING would be NIL. An analogy would be the current diffserv PIB in RAP and the diffserv MIB being developed in SNMPCONF, one could argue that PIBs/COPS+ and MIBs/SNMPCONF for this specific instance of diffserv configuration are two different mechanism which produce the same result (meaning the PIB == MIB in this scenario). Even though the mechanisms are very different the same data would be manipulated and the same end results occur and this was intentionally the goal of the SNMPCONF wg when they undertook designing a Diffserv MIB. I would even go so far as to say, different control mechanisms may imply different protocols. To extend the above anaology, one could probably use COPS+ and/or SNMPCONF to also set up the test-plane. I wouldn't necessarily mandate that every device that wants to support one-way delay test-plane needs to also support SNMPCONF and COPS+ in addition to the TCP mechanism proposed in draft-ietf-ippm-owdp-01.txt. I certainly don't view these as the same protocol. In summary, I believe that one of the major motivations for vendors to implement an IETF standard is interoperability with other vendors. Starting with one control method and one test-plane would achieve interoperability faster and more directly. Thanks, Joan > > Thanks, > Bob > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm > _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 1 18:25:02 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14316 for ; Thu, 1 Feb 2001 18:25:01 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f11NL4h32172; Thu, 1 Feb 2001 18:21:04 -0500 Received: from cmailg1.svr.pol.co.uk (cmailg1.svr.pol.co.uk [195.92.195.171]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f11NKLh32133 for ; Thu, 1 Feb 2001 18:20:22 -0500 Received: from [195.92.198.123] (helo=mail17.svr.pol.co.uk) by cmailg1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14OT1X-0007z1-00 for ippm@advanced.org; Thu, 01 Feb 2001 23:20:19 +0000 Received: from modem-71.arien.dialup.pol.co.uk ([62.136.124.199] helo=hawk-technologies.co.uk) by mail17.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14OSRA-00034B-00 for ippm@advanced.org; Thu, 01 Feb 2001 22:42:46 +0000 To: ippm@advanced.org From: "HAWK TECHNOLOGIES UK" X-Mailer: 2BCF0A9.210A73BB.d4801da9ca3aa80e161146e2b7cbefcf Organization: "HAWK TECHNOLOGIES UK" Message-Id: Date: Thu, 01 Feb 2001 22:42:46 +0000 Subject: [ippm] TRUCKERS!!! - ILLEGAL IMMIGRANT AND THEFT PROBLEM - SOLVED! Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List YOU WILL BE PROSECUTED!!! THIS EMAIL IS OF UTMOST IMPORTANCE- PLEASE READ. Dear Transport Manager, You have received this email because you have expressed an interest in important transport related issues in the past. If this is incorrect or you no longer wish to receive IMPORTANT Transport related information please except or sincere apologies and reply to this email typing "REMOVE" in the subject line and you will be removed from any future mailings. As you are well aware, if illegal immigrants who are stowaways in the rear of your vehicles are detected by the authorities, your company will incur fines of up to £2000 per head in the UK! This is happening to hundreds of HGV's every week... It is happening NOW and becoming a HUGE problem. So much so, that the UK Government have authorised searches of all heavy goods vehicles (including overseas company vehicles) entering the UK to detect illegal immigrants trying to gain access into the country. This in turn will create massive hold ups to both hauliers and the immigration authorities enforcing the searches. This is NOT just UK related - it is world-wide!!! WE HAVE THE SOLUTION TO THIS HUGE PROBLEM..... I will get straight to the point, as I know being a fellow businessman how precious your time can be. Our company specialises in the implementation of covert camera systems within vehicles, being able to DETECT AND RECORD UNAUTHORISED ENTRY into vehicles and their trailers. Just look how the "TruckEye" system will help your company: * OBSERVATION OF OCCUPANTS - The driver can observe from his cab any intruders that may have entered the vehicle who may be attempting to hide themselves away or smuggle illegal goods. * KEEPS THE DRIVER SAFE!!! - NO CONFRONTATION - UNLIKE CONVENTIONAL ALARM SYSTEMS - You have 100% PROOF that you have someone in the rear of the vehicle! The driver doesn't need to confront the intruders - he can go directly to the authorities or police with POSITIVE RECORDED PROOF! * SAVES VERY HEAVY FINES!!! Hauliers entering the UK are currently being fined £2000.00 per head for every person caught illegally entering the country in the rear of their vehicles. * CANNOT BE DETECTED - Completely covert - Undetectable by occupants. * WORKS IN COMPLETE DARKNESS - Unlike conventional camera systems. * EASY TO FIT - DIY Fitting. * EXTREMELY EASY TO USE - DIGITAL TECHNOLOGY - Doesn't need video tapes - Doesn't rely on driver to load tapes etc. or for operation - will always be ready to capture unauthorised entries. * FULLY AUTOMATIC * TOTALLY RELIABLE * 12 MONTHS BACK TO BASE WARRANTY * 25 YEARS RECORD TIME - Will run for twenty-five years continuously if needed. * COMPLETELY TRANSPORTABLE. * WILL TAKE UP TO 4 CAMERA'S - The base unit can operate four cameras covering any entry/exit points. * NO EXPENSIVE MAINTENENCE CONTRACTS The "TruckEye" system records the exact time of entry, captures digital images/footage and lets the driver know BEFORE he moves away to cross the border or channel if he is in fact transporting illegal immigrants, if he has had any unauthorized entry into his vehicle (theft) or if his vehicle has been tampered with an any way. This would otherwise go un-noticed without one of these systems fitted. This means the driver DOES NOT HAVE TO CONFRONT ANY INTRUDER (as with conventional alarm systems), but can go directly to the authorities with POSITIVE RECORDED PROOF allowing them to act on the information presented. If these immigrants are not detected, your company WILL incur fines of up to £2000 per head in the UK ! The systems are totally reliable, very robust and can save you thousands of pounds in fines, court costs and lost goods should your company vehicles be caught transporting these illegal immigrants or are broken into. I am sure you will agree this is huge problem that cannot be ignored and in the UK the Government is handing the responsibility over to the hauliers. Don't become a victim. We will be very happy to discuss this unique system and its benefits with you and to show you how easily this problem can be remedied, saving you thousands of pounds in potential fines or stolen goods. "TruckEye" can also be used to monitor unstable loads while in transit or stationary and can monitor the loading and unloading of goods to be sure everything is as it should be. This is what the transport industry has needed for many years. It is like having your very own night watchman looking after your vehicle, only you don't have to pay any wages and it works 24hrs a day 7 days a week 365 days a year with no days off! For more information on this revolutionary product, visit our website NOW at: http://www.hawk-technologies.co.uk and click on the link "TruckEye" Please feel free to contact me at any time on the following number: Tel: +44 (0)70 9121 42 32 or E-mail: mailto:TruckEye@freeautobot.com Kind regards Brian A. Doherty SALES DIRECTOR HAWK TECHNOLOGIES UK Tel: +44 (0)709 121 42 32 E-mail: brian@hawk-technologies.co.uk _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 1 18:44:22 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14715 for ; Thu, 1 Feb 2001 18:44:22 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f11Nb3h00621; Thu, 1 Feb 2001 18:37:03 -0500 Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f11Na3h00560 for ; Thu, 1 Feb 2001 18:36:05 -0500 Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA12643 for ; Thu, 1 Feb 2001 18:35:41 -0500 (EST) Received: from htiku-pc (ch2-dhcp134-189.cisco.com [161.44.134.189]) by bucket.cisco.com (Mirapoint) with SMTP id ABJ70118; Thu, 1 Feb 2001 18:36:03 -0500 (EST) From: "Hidega Tiku" To: Date: Thu, 1 Feb 2001 18:33:35 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Subject: [ippm] REMOVE Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit -----Original Message----- From: ippm-admin@advanced.org [mailto:ippm-admin@advanced.org]On Behalf Of HAWK TECHNOLOGIES UK Sent: Thursday, February 01, 2001 5:43 PM To: ippm@advanced.org Subject: [ippm] TRUCKERS!!! - ILLEGAL IMMIGRANT AND THEFT PROBLEM - SOLVED! YOU WILL BE PROSECUTED!!! THIS EMAIL IS OF UTMOST IMPORTANCE- PLEASE READ. Dear Transport Manager, You have received this email because you have expressed an interest in important transport related issues in the past. If this is incorrect or you no longer wish to receive IMPORTANT Transport related information please except or sincere apologies and reply to this email typing "REMOVE" in the subject line and you will be removed from any future mailings. As you are well aware, if illegal immigrants who are stowaways in the rear of your vehicles are detected by the authorities, your company will incur fines of up to ?2000 per head in the UK! This is happening to hundreds of HGV's every week... It is happening NOW and becoming a HUGE problem. So much so, that the UK Government have authorised searches of all heavy goods vehicles (including overseas company vehicles) entering the UK to detect illegal immigrants trying to gain access into the country. This in turn will create massive hold ups to both hauliers and the immigration authorities enforcing the searches. This is NOT just UK related - it is world-wide!!! WE HAVE THE SOLUTION TO THIS HUGE PROBLEM..... I will get straight to the point, as I know being a fellow businessman how precious your time can be. Our company specialises in the implementation of covert camera systems within vehicles, being able to DETECT AND RECORD UNAUTHORISED ENTRY into vehicles and their trailers. Just look how the "TruckEye" system will help your company: * OBSERVATION OF OCCUPANTS - The driver can observe from his cab any intruders that may have entered the vehicle who may be attempting to hide themselves away or smuggle illegal goods. * KEEPS THE DRIVER SAFE!!! - NO CONFRONTATION - UNLIKE CONVENTIONAL ALARM SYSTEMS - You have 100% PROOF that you have someone in the rear of the vehicle! The driver doesn't need to confront the intruders - he can go directly to the authorities or police with POSITIVE RECORDED PROOF! * SAVES VERY HEAVY FINES!!! Hauliers entering the UK are currently being fined ?2000.00 per head for every person caught illegally entering the country in the rear of their vehicles. * CANNOT BE DETECTED - Completely covert - Undetectable by occupants. * WORKS IN COMPLETE DARKNESS - Unlike conventional camera systems. * EASY TO FIT - DIY Fitting. * EXTREMELY EASY TO USE - DIGITAL TECHNOLOGY - Doesn't need video tapes - Doesn't rely on driver to load tapes etc. or for operation - will always be ready to capture unauthorised entries. * FULLY AUTOMATIC * TOTALLY RELIABLE * 12 MONTHS BACK TO BASE WARRANTY * 25 YEARS RECORD TIME - Will run for twenty-five years continuously if needed. * COMPLETELY TRANSPORTABLE. * WILL TAKE UP TO 4 CAMERA'S - The base unit can operate four cameras covering any entry/exit points. * NO EXPENSIVE MAINTENENCE CONTRACTS The "TruckEye" system records the exact time of entry, captures digital images/footage and lets the driver know BEFORE he moves away to cross the border or channel if he is in fact transporting illegal immigrants, if he has had any unauthorized entry into his vehicle (theft) or if his vehicle has been tampered with an any way. This would otherwise go un-noticed without one of these systems fitted. This means the driver DOES NOT HAVE TO CONFRONT ANY INTRUDER (as with conventional alarm systems), but can go directly to the authorities with POSITIVE RECORDED PROOF allowing them to act on the information presented. If these immigrants are not detected, your company WILL incur fines of up to ?2000 per head in the UK ! The systems are totally reliable, very robust and can save you thousands of pounds in fines, court costs and lost goods should your company vehicles be caught transporting these illegal immigrants or are broken into. I am sure you will agree this is huge problem that cannot be ignored and in the UK the Government is handing the responsibility over to the hauliers. Don't become a victim. We will be very happy to discuss this unique system and its benefits with you and to show you how easily this problem can be remedied, saving you thousands of pounds in potential fines or stolen goods. "TruckEye" can also be used to monitor unstable loads while in transit or stationary and can monitor the loading and unloading of goods to be sure everything is as it should be. This is what the transport industry has needed for many years. It is like having your very own night watchman looking after your vehicle, only you don't have to pay any wages and it works 24hrs a day 7 days a week 365 days a year with no days off! For more information on this revolutionary product, visit our website NOW at: http://www.hawk-technologies.co.uk and click on the link "TruckEye" Please feel free to contact me at any time on the following number: Tel: +44 (0)70 9121 42 32 or E-mail: mailto:TruckEye@freeautobot.com Kind regards Brian A. Doherty SALES DIRECTOR HAWK TECHNOLOGIES UK Tel: +44 (0)709 121 42 32 E-mail: brian@hawk-technologies.co.uk _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Feb 2 06:38:37 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06247 for ; Fri, 2 Feb 2001 06:38:36 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f12Ba3h27253; Fri, 2 Feb 2001 06:36:03 -0500 Received: from mailgestao.intra.cet.pt ([194.65.138.12]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f12BZYh27232 for ; Fri, 2 Feb 2001 06:35:45 -0500 X-Authentication-Warning: mailhost.advanced.org: Host [194.65.138.12] claimed to be mailgestao.intra.cet.pt Received: by mailgestao.intra.cet.pt with Internet Mail Service (5.5.2448.0) id <1BJZVJX5>; Fri, 2 Feb 2001 11:32:05 -0000 Message-ID: <25CCC6566D01D411885B00A024559FB717414B@EXCHANGE_GERAL> From: Augusta Manuela To: "'ippm@advanced.org'" Subject: [ippm] REMOVE Date: Fri, 2 Feb 2001 11:36:42 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id f12BZYh27232 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.advanced.org id f12Ba3h27253 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA06247 -----Original Message----- From: HAWK TECHNOLOGIES UK [mailto:truckeye@hawk-technologies.co.uk] Sent: Quinta-feira, 1 de Fevereiro de 2001 22:43 To: ippm@advanced.org Subject: [ippm] TRUCKERS!!! - ILLEGAL IMMIGRANT AND THEFT PROBLEM - SOLVED! YOU WILL BE PROSECUTED!!! THIS EMAIL IS OF UTMOST IMPORTANCE- PLEASE READ. Dear Transport Manager, You have received this email because you have expressed an interest in important transport related issues in the past. If this is incorrect or you no longer wish to receive IMPORTANT Transport related information please except or sincere apologies and reply to this email typing "REMOVE" in the subject line and you will be removed from any future mailings. As you are well aware, if illegal immigrants who are stowaways in the rear of your vehicles are detected by the authorities, your company will incur fines of up to £2000 per head in the UK! This is happening to hundreds of HGV's every week... It is happening NOW and becoming a HUGE problem. So much so, that the UK Government have authorised searches of all heavy goods vehicles (including overseas company vehicles) entering the UK to detect illegal immigrants trying to gain access into the country. This in turn will create massive hold ups to both hauliers and the immigration authorities enforcing the searches. This is NOT just UK related - it is world-wide!!! WE HAVE THE SOLUTION TO THIS HUGE PROBLEM..... I will get straight to the point, as I know being a fellow businessman how precious your time can be. Our company specialises in the implementation of covert camera systems within vehicles, being able to DETECT AND RECORD UNAUTHORISED ENTRY into vehicles and their trailers. Just look how the "TruckEye" system will help your company: * OBSERVATION OF OCCUPANTS - The driver can observe from his cab any intruders that may have entered the vehicle who may be attempting to hide themselves away or smuggle illegal goods. * KEEPS THE DRIVER SAFE!!! - NO CONFRONTATION - UNLIKE CONVENTIONAL ALARM SYSTEMS - You have 100% PROOF that you have someone in the rear of the vehicle! The driver doesn't need to confront the intruders - he can go directly to the authorities or police with POSITIVE RECORDED PROOF! * SAVES VERY HEAVY FINES!!! Hauliers entering the UK are currently being fined £2000.00 per head for every person caught illegally entering the country in the rear of their vehicles. * CANNOT BE DETECTED - Completely covert - Undetectable by occupants. * WORKS IN COMPLETE DARKNESS - Unlike conventional camera systems. * EASY TO FIT - DIY Fitting. * EXTREMELY EASY TO USE - DIGITAL TECHNOLOGY - Doesn't need video tapes - Doesn't rely on driver to load tapes etc. or for operation - will always be ready to capture unauthorised entries. * FULLY AUTOMATIC * TOTALLY RELIABLE * 12 MONTHS BACK TO BASE WARRANTY * 25 YEARS RECORD TIME - Will run for twenty-five years continuously if needed. * COMPLETELY TRANSPORTABLE. * WILL TAKE UP TO 4 CAMERA'S - The base unit can operate four cameras covering any entry/exit points. * NO EXPENSIVE MAINTENENCE CONTRACTS The "TruckEye" system records the exact time of entry, captures digital images/footage and lets the driver know BEFORE he moves away to cross the border or channel if he is in fact transporting illegal immigrants, if he has had any unauthorized entry into his vehicle (theft) or if his vehicle has been tampered with an any way. This would otherwise go un-noticed without one of these systems fitted. This means the driver DOES NOT HAVE TO CONFRONT ANY INTRUDER (as with conventional alarm systems), but can go directly to the authorities with POSITIVE RECORDED PROOF allowing them to act on the information presented. If these immigrants are not detected, your company WILL incur fines of up to £2000 per head in the UK ! The systems are totally reliable, very robust and can save you thousands of pounds in fines, court costs and lost goods should your company vehicles be caught transporting these illegal immigrants or are broken into. I am sure you will agree this is huge problem that cannot be ignored and in the UK the Government is handing the responsibility over to the hauliers. Don't become a victim. We will be very happy to discuss this unique system and its benefits with you and to show you how easily this problem can be remedied, saving you thousands of pounds in potential fines or stolen goods. "TruckEye" can also be used to monitor unstable loads while in transit or stationary and can monitor the loading and unloading of goods to be sure everything is as it should be. This is what the transport industry has needed for many years. It is like having your very own night watchman looking after your vehicle, only you don't have to pay any wages and it works 24hrs a day 7 days a week 365 days a year with no days off! For more information on this revolutionary product, visit our website NOW at: http://www.hawk-technologies.co.uk and click on the link "TruckEye" Please feel free to contact me at any time on the following number: Tel: +44 (0)70 9121 42 32 or E-mail: mailto:TruckEye@freeautobot.com Kind regards Brian A. Doherty SALES DIRECTOR HAWK TECHNOLOGIES UK Tel: +44 (0)709 121 42 32 E-mail: brian@hawk-technologies.co.uk _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Feb 2 15:47:00 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27436 for ; Fri, 2 Feb 2001 15:46:59 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f12Ke3h24080; Fri, 2 Feb 2001 15:40:03 -0500 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f12KdRh24026; Fri, 2 Feb 2001 15:39:28 -0500 Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA24733; Fri, 2 Feb 2001 15:39:22 -0500 (EST) Received: from guns (mallman@localhost) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id PAA03765; Fri, 2 Feb 2001 15:40:01 -0500 (EST) Message-Id: <200102022040.PAA03765@guns.lerc.nasa.gov> To: "Matthew J Zekauskas" From: Mark Allman cc: mathis@psc.edu, "Merike Kaeo" , ippm@advanced.org Organization: NASA GRC/BBN Technologies Song-of-the-Day: Imagine Date: Fri, 02 Feb 2001 15:40:00 -0500 Subject: [ippm] Re: thoughts on draft-ietf-ippm-btc-framework-04.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List > I did a thorough read of the document, and have one point that > might be worth a discussion. In section 1, you define BTC as > data_sent / elapsed_time, where data_sent represents the unique > "data" bytes transferred. To me, this means BTC is bytes/sec. I > believe Treno and cap both report(ed?) in bits/sec. I think the > units should explicitly be bits/sec (as you do in section 3.1 for > congestion avoidance capacity). OK. I can go either way. Cap reports bytes, but a "bit" and a "byte" are pretty much universal and can't be confused too much. I don't like the idea of using KB because that means either 1000 or 1024 bytes and even if it is specified, some people will screw it up in their heads (some people like me!). > In section 3.1, at the end of the first paragraph you mention > "(except the single segment Slow-Start that is permitted to follow > recovery, as discussed in section 2.3)". It's not section 2.3 of > this document; I assume there should be a reference here. OK. I'll patch this... > In section 2, the first two bulleted points are implicit MUSTs; > the final three are explicit MUSTs. The wording in the first two > should probably change. Similarly, I think the "should" should be > uppercased in the final sentence of section 2. And this... Thanks! (And, sorry for the slow response...) allman _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 5 08:23:57 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04841 for ; Mon, 5 Feb 2001 08:23:57 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f15DK3h00622; Mon, 5 Feb 2001 08:20:03 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f15DJ3h00559 for ; Mon, 5 Feb 2001 08:19:07 -0500 Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id OAA18933; Mon, 5 Feb 2001 14:18:56 +0100 (CET) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id OAA02527; Mon, 5 Feb 2001 14:18:56 +0100 (CET) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Mon, 5 Feb 2001 14:18:56 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: "Cucchiara, Joan" cc: "'ippm@advanced.org'" Subject: RE: [ippm] Re: draft-ietf-ippm-owdp: should it be split? In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB9B7F3A@brixcorp2.brixnet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Joan, > In summary, I believe that one of the major motivations for vendors to > implement an IETF standard is interoperability with other vendors. > Starting with one control method and one test-plane would achieve > interoperability faster and more directly. But in that case, I think we should take a step back and discuss requirements for the control protocol first, then design it from there. IIRC, the OWDP-C in the draft is (close to) the mechanism chosen by one of the implementations and this is now being promoted to a standard. However, there are other OWD implementations and they have come up with totally different OWDP-C's based on slightly different requirements and implementation choices. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 5 11:37:15 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11323 for ; Mon, 5 Feb 2001 11:37:14 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f15GW3h10302; Mon, 5 Feb 2001 11:32:03 -0500 Received: from brixcorp2.brixnet.com ([63.122.27.34]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f15GVbh10260 for ; Mon, 5 Feb 2001 11:31:42 -0500 X-Authentication-Warning: mailhost.advanced.org: Host [63.122.27.34] claimed to be brixcorp2.brixnet.com Received: by Brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id <1FM7BZJQ>; Mon, 5 Feb 2001 11:31:39 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB9B7F45@Brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'ippm@advanced.org'" , "'henk.uijterwaal@ripe.net'" Subject: RE: [ippm] Re: draft-ietf-ippm-owdp: should it be split? Date: Mon, 5 Feb 2001 11:31:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List > -----Original Message----- > From: Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net] > Sent: Monday, February 05, 2001 8:19 AM > To: Cucchiara, Joan > Cc: 'ippm@advanced.org' > Subject: RE: [ippm] Re: draft-ietf-ippm-owdp: should it be split? > > > Joan, > > > > In summary, I believe that one of the major motivations for > vendors to > > implement an IETF standard is interoperability with other vendors. > > Starting with one control method and one test-plane would achieve > > interoperability faster and more directly. Hi Henk, > > But in that case, I think we should take a step back and discuss > requirements for the control protocol first, then design it > from there. I agree. A few people at Brix read this draft also, and echoed the same comment. We also think this draft needs a clearly specified goals/requirements section. Also, it is sometimes helpful to list non-goals, and thus clearly limit the scope of the protocol. > > IIRC, the OWDP-C in the draft is (close to) the mechanism > chosen by one of > the implementations and this is now being promoted to a standard. > However, there are other OWD implementations and they have > come up with > totally different OWDP-C's based on slightly different > requirements and > implementation choices. I would hesitate to say that this is being promoted to a standand as is, rather I think that the co-authors are calling for some feedback on it, but of course, the co-authors would be better able to say what the intention is at this time. Certainly, you are correct, that if the requirements were more clearly defined, then the implementation would be in the context of those requirements. Ideally, the implentation should be flexible and extensible so that new requirements could be added and the implementation could support them. For example, the TCP-packet format could be more flexible and extensible if a TLV approach was adopted (but this is another discussion :) My only point is that one control-method and one test- method is needed for an IETF standard (and for vendor inter-operability) and I will add that both the control-method and test-method should be based on a set of requirements which are agreed upon upfront. If other control-methods are incorporated in a single IETF standard, then what are vendors supposed to do? As a vendor, I do not want to support a bunch of control-methods, I just want to support one and know that I will be able to interoperate with other vendors that also support that standard. As I said before a different control-method may imply a different protocol (especially if the requirements were slightly different). If more than one protocol is developed due to different control-methods, that would be preferable than grouping multiple control-methods into a single IETF protocol. Thanks, -Joan > > Henk > > -------------------------------------------------------------- > ---------------- > Henk Uijterwaal Email: henk.uijterwaal@ripe.net > RIPE Network Coordination Centre WWW: > http://www.ripe.net/home/henk > Singel 258 Phone: +31.20.5354414 > 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands Mobile: +31.6.55861746 > -------------------------------------------------------------- > ---------------- > > As long as you don't tell your friends how I played the hand, > then I won't tell my friends how you defended it. > (Anonymous) > > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm > _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 5 13:08:26 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13233 for ; Mon, 5 Feb 2001 13:08:26 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f15I32h15801; Mon, 5 Feb 2001 13:03:02 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f15I29h15766 for ; Mon, 5 Feb 2001 13:02:09 -0500 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id NAA25856 for ; Mon, 5 Feb 2001 13:02:09 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id F09C9895; Mon, 5 Feb 2001 13:02:02 -0500 (EST) To: ippm@advanced.org Subject: Re: [ippm] draft-ietf-ippm-owdp: should it be split? References: From: stanislav shalunov Date: 05 Feb 2001 13:02:02 -0500 In-Reply-To: Message-ID: <87elxd2elh.fsf@cain.internet2.edu> Lines: 13 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List "Henk Uijterwaal (RIPE-NCC)" writes: > IIRC, the OWDP-C in the draft is (close to) the mechanism chosen by > one of the implementations and this is now being promoted to a > standard. Which implementation do you mean? Not Surveyor's as far as I know Surveyor's implementation. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Sex is the mathematics urge sublimated. -- M. C. Reed. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 5 19:48:36 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21385 for ; Mon, 5 Feb 2001 19:48:36 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f160f3h03371; Mon, 5 Feb 2001 19:41:03 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f160e1h03341 for ; Mon, 5 Feb 2001 19:40:02 -0500 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id TAA04592; Mon, 5 Feb 2001 19:40:02 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id 75EB8895; Mon, 5 Feb 2001 19:40:01 -0500 (EST) To: Henk Uijterwaal Cc: ippm@advanced.org Subject: Re: [ippm] draft-ietf-ippm-owdp: optional fields References: From: stanislav shalunov Date: 05 Feb 2001 19:40:01 -0500 In-Reply-To: Message-ID: <87ofwg1w66.fsf@cain.internet2.edu> Lines: 160 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List "Henk Uijterwaal (RIPE-NCC)" writes: > * Experimental error. > > This follows from RFC2330 which indicates that experimental errors > for OWD should be reported. Reporting errors becomes even more > important when OWD sessions can be set up between different devices > operated/manufactured by different organizations. (Typical example, > if one sync's his clock from a nearby NTP server, there will be a large > statistical error on the time compared to a situation where one has > a GPS receiver inside the device. These errors propagate into the > result, and should be quoted in order to fully appreciate the > final result for a OWD measurement). > > This number can be expressed using the same format as an NTP timestamp. What would this error bar tell us? The maximum possible error? Average error? Median error? Square root of average error square? 95th (90th, 99th) percentile of error? Instead of dealing with this ourselves, we decided that it makes sense to delegate precision definition to time protocol people in a way that does *not* imply that hosts are running NTP software: Sender Precision and Receiver Precision are signed integers in the range +32 to -32 indicating the precision of the corresponding clocks, in seconds to the nearest power of two, as described in RFC 958. Does this make sense to you? If it does, then your suggestion is to place this in every packet, optionally, rather than have it negotiated at setup time as clock property, right? > * Clock status. > This word should indicate whether the clock is sychronized or not. > This is typically necessary during startup and to detect experimental > problems. Synchronized to what in what sense? It'd be nice to avoid NTP-specific fields. > NTP use 13 bits for this, see /usr/local/include/time.h on your unix > box for the definition. /usr/include/time.h on my BSD machine doesn't have this information. Could you point me to a URL or specify your Unix flavor? > In order to accomodate other time keeping mechanisms, we could use > 1 word of the send message, and split that into a few bytes to > indicate the time keeping method, followed by 13 others if that's > NTP or N others for any other timekeeping mechanism. This suggests to me that the meaning of this field would be up to the application writers to determine, with only NTP-using implementations interoperating with each other. Doesn't look very good, if that's the case. Can you please clarify? > Page 6: "In unautheniticated mode, KID, ..." > but KID is only defined in the next paragraph "In unauthenticated mode, KID, Token, and Client-IV are unused" was my way of saying "pay no attention to fields called that on the diagram if mode is unauthenticated". Then the text proceeds to explain to to treat them in the next paragraph in the other two modes. Should these paragraphs be exchanged? > Page 6: The response message: I think the text should specify here > that YES==0 and NO != 0 The name of the field was changed from "Yes/No" to "Accept" in working version of the draft. Wording was changed to: A zero value in the Accept field means that the server accepts the authentication and is willing to conduct further transactions. Any non-zero value means that the server does not accept the authentication provided by the client or, for some other reason, is not willing to conduct further transactions in this OWDP-Control session. > Page 8/9, creating sessions: > I'm not sure how the sender can say anything about the receiver > precision during setup of a session. I think not: Sender Precision is meaningful only if Conf-Sender is not set. Receiver Precision is meaningful only if Conf-Receiver is not set. > Related to this, precision may vary during a session as > clocks tend to drift. That's (my interpretation) of your first suggestion. > Packet length: this does not seem to deal with sessions where > one sends packets of varying length. No, it doesn't. Shall we insert a way to specify a Turing machine that will output the required sequence of packet lengths? :-) I think this, and non-Poisson distributions, lie in the realm of extension once we have a working protocol. > Packets: there should a value for infinite. This will complicate session results retrieval quite a bit. At the moment, you complete the session and get the results (which, in particular, serves the purposes of non-disturbing test in progress by control part of the protocol). If you have sessions with infinite numbers of packets, I'd say you should no longer be able to retrieve their results. Is that what you mean, too? > Page 11/12: Why do the 1st and 3rd message have a specific value in the > first 8 bytes, while the second 1 only has 0 or non-zero. > Wouldn't it be easier to simply use values for the different > messages (for example 1=start, 2=ack, 3=stop, 4=... ). The specific values are commands, the zero/non-zero values are yes/no responses. The intention is to be able to specify later a number of (non-zero) error codes that would give a clue as to what happened. It's probably premature to do it now, but hooks for doing it are in the draft. (Only add a new section.) > Page 16: Shouldn't we specify that the sequence numbers increase by 1? I somehow thought that "sequence number" has this meaning already, but I guess it wouldn't hurt to say it explicitly. Thanks! Does "Sequence numbers start with 0 and are incremented by 1 for each subsequent packet." sound good? > Page 18: RFC958 is obsolete and has been replaced by 1305. Yuck. Sorry about this. All references are changed. > Page 19: " [RIPE] Ripe Test-Traffic home... " should be > " [RIPE] RIPE NCC Test-TRaffic Measurements home..." Corrected. Thank you. > Page 19: [RIPE-NLUUG] : The URL should be: > > http://www.ripe.net/test-traffic/Talks/9805_nluug.ps.gz Corrected. Thank you. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "The power of accurate observation is commonly called cynicism by those who have not got it." -- G. B. Shaw _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Feb 6 05:11:57 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10536 for ; Tue, 6 Feb 2001 05:11:57 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f16A72h22879; Tue, 6 Feb 2001 05:07:02 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f16A5xh22853 for ; Tue, 6 Feb 2001 05:06:30 -0500 Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id LAA16369; Tue, 6 Feb 2001 11:05:51 +0100 (CET) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id LAA10096; Tue, 6 Feb 2001 11:05:51 +0100 (CET) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Tue, 6 Feb 2001 11:05:51 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: stanislav shalunov cc: Subject: Re: [ippm] draft-ietf-ippm-owdp: optional fields In-Reply-To: <87ofwg1w66.fsf@cain.internet2.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List On 5 Feb 2001, stanislav shalunov wrote: > "Henk Uijterwaal (RIPE-NCC)" writes: > > > * Experimental error. > > > > This follows from RFC2330 which indicates that experimental errors > > for OWD should be reported. Reporting errors becomes even more > > important when OWD sessions can be set up between different devices > > operated/manufactured by different organizations. (Typical example, > > if one sync's his clock from a nearby NTP server, there will be a large > > statistical error on the time compared to a situation where one has > > a GPS receiver inside the device. These errors propagate into the > > result, and should be quoted in order to fully appreciate the > > final result for a OWD measurement). > > > > This number can be expressed using the same format as an NTP timestamp. > > What would this error bar tell us? The standard deviation of the distribution that one would get when taking a large number of samples from this clock and comparing them to an (imaginary) absolute time source. From that, one can always and easily calculate percentiles (95th is about 2 sigma, 99 is about 3) as well as any other quantity. > The maximum possible error? This is infinite by definition or perhaps 2^32 seconds in a 32 bit world. > Instead of dealing with this ourselves, we decided that it makes sense > to delegate precision definition to time protocol people in a way that > does *not* imply that hosts are running NTP software: > > Sender Precision and Receiver Precision are signed integers in the > range +32 to -32 indicating the precision of the corresponding > clocks, in seconds to the nearest power of two, as described in > RFC 958. > > Does this make sense to you? RFC958 is obsolete and replaced by 1305. But besides that, yes, I don't think that we should assume that people use NTP, but just indicate how accurate one thinks the clock is. > If it does, then your suggestion is to place this in every packet, > optionally, rather than have it negotiated at setup time as clock > property, right? Yes, of course, as it can vary from one measurement to another. A typical scenario when switching on a GPS device is, is that it doesn't have a clue what the time is and hence has a large error. When it picks up a satellite, the error is reduced to something of the order of 0.5 seconds. When it starts to see more satellites, the error drops dramatically again when it gets are rough guess of the position, then continues to improve when it can do a better determination of the position of the receiver eventually reaching something like 100ns. The error may go up again if the receiver loses sight of some of the satellites, then back down when it picks up another satellite. These fluctuations can happen in a matter of minutes, so any error negoatiated at setup is valid for at most 1 minute. > > * Clock status. > > This word should indicate whether the clock is sychronized or not. > > This is typically necessary during startup and to detect experimental > > problems. > > Synchronized to what in what sense? It'd be nice to avoid > NTP-specific fields. "Synchronized to an external time-source" or more general "reliable". What one sees in practice, is that people cut antenna cables from GPS receivers, filter on NTP packets to a nearby stratum-1, pull the plug from their DCF77 receivers, etc, etc. At this point, the measurements become unreliable, even though the mechanism for doing them might still work. What I propose is a work to record the clock status, so, after the data has been collected, one can easily reject measurements where one suspects problems with the hardware. The alternative would be to stop the measurements as soon as sender or receiver suspects a clock problem, but then one cannot use the same data to measure packet loss continously _and_ one has to go through a setup cycle for every small hickup. > > NTP use 13 bits for this, see /usr/local/include/time.h on your unix > > box for the definition. > > /usr/include/time.h on my BSD machine doesn't have this information. > Could you point me to a URL or specify your Unix flavor? Linux, FreeBSD. > > > In order to accomodate other time keeping mechanisms, we could use > > 1 word of the send message, and split that into a few bytes to > > indicate the time keeping method, followed by 13 others if that's > > NTP or N others for any other timekeeping mechanism. > > This suggests to me that the meaning of this field would be up to the > application writers to determine, with only NTP-using implementations > interoperating with each other. Doesn't look very good, if that's the > case. No, all I'm saying is N bits for "time keeping mechanism", (32-N) for the clock status, say, with N=3 0 1 2 3 4 5 6 7 ... 32 0 0 1 .... NTP, with 3..16 the NTP bits 0 1 0 ... Read GPS receiver over the bus, with 3..8 the number of sats seens ... when analyzing the data, one looks for the first 3 bits, then decides if the clock reliable. > > Page 6: "In unautheniticated mode, KID, ..." > > but KID is only defined in the next paragraph > > "In unauthenticated mode, KID, Token, and Client-IV are unused" was my > way of saying "pay no attention to fields called that on the diagram > if mode is unauthenticated". > > Then the text proceeds to explain to to treat them in the next > paragraph in the other two modes. > > Should these paragraphs be exchanged? I generally don't like abbreviations to appear before their definition. > That's (my interpretation) of your first suggestion. > > > Packet length: this does not seem to deal with sessions where > > one sends packets of varying length. > > No, it doesn't. Shall we insert a way to specify a Turing machine > that will output the required sequence of packet lengths? :-) > > I think this, and non-Poisson distributions, lie in the realm of > extension once we have a working protocol. OK. > > > Packets: there should a value for infinite. > > This will complicate session results retrieval quite a bit. At the > moment, you complete the session and get the results (which, in > particular, serves the purposes of non-disturbing test in progress by > control part of the protocol). > > If you have sessions with infinite numbers of packets, I'd say you > should no longer be able to retrieve their results. Is that what you > mean, too? This is what we do at the moment: sender starts sending, receiver starts receiving, and once a day we collect what was sent in the last day. The receiver software writes the data to a dffirent file each day, but we don't see why one should stop the measurement for that. > > Page 11/12: Why do the 1st and 3rd message have a specific value in the > > first 8 bytes, while the second 1 only has 0 or non-zero. > > Wouldn't it be easier to simply use values for the different > > messages (for example 1=start, 2=ack, 3=stop, 4=... ). > > The specific values are commands, the zero/non-zero values are yes/no > responses. The intention is to be able to specify later a number of > (non-zero) error codes that would give a clue as to what happened. > > It's probably premature to do it now, but hooks for doing it are in > the draft. (Only add a new section.) OK > > Page 16: Shouldn't we specify that the sequence numbers increase by 1? > > I somehow thought that "sequence number" has this meaning already, but > I guess it wouldn't hurt to say it explicitly. Thanks! > > Does "Sequence numbers start with 0 and are incremented by 1 for each > subsequent packet." sound good? Yes. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Feb 6 05:13:02 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10556 for ; Tue, 6 Feb 2001 05:13:01 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f16A92h22964; Tue, 6 Feb 2001 05:09:02 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f16A8Lh22929 for ; Tue, 6 Feb 2001 05:08:21 -0500 Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id LAA17255 for ; Tue, 6 Feb 2001 11:08:23 +0100 (CET) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id LAA10101 for ; Tue, 6 Feb 2001 11:08:23 +0100 (CET) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Tue, 6 Feb 2001 11:08:23 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Subject: Re: [ippm] draft-ietf-ippm-owdp: should it be split? In-Reply-To: <87elxd2elh.fsf@cain.internet2.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List On 5 Feb 2001, stanislav shalunov wrote: > "Henk Uijterwaal (RIPE-NCC)" writes: > > > IIRC, the OWDP-C in the draft is (close to) the mechanism chosen by > > one of the implementations and this is now being promoted to a > > standard. > > Which implementation do you mean? Not Surveyor's as far as I know > Surveyor's implementation. No? I know Sunil or Matt described Surveyor's setup mechanism somewhere, a long time ago and OWDP-C looked remarkably like what I remember from that. My memory must be worse that I thought ;-) Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Feb 6 15:11:53 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00351 for ; Tue, 6 Feb 2001 15:11:53 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f16K93h19592; Tue, 6 Feb 2001 15:09:03 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f16K8dh19552 for ; Tue, 6 Feb 2001 15:08:39 -0500 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id PAA22906 for ; Tue, 6 Feb 2001 15:08:40 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id F40EE895; Tue, 6 Feb 2001 15:08:34 -0500 (EST) To: ippm@advanced.org Subject: Re: [ippm] draft-ietf-ippm-owdp: should it be split? References: From: stanislav shalunov Date: 06 Feb 2001 15:08:34 -0500 In-Reply-To: Message-ID: <87hf27zi9p.fsf@cain.internet2.edu> Lines: 20 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List "Henk Uijterwaal (RIPE-NCC)" writes: > No? I know Sunil or Matt described Surveyor's setup mechanism > somewhere, a long time ago and OWDP-C looked remarkably like what I > remember from that. Surveyor depends on issuing shell commands through SSH, depends on system PRNG being the same on all hosts, has no authentication/encryption aside from what is passed through SSH, does data collection out-of-band, allows no open mode, etc., etc., etc. If similarities exist, they are coincidental--if you're doing the same simple thing it's possible the method will be somewhat similar to one of the existing models. -- 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@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Feb 6 15:17:30 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00645 for ; Tue, 6 Feb 2001 15:17:24 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f16KF3h20061; Tue, 6 Feb 2001 15:15:03 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f16KEOh20022 for ; Tue, 6 Feb 2001 15:14:24 -0500 Received: from kantoor.ripe.net (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id VAA12924 for ; Tue, 6 Feb 2001 21:14:26 +0100 (CET) Received: from localhost (henk@localhost) by kantoor.ripe.net (8.8.8/8.8.5) with ESMTP id VAA11310 for ; Tue, 6 Feb 2001 21:14:26 +0100 (CET) X-Authentication-Warning: kantoor.ripe.net: henk owned process doing -bs Date: Tue, 6 Feb 2001 21:14:26 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Subject: Re: [ippm] draft-ietf-ippm-owdp: should it be split? In-Reply-To: <87hf27zi9p.fsf@cain.internet2.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List On 6 Feb 2001, stanislav shalunov wrote: > "Henk Uijterwaal (RIPE-NCC)" writes: > > > No? I know Sunil or Matt described Surveyor's setup mechanism > > somewhere, a long time ago and OWDP-C looked remarkably like what I > > remember from that. > > Surveyor depends on issuing shell commands through SSH, depends on > system PRNG being the same on all hosts, has no > authentication/encryption aside from what is passed through SSH, does > data collection out-of-band, allows no open mode, etc., etc., etc. > > If similarities exist, they are coincidental--if you're doing the same > simple thing it's possible the method will be somewhat similar to one > of the existing models. OK, you win! Ignore my comment. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Feb 6 16:08:30 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02023 for ; Tue, 6 Feb 2001 16:08:30 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f16L73h23581; Tue, 6 Feb 2001 16:07:04 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f16L6Fh23535 for ; Tue, 6 Feb 2001 16:06:36 -0500 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id QAA24376 for ; Tue, 6 Feb 2001 16:06:06 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id 3CBAE895; Tue, 6 Feb 2001 16:06:03 -0500 (EST) To: ippm@advanced.org Subject: Re: [ippm] draft-ietf-ippm-owdp: optional fields References: From: stanislav shalunov Date: 06 Feb 2001 16:06:03 -0500 In-Reply-To: Message-ID: <87elxbzflw.fsf@cain.internet2.edu> Lines: 95 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List "Henk Uijterwaal (RIPE-NCC)" writes: > > What would this error bar tell us? > > The standard deviation of the distribution that one would get when > taking a large number of samples from this clock and comparing them > to an (imaginary) absolute time source. From that, one can always > and easily calculate percentiles (95th is about 2 sigma, 99 is about > 3) as well as any other quantity. Assuming you have Gaussian distribution of errors with no systematic error, this is true. One may argue why externally NTP-synchronized clocks would have Gaussian distribution of errors in case of symmetric routing, but in general it doesn't have to be true. For example, I very much doubt that reading GPS hardware or using locally GPS-synchronized clock would give you that. And, of course you can have unknown systematic errors (e.g., with CDMA time sources). > > The maximum possible error? > This is infinite by definition or perhaps 2^32 seconds in a 32 bit world. By definition of what? If you have local GPS hardware that gives you time with resolution of 1ms, you very much have maximum error. This is not to say that you won't have standard deviation for whatever distribution of errors you have. The points are that * no single parameter describes errors adequately (such description, even if errors are independent, would require an R->R extended function); * you may not know what your error distribution is (but usually have a rough idea about their order of magnitude). > RFC958 is obsolete and replaced by 1305. All references replaced per your previous message. > But besides that, yes, I don't think that we should assume that > people use NTP, but just indicate how accurate one thinks the clock > is. Do you think that what NTP calls precision is sufficient for this purpose? That's what we have now (per session, not per packet as you ask for). > "Synchronized to an external time-source" or more general "reliable". This looks like 1 bit of information to me rather than 13 or 32 bits. Should we think about it as conveying 1 bit? ("I think I have time that something external to me, such as a GPS receiver or NTP server, claims to be UTC.") > > > /usr/local/include/time.h > > /usr/include/time.h on my BSD machine doesn't have this information. > > Could you point me to a URL or specify your Unix flavor? > Linux, FreeBSD. Since FreeBSD uses /usr/local for non-system software, and Linux uses it for non-packaged software, this is likely some file you have installed on your systems. How about 1 bit, though? > No, all I'm saying is N bits for "time keeping mechanism", (32-N) for > the clock status, say, with N=3 > > 0 1 2 3 4 5 6 7 ... 32 > 0 0 1 .... NTP, with 3..16 the NTP bits > 0 1 0 ... Read GPS receiver over the bus, with > 3..8 the number of sats seens > ... > > when analyzing the data, one looks for the first 3 bits, then decides > if the clock reliable. We'd need a rather long list of potential time sources this way, wouldn't we? What if it's timeslave? Local CDMA? Timed to NTP server? GPS over serial with NMEA? And so forth... > This is what we do at the moment: sender starts sending, receiver starts > receiving, and once a day we collect what was sent in the last day. The > receiver software writes the data to a dffirent file each day, but we > don't see why one should stop the measurement for that. Let us think more about implications of infinite irretrievable sessions for a day or two. Thanks a lot for all the comments! -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "Nuclear war would really set back cable [television]." -- Ted Turner _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Feb 6 17:06:57 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03381 for ; Tue, 6 Feb 2001 17:06:57 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f16M23h26831; Tue, 6 Feb 2001 17:02:03 -0500 Received: from orc.cs.waikato.ac.nz (orc.cs.waikato.ac.nz [130.217.241.22]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f16M1Ah26789 for ; Tue, 6 Feb 2001 17:01:10 -0500 Received: from orca.cs.waikato.ac.nz ([130.217.244.4] helo=cs.waikato.ac.nz ident=sfd) by orc.cs.waikato.ac.nz with esmtp (Exim 3.16 #6) id 14QGAb-0005Cl-00 for ippm@advanced.org; Wed, 07 Feb 2001 11:01:05 +1300 Message-ID: <3A807421.11422C00@cs.waikato.ac.nz> Date: Wed, 07 Feb 2001 11:01:05 +1300 From: Stephen Donnelly Organization: The University of Waikato X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org Subject: Re: [ippm] draft-ietf-ippm-owdp: optional fields References: <87elxbzflw.fsf@cain.internet2.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit stanislav shalunov wrote: > > > The maximum possible error? > > > This is infinite by definition or perhaps 2^32 seconds in a 32 bit world. > > By definition of what? If you have local GPS hardware that gives you > time with resolution of 1ms, you very much have maximum error. Sure, until lightning hits it, or the UPS it's on fails, or there aren't enough satellites above the horizon, or someone unplugs the patch acble to it. These things all happen in practice, so there's no such thing as a maximum error of 1ms, whatever the manufacturer says. > > This is what we do at the moment: sender starts sending, receiver starts > > receiving, and once a day we collect what was sent in the last day. The > > receiver software writes the data to a dffirent file each day, but we > > don't see why one should stop the measurement for that. > > Let us think more about implications of infinite irretrievable > sessions for a day or two. Why should it bwe irretreviable? Henk just indicated that it need not be. Why should data be retrieved only after a measurement 'session' has been shut down? What if you want some kind of 'near real time' monitoring/display of delay? Stephen. -- ----------------------------------------------------------------------- Stephen Donnelly (BCMS) email: sfd@cs.waikato.ac.nz WAND Group Room GG.15 phone +64 7 838 4086 Computer Science Department, University of Waikato, New Zealand ----------------------------------------------------------------------- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Feb 6 17:20:12 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03743 for ; Tue, 6 Feb 2001 17:20:12 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f16MJ4h27708; Tue, 6 Feb 2001 17:19:04 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f16MIfh27667 for ; Tue, 6 Feb 2001 17:18:44 -0500 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id RAA25859 for ; Tue, 6 Feb 2001 17:18:43 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id 0936B895; Tue, 6 Feb 2001 17:18:41 -0500 (EST) To: ippm@advanced.org Subject: Re: [ippm] draft-ietf-ippm-owdp: continuous sessions References: <87elxbzflw.fsf@cain.internet2.edu> <3A807421.11422C00@cs.waikato.ac.nz> From: stanislav shalunov Date: 06 Feb 2001 17:18:41 -0500 In-Reply-To: <3A807421.11422C00@cs.waikato.ac.nz> Message-ID: <87bssfzc8u.fsf_-_@cain.internet2.edu> Lines: 31 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Stephen Donnelly writes: > Why should it bwe irretreviable? What I meant to say, irretrievable by means of OWDP-Control, unless one wants to allow partial retrivals in a separate session. This would naturally mean decreased robustness (how many losses occured after the last packet?) > Why should data be retrieved only after a measurement 'session' has > been shut down? The motivation to do this would be to be able to ensure complete transmission of session results, and to distinguish losses due to host failures from losses due to network conditions. (I was recording this session which was supposed to have 1000 packets in it. Last packet I have seen was packet number 564, with a total of 532. Were packets 565-999 dropped by the network or did my peer crash?) > What if you want some kind of 'near real time' monitoring/display of > delay? You'd run short sessions. (Or, at least, that was the understanding of how it would work.) -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Beware of Programmers who carry screwdrivers. -- Leonard Brandwein _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Feb 6 17:46:34 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04116 for ; Tue, 6 Feb 2001 17:46:34 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f16Mj4h29281; Tue, 6 Feb 2001 17:45:04 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f16Mith29252 for ; Tue, 6 Feb 2001 17:44:56 -0500 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id RAA26440 for ; Tue, 6 Feb 2001 17:44:58 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id 97439895; Tue, 6 Feb 2001 17:44:56 -0500 (EST) To: ippm@advanced.org Subject: Re: [ippm] draft-ietf-ippm-owdp: optional fields References: <87elxbzflw.fsf@cain.internet2.edu> <3A807421.11422C00@cs.waikato.ac.nz> From: stanislav shalunov Date: 06 Feb 2001 17:44:56 -0500 In-Reply-To: <3A807421.11422C00@cs.waikato.ac.nz> Message-ID: <878znjzb13.fsf@cain.internet2.edu> Lines: 22 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Stephen Donnelly writes: > Sure, until lightning hits it, or the UPS it's on fails, or there aren't > enough satellites above the horizon, or someone unplugs the patch acble > to it. These would all be covered by unsynchronized case. Presumably, whatever you use for your error estimate parameter(s) would be discarded when not synchronized. > These things all happen in practice, so there's no such thing as > a maximum error of 1ms, whatever the manufacturer says. How do you propose the software implementing the protocol would deal with broken equipment that claims it's synchronized when it's not? And how having 1 or 1000 parameters describing the errors would change the situation? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "Nuclear war can ruin your whole compile." -- Karl Lehenbauer _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Feb 7 03:47:21 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA26809 for ; Wed, 7 Feb 2001 03:47:21 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f178k3h18810; Wed, 7 Feb 2001 03:46:03 -0500 Received: from plinius.intec2.rug.ac.be (plinius.intec2.rug.ac.be [157.193.122.4]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f178jMh18775 for ; Wed, 7 Feb 2001 03:45:23 -0500 Received: from intec.rug.ac.be (daisne.intec2.rug.ac.be [157.193.122.92]) by plinius.intec2.rug.ac.be (Postfix) with ESMTP id 8ED0EEEAB; Wed, 7 Feb 2001 09:45:03 +0100 (CET) Message-ID: <3A810B0F.613B6C50@intec.rug.ac.be> Date: Wed, 07 Feb 2001 09:45:03 +0100 From: Steven Van den Berghe X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.3.99-pre9 i686) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org Subject: Re: [ippm] draft-ietf-ippm-owdp: continuous sessions References: <87elxbzflw.fsf@cain.internet2.edu> <3A807421.11422C00@cs.waikato.ac.nz> <87bssfzc8u.fsf_-_@cain.internet2.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit stanislav shalunov wrote: > Stephen Donnelly writes: > > > > What if you want some kind of 'near real time' monitoring/display of > > delay? > > You'd run short sessions. (Or, at least, that was the understanding > of how it would work.) > Is the overhead of setting up and tearing down sessions not too much a burdon here? An 'intermediate result retrieval function' would imho not complicate the protocol too much (the only extra state needed in the control level would be a pointer to the last result transmitted to the client) and the request of intermediate results to the control plane would also detect host faillures. Steven -- Steven Van den Berghe steven.vandenberghe@intec.rug.ac.be Workgroup Broadband-Networks Department Information Technology Ghent University - Belgium Phone: +32 (0)9 267 35 86 | Fax : +32 (0)9 267 35 99 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Feb 7 04:39:06 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27183 for ; Wed, 7 Feb 2001 04:39:06 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f179b2h20734; Wed, 7 Feb 2001 04:37:02 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f179ach20706 for ; Wed, 7 Feb 2001 04:36:38 -0500 Received: from kantoor.ripe.net (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id KAA05904 for ; Wed, 7 Feb 2001 10:36:40 +0100 (CET) Received: from localhost (henk@localhost) by kantoor.ripe.net (8.8.8/8.8.5) with ESMTP id KAA10732 for ; Wed, 7 Feb 2001 10:36:40 +0100 (CET) X-Authentication-Warning: kantoor.ripe.net: henk owned process doing -bs Date: Wed, 7 Feb 2001 10:36:40 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: ippm@advanced.org Subject: Re: [ippm] draft-ietf-ippm-owdp: continuous sessions In-Reply-To: <87bssfzc8u.fsf_-_@cain.internet2.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List On 6 Feb 2001, stanislav shalunov wrote: > > Why should data be retrieved only after a measurement 'session' has > > been shut down? > > The motivation to do this would be to be able to ensure complete > transmission of session results, and to distinguish losses due to host > failures from losses due to network conditions. > > (I was recording this session which was supposed to have 1000 packets > in it. Last packet I have seen was packet number 564, with a total of > 532. Were packets 565-999 dropped by the network or did my peer > crash?) You don't know, but that doesn't mean that you cannot already do something useful with the 532 packets that you did receive. For those 532 points, you can report that packet loss is at least 32/564 = 6% and a distribution of the delays during the time that data came in. For operational purposes, this is already quite useful even though it is clearly insufficient data for a full scientific analysis. > > What if you want some kind of 'near real time' monitoring/display of > > delay? > > You'd run short sessions. (Or, at least, that was the understanding > of how it would work.) I don't think that this will work due to the overhead being involved. What I noticed from looking at the data, is that 10 to 20 minutes worth of data is often enough to see that something changed on the network that cannot be attributed to a statistical fluke or a user overloading the line. This can be used for network monitoring systems. However, I would not want to restart all 50 measurements sessions that I have running on a node every 10 minutes. At the moment, setting up all those 50 sessions takes of the order of a minute, so this would translate into a dead-time of O(10)%. But for a measurement device, I typically think about dead-times of O(0.1)% or less. I'm sure that some optimalization can be done, but I doubt that one can gain 2 orders of magnitude here. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Feb 7 05:04:17 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA27331 for ; Wed, 7 Feb 2001 05:04:17 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f17A23h21784; Wed, 7 Feb 2001 05:02:03 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f17A1Zh21758 for ; Wed, 7 Feb 2001 05:01:36 -0500 Received: from kantoor.ripe.net (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id LAA12204 for ; Wed, 7 Feb 2001 11:01:37 +0100 (CET) Received: from localhost (henk@localhost) by kantoor.ripe.net (8.8.8/8.8.5) with ESMTP id LAA13698 for ; Wed, 7 Feb 2001 11:01:37 +0100 (CET) X-Authentication-Warning: kantoor.ripe.net: henk owned process doing -bs Date: Wed, 7 Feb 2001 11:01:37 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: ippm@advanced.org Subject: Re: [ippm] draft-ietf-ippm-owdp: optional fields In-Reply-To: <87elxbzflw.fsf@cain.internet2.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List On 6 Feb 2001, stanislav shalunov wrote: > "Henk Uijterwaal (RIPE-NCC)" writes: > > > > What would this error bar tell us? > > > > The standard deviation of the distribution that one would get when > > taking a large number of samples from this clock and comparing them > > to an (imaginary) absolute time source. From that, one can always > > and easily calculate percentiles (95th is about 2 sigma, 99 is about > > 3) as well as any other quantity. > > Assuming you have Gaussian distribution of errors with no systematic > error, this is true. One may argue why externally NTP-synchronized > clocks would have Gaussian distribution of errors in case of symmetric > routing, but in general it doesn't have to be true. Then you should report 2 errors: statistical and systematic. > > > The maximum possible error? > > > This is infinite by definition or perhaps 2^32 seconds in a 32 bit world. > > By definition of what? If you have local GPS hardware that gives you > time with resolution of 1ms, you very much have maximum error. No, this only applies in a specific case: it has seen enough satellites to determine its position for a while and it had time to stabilize its internal PLL. If the same receiver sees only 1 satellite, after just being switched on, the error can be larger, even if the manufacturers of the devices claim otherwise. > > But besides that, yes, I don't think that we should assume that > > people use NTP, but just indicate how accurate one thinks the clock > > is. > > Do you think that what NTP calls precision is sufficient for this > purpose? That's what we have now (per session, not per packet as you > ask for). I think the NTP error estimates are sufficient (or at least the best we have). Per session is insufficient, as the error estimates can change rapidly. > > "Synchronized to an external time-source" or more general "reliable". > > This looks like 1 bit of information to me rather than 13 or 32 bits. > Should we think about it as conveying 1 bit? ("I think I have time > that something external to me, such as a GPS receiver or NTP server, > claims to be UTC.") > > > > /usr/local/include/time.h > > > /usr/include/time.h on my BSD machine doesn't have this information. > > > Could you point me to a URL or specify your Unix flavor? > > > Linux, FreeBSD. > > Since FreeBSD uses /usr/local for non-system software, and Linux uses > it for non-packaged software, this is likely some file you have > installed on your systems. How about 1 bit, though? > > > No, all I'm saying is N bits for "time keeping mechanism", (32-N) for > > the clock status, say, with N=3 > > > > 0 1 2 3 4 5 6 7 ... 32 > > 0 0 1 .... NTP, with 3..16 the NTP bits > > 0 1 0 ... Read GPS receiver over the bus, with > > 3..8 the number of sats seens > > ... > > > > when analyzing the data, one looks for the first 3 bits, then decides > > if the clock reliable. > > We'd need a rather long list of potential time sources this way, > wouldn't we? What if it's timeslave? Local CDMA? Timed to NTP > server? GPS over serial with NMEA? And so forth... Yes, true. But, when something goes wrong, I'd like to be able to check what went wrong. So how about: bit 0 : 0/1 for clock sync'ed or unsync'ed bit 1 : 0/1 for additional data bit 2.. : additional data. For a quick look, look at bit 0. If you want to debug, look at bit 1. If the sender included data, then it will be set and you can debug. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Feb 7 11:22:27 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02813 for ; Wed, 7 Feb 2001 11:22:26 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f17GH3h06124; Wed, 7 Feb 2001 11:17:03 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f17GG5h06048 for ; Wed, 7 Feb 2001 11:16:05 -0500 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id LAA13615 for ; Wed, 7 Feb 2001 11:16:08 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id E8B18895; Wed, 7 Feb 2001 11:16:06 -0500 (EST) To: ippm@advanced.org Subject: Re: [ippm] draft-ietf-ippm-owdp: continuous sessions References: <87elxbzflw.fsf@cain.internet2.edu> <3A807421.11422C00@cs.waikato.ac.nz> <87bssfzc8u.fsf_-_@cain.internet2.edu> <3A810B0F.613B6C50@intec.rug.ac.be> From: stanislav shalunov Date: 07 Feb 2001 11:16:06 -0500 In-Reply-To: <3A810B0F.613B6C50@intec.rug.ac.be> Message-ID: <87d7cuxyd5.fsf@cain.internet2.edu> Lines: 14 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Steven Van den Berghe writes: > the request of intermediate results to the control plane would also > detect host faillures. Not really, since you'd be talking to one host and another host might have failed. (E.g., sender failed, you're retrieving the results from the receiver; situation becomes even worse if the five logical roles are spread among five hosts.) -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "Which one is worse? Both are worse." -- V. I. Lenin _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Feb 7 11:50:26 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03434 for ; Wed, 7 Feb 2001 11:50:26 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f17Gl5x09824; Wed, 7 Feb 2001 11:47:05 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f17Gkkx09764 for ; Wed, 7 Feb 2001 11:46:46 -0500 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id LAA15361 for ; Wed, 7 Feb 2001 11:46:48 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id 77D6F895; Wed, 7 Feb 2001 11:46:47 -0500 (EST) To: ippm@advanced.org Subject: Re: [ippm] draft-ietf-ippm-owdp: optional fields References: From: stanislav shalunov Date: 07 Feb 2001 11:46:47 -0500 In-Reply-To: Message-ID: <87ae7yxwy0.fsf@cain.internet2.edu> Lines: 73 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List "Henk Uijterwaal (RIPE-NCC)" writes: > Then you should report 2 errors: statistical and systematic. I don't think it would work; if you know your systematic error the best way to "report" it would be to subtract it from the timestamps. > No, this only applies in a specific case: it has seen enough satellites to > determine its position for a while and it had time to stabilize its > internal PLL. If the same receiver sees only 1 satellite, after just > being switched on, the error can be larger, even if the manufacturers of > the devices claim otherwise. The hardware that I am familiar with indicates whether it is synchronized (knows its position, and, therefore, time). It might not say whether it is synced in 2D or 3D mode (with 3 or 4 satellites), but for static (in space) computers it is not really an issue. > I think the NTP error estimates are sufficient (or at least the best we > have). Per session is insufficient, as the error estimates can change > rapidly. NTP provides your implementation with error estimates. I assume you mean the dispersion to the server you are synchronized to. This dispersion has some value to it, but it's far from being a real error estimate. E.g., when NTP software on Abilene Surveyors indicates 10-50us dispersion, it can typically be off by as much as 200us (and this is under network conditions that are probably as good as it can get for NTP). Further, while NTP at least gives you some numbers (good or bad) many other mechanisms might not give you that. I don't understand what you would do in these situations. Further, since these error estimates will inevitably be generated using completely different means you'd end up comparing apples to oranges. You suggest having one parameter for measuring errors. What if somebody came and suggested to put dispersion, median, maximum error, third momentum, fourth momentum, 50th percentile, and 95th percentile? In general, these are all independent error characterizations. We have to draw the line somewhere. And it should be drawn in such a way that it does not favor one specific implementation of time synchronization (NTP) at the expense of others. That is why we have (rough) precision rather than some more elaborate scheme. Would you be satisfied with this precision information (-32..32) in each packet, optionally (or mandatory if space permits)? > But, when something goes wrong, I'd like to be able to check what went > wrong. So how about: > > bit 0 : 0/1 for clock sync'ed or unsync'ed > bit 1 : 0/1 for additional data > bit 2.. : additional data. > > For a quick look, look at bit 0. If you want to debug, look at bit 1. If > the sender included data, then it will be set and you can debug. Do we assign meaning to the additional bits or is it an opaque/proprietary field? If we assign meaning to them, it must not be NTP-specific. If we keep an opaque field, it would naturally hinder inter-operability between different vendors. ("Hmm, it *says* it's not synced in the first bit, but this further data tells me time is actually OK. Let's trust it. [...] Oh wait, I didn't know we're not talking to the same implementation!") What did you have in mind? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "Nuclear war can ruin your whole compile." -- Karl Lehenbauer _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Feb 7 12:38:25 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04503 for ; Wed, 7 Feb 2001 12:38:24 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f17Hb3s20653; Wed, 7 Feb 2001 12:37:03 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f17Ha1s20563 for ; Wed, 7 Feb 2001 12:36:02 -0500 Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id SAA20546 for ; Wed, 7 Feb 2001 18:36:03 +0100 (CET) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id SAA03737 for ; Wed, 7 Feb 2001 18:36:03 +0100 (CET) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Wed, 7 Feb 2001 18:36:02 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: ippm@advanced.org Subject: Re: [ippm] draft-ietf-ippm-owdp: optional fields In-Reply-To: <87ae7yxwy0.fsf@cain.internet2.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List > > Then you should report 2 errors: statistical and systematic. > > I don't think it would work; if you know your systematic error the > best way to "report" it would be to subtract it from the timestamps. That is not an error but the calibration of your device. > > I think the NTP error estimates are sufficient (or at least the best we > > have). Per session is insufficient, as the error estimates can change > > rapidly. > > NTP provides your implementation with error estimates. I assume you > mean the dispersion to the server you are synchronized to. No, why? I meant the error estimate on the PLL that NTP gives you, after it has gone through all its filtering steps and whatever else it does to extract the correct time. > Further, while NTP at least gives you some numbers (good or bad) many > other mechanisms might not give you that. > > I don't understand what you would do in these situations. My physics background tells me that I shouldn't do a measurement then. RFC2330 seems to confirm this. What I basically ask is for two things: a time and the best estimate of the error on that time that the source can give me. When calculating the delay, I can then use standard techniques to calculate an error on the overall result and thus have some indication on how reliable my final result is. > Further, since these error estimates will inevitably be generated > using completely different means you'd end up comparing apples to > oranges. This happens all the time and is never a problem. You ask for a well defined number and the owner of the clock reports it. > You suggest having one parameter for measuring errors. What if > somebody came and suggested to put dispersion, median, maximum error, > third momentum, fourth momentum, 50th percentile, and 95th percentile? I'm asking for one which is reported in about every other paper and from which the others can be derived, and which is also a de-facto world-wide standard. > > But, when something goes wrong, I'd like to be able to check what went > > wrong. So how about: > > > > bit 0 : 0/1 for clock sync'ed or unsync'ed > > bit 1 : 0/1 for additional data > > bit 2.. : additional data. > > > > For a quick look, look at bit 0. If you want to debug, look at bit 1. If > > the sender included data, then it will be set and you can debug. > > Do we assign meaning to the additional bits or is it an > opaque/proprietary field? If we assign meaning to them, it must not > be NTP-specific. If we keep an opaque field, it would naturally > hinder inter-operability between different vendors. ("Hmm, it *says* > it's not synced in the first bit, but this further data tells me time > is actually OK. Let's trust it. [...] Oh wait, I didn't know we're > not talking to the same implementation!") This cannot happen: Bit 0 is set based on a time sync'ed/un-sync'ed decision by the sender, based on the information in the other words, so it is impossible to have a situation where it says that it is not sync'ed but where the data says otherwise. Bit's 1 and further are intended for debugging. If the source is under my control, I know which implementation is running there and thus what the meaning of the bit is. If the source is not under my control, I might report the error to the owner of the source but there is nothing I can do to debug it. Thus, I don't care which implementation is used there and what the bits mean. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Feb 7 22:49:28 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17030 for ; Wed, 7 Feb 2001 22:49:27 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f183g3m24066; Wed, 7 Feb 2001 22:42:03 -0500 Received: from orc.cs.waikato.ac.nz (orc.cs.waikato.ac.nz [130.217.241.22]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f183fXm23983 for ; Wed, 7 Feb 2001 22:41:35 -0500 Received: from orca.cs.waikato.ac.nz ([130.217.244.4] helo=cs.waikato.ac.nz ident=sfd) by orc.cs.waikato.ac.nz with esmtp (Exim 3.16 #6) id 14QhxY-0003Om-00 for ippm@advanced.org; Thu, 08 Feb 2001 16:41:28 +1300 Message-ID: <3A821566.809400DD@cs.waikato.ac.nz> Date: Thu, 08 Feb 2001 16:41:26 +1300 From: Stephen Donnelly Organization: The University of Waikato X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [ippm] RFC2679 question on Poisson-Stream Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk Reply-To: ippm@advanced.org List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit I apologise for asking a question off the current development track. RFC2679 defines only one sample metric, Type-P-One-way-Delay-Poisson-Stream. It specifies that measurements for this sample metric should be generated from a Poisson process. RFC2330 defines 'Poisson sampling' in terms of an exponential distribution. So, in order to form a measurement of Type-P-One-way-Delay-Poisson-Stream, is an exponential distribution for inter-measurement times required, or can some other distribution be used, provided that it is documented? I am a little confused by the comment on P13 on experimanting with other sampling methods. Thanks, Stephen Donnelly. -- ----------------------------------------------------------------------- Stephen Donnelly (BCMS) email: sfd@cs.waikato.ac.nz WAND Group Room GG.15 phone +64 7 838 4086 Computer Science Department, University of Waikato, New Zealand ----------------------------------------------------------------------- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Feb 9 19:07:46 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04793 for ; Fri, 9 Feb 2001 19:07:45 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f19N0Bm16470; Fri, 9 Feb 2001 18:00:11 -0500 Received: from imo-d05.mx.aol.com (imo-d05.mx.aol.com [205.188.157.37]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f19Mxpm16440 for ; Fri, 9 Feb 2001 17:59:52 -0500 Received: from Mpierce1@aol.com by imo-d05.mx.aol.com (mail_out_v29.5.) id l.d6.2258c7e (6153) for ; Fri, 9 Feb 2001 17:59:37 -0500 (EST) From: Mpierce1@aol.com Message-ID: Date: Fri, 9 Feb 2001 17:59:36 EST Subject: Re: [ippm] New ipdv draft (attached) To: ippm@advanced.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="part1_d6.2258c7e.27b5d058_boundary" X-Mailer: AOL 4.0 for Windows 95 sub 102 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List --part1_d6.2258c7e.27b5d058_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Phil, Thanks for the update to ipdv. Attached as a Word file with comments. I will also paste the comments into the body of this e-mail for those who would rather have it that way. First some editorial or minor wording (to prove I read it): 3.1 2nd para: after MP2 should be "as" not "is" 3.2 2nd para: add "to" after "respect" 4.2 definition of I1, I2: "that" should be "the" 4.4 3rd para: this seems to be extra, was already said in previous. 4.5 2nd para, 2nd bullet (beginning "A given methodology ...") add "[RFC2678]"after "Mahdavi and Paxson" 4.5 2nd para: spelling of "assumes" 5.5 3rd para: spelling of "specific" 6.2 4th para: need to add meaning of "pdf" and "cdf" 6.6 title is the same as 6.5. This needs a different name 6.6 1st para: change "each" at end of 1st sentence to "the same" 7.1 3rd para (after formula): "change is skew" should be "in" Next some technical issues: 3.1 2nd para: This says it is the difference between the first and the second. If the second is greater, this would yield a negative number. The definition should be second minus first, therefore it might be better to say "difference between the second and the first". 3.3 This whole issue of the definition of "skew" and "drift" and the dual meanings of "clock" has been confused in other references. This RFC doesn't need to repeat all this, other than to say that offset between the source and destination real time clocks is not important and that changes in the offset between the clocks has an effect and needs to be controlled. It is clear that the possible variation due to changes in the frequency of crystals is insignificant and should not be mentioned. I suggest deleting everything after the first sentence. In fact, the only concern should be if procedures used to update a clock (like when an operator finds it is wrong) cause discontinuities, but this is a common, well-known problem and doesn't need to be dealt with in detail. 5. This presumes that a Poisson distribution (of generation times) is required. This is one possibility, but when a real distribution of all differences is taken, it is less important for the generation to be Poisson. If the service being measured is one that uses periodic packets, then the measurement of "delay variation" can use the same periodic packets. 6.2 This discussion of the finite distribution of values still presumes that we are looking at a sample in which the first packet of each pair is the second packet of the previous. I really don't know what the significance of this is. Since it is always possible that a packet is delayed any length, there is no bound on the ipdv-value. In looking at any sample, the distribution is whatever it is. 6.3 and 6.4 These refer to a "Type-P-One-way sample" but not as a defined metric name. (Note that there is no hyphen between ipdv and sample.) 6.5 I would suggest not referring to the "jitter" definition in RFC 2598. I think they used the term in a very general sense, and defined it as "absolute value of the difference between ... adjacent packets". Their definition didn't talk about samples of multiple values. 6.6 This seems like an awful complicated way to describe the derivation of "peak-to-peak" jitter. The same was already implied by the description in 6.5 (same title). (Should 6.5 and 6.6 simply be combined?) In fact, the derivation is based on a multiple step process which needs to be detailed. It requires calculating a statistic for each sub-interval, forming a sample of many of these, and then calculating a statistic based on the sample of the whole measurement period (see below). The description assumes that there is a sample of delay values for all packets in each sub-interval. To be complete, that sample metric should be defined first. As in other sections, this should be "the first packet of each pair is the minimum and the second is the maximum" so that a positive value means that the second is larger. Or just eliminate this concept or "first" and "second" and "pairs" and say that "the peak-to-peak delay variation for each sub-interval of the measurement period is the difference between the maximum Type-P-One-way-Delay and the minimum Type-P-One-way-delay". The metric described in 6.6 is a "sample" based on the definition in RFC 2330, not a "Statistic" (title of section 6). I would suggest the following: Change the title and beginning text of 6 as follows 6. Statistic and Sample Metrics for One-way-ipdv" Some samples and statistics ... Add new section between 6.2 and 6.3 6.3 Type-P-One-way-Delay-Sample This sample consists of a sequence of Type-P-One-way-Delay values (as defined in RFC 2679) for a stream of packets. This stream may be either a Poisson distribution or a periodic stream, depending on the type of packets being considered. Correct references in the current 6.3 and 6.4 to refer to the above defined metric (and renumber 6.4 and 6.5). Combine the current Section 6.5 and 6.5 as follows to describe a statistic for each individual interval: 6.6 Type-P-One-way-Peak-to-peak-ipdv This statistic metric is based on the definition of "jitter" and the analysis of delay variations found in [7]. In that document, consecutive packets of the Type-P stream are selected for the packet pairs used in the delay variation computation. The maximum value of the absolute value of the individual delay variation values in the sample is then used for the analysis. The Type-P-One-way-Peak-to-peak ipdv statistic metric is computed for a specified interval by determining the difference between the maximum and minimum values in Type-P-One-way-Delay-Sample during that interval. Add a new sample metric to contain peak-to-peak ipdv values for multiple intervals: 6.7 Type-P-One-way-Peak-to-peak-ipdv-Sample This sample metric is formed by taking a sequence of Type-P-One-way-Peak-to-peak-ipdv values for a series of sub-intervals which make up a larger measurement interval. The sub-intervals may be contiguous or discontiguous. They shall not overlap. Add a new statistic metric to show one possible derivation of information from the above defined sample and a section to indicate that there are others: 6.8 Type-P-One-way-Peak-to-peak-ipdv-Percentile For all sub-intervals in the measurement period and for a given percentage X, this statistic metric indicates the peak-to-peak delay variation which represents the X-percentile of the sample. For example, Type-P-One-way-Peak-to-peak-ipdv-Percentile-90% = 50ms means that 90% of the sub-intervals had a peak-to-peak delay variation less than or equal to 50ms. 6.9 Other Statistic Metrics Other statistics may be derived from the Type-P-One-way-Delay-Sample and the Type-P-One-way-Peak-to-peak-ipdv-Sample metrics. See you in Minneapolis. Mike --part1_d6.2258c7e.27b5d058_boundary Content-Type: application/octet-stream; name="COMMEN~1.DOC" Content-Disposition: attachment; filename="COMMEN~1.DOC" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAALgAAAAAA AAAAEAAAMAAAAAEAAAD+////AAAAAC0AAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAWQAJBAAAABK/AAAAAAAAEAAAAAAABAAA mB0AAA4AYmpiavNX81cAAAAAAAAAAAAAAAAAAAAAAAAJBBYAIigAAJE9AQCRPQEAmBkAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAF0AAAAAALADAAAAAAAAsAMAALADAAAAAAAAsAMAAAAAAACwAwAA AAAAALADAAAAAAAAsAMAABQAAAAAAAAAAAAAAMQDAAAAAAAAxAMAAAAAAADEAwAAAAAAAMQD AAAAAAAAxAMAAAwAAADQAwAAFAAAAMQDAAAAAAAASggAALYAAADwAwAAAAAAAPADAAAAAAAA 8AMAAAAAAADwAwAAAAAAAPADAAAAAAAA8AMAAAAAAADwAwAAAAAAAPADAAAAAAAADwgAAAIA AAARCAAAAAAAABEIAAAAAAAAEQgAAAAAAAARCAAAAAAAABEIAAAAAAAAEQgAACQAAAAACQAA 9AEAAPQKAADQAAAANQgAABUAAAAAAAAAAAAAAAAAAAAAAAAAsAMAAAAAAADwAwAAAAAAAAAA AAAAAAAAAAAAAAAAAADwAwAAAAAAAPADAAAAAAAA8AMAAAAAAADwAwAAAAAAADUIAAAAAAAA rgQAAAAAAACwAwAAAAAAALADAAAAAAAA8AMAAAAAAAAAAAAAAAAAAPADAAAAAAAA8AMAAAAA AACuBAAAAAAAAK4EAAAAAAAArgQAAAAAAADwAwAAvgAAALADAAAAAAAA8AMAAAAAAACwAwAA AAAAAPADAAAAAAAADwgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxAMAAAAAAADEAwAAAAAAALAD AAAAAAAAsAMAAAAAAACwAwAAAAAAALADAAAAAAAA8AMAAAAAAAAPCAAAAAAAAK4EAABsAAAA rgQAAAAAAAAaBQAAxgAAAGsHAACQAAAAsAMAAAAAAACwAwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwgAAAAAAADwAwAA AAAAAOQDAAAMAAAAYHJWwOmSwAHEAwAAAAAAAMQDAAAAAAAArgQAAAAAAAD7BwAAFAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ29tbWVudHMgb24gZHJhZnQgSVBEVg1GaXJzdCBz b21lIGVkaXRvcmlhbCBvciBtaW5vciB3b3JkaW5nICh0byBwcm92ZSBJIHJlYWQgaXQpOiAN My4xIDJuZCBwYXJhOiBhZnRlciBNUDIgc2hvdWxkIGJlICJhcyIgbm90ICJpcyINMy4yIDJu ZCBwYXJhOiBhZGQgInRvIiBhZnRlciAicmVzcGVjdCINNC4yIGRlZmluaXRpb24gb2YgSTEs IEkyOiAidGhhdCIgc2hvdWxkIGJlICJ0aGUiDTQuNCAzcmQgcGFyYTogdGhpcyBzZWVtcyB0 byBiZSBleHRyYSwgd2FzIGFscmVhZHkgc2FpZCBpbiBwcmV2aW91cy4NNC41IDJuZCBwYXJh LCAybmQgYnVsbGV0IChiZWdpbm5pbmcgIkEgZ2l2ZW4gbWV0aG9kb2xvZ3kgLi4uIikgYWRk ICJbUkZDMjY3OF0iYWZ0ZXIgIk1haGRhdmkgYW5kIFBheHNvbiIgDTQuNSAybmQgcGFyYTog c3BlbGxpbmcgb2YgImFzc3VtZXMiDTUuNSAzcmQgcGFyYTogc3BlbGxpbmcgb2YgInNwZWNp ZmljIg02LjIgNHRoIHBhcmE6IG5lZWQgdG8gYWRkIG1lYW5pbmcgb2YgInBkZiIgYW5kICJj ZGYiDTYuNiB0aXRsZSBpcyB0aGUgc2FtZSBhcyA2LjUuIFRoaXMgbmVlZHMgYSBkaWZmZXJl bnQgbmFtZQ02LjYgMXN0IHBhcmE6IGNoYW5nZSAiZWFjaCIgYXQgZW5kIG9mIDFzdCBzZW50 ZW5jZSB0byAidGhlIHNhbWUiDTcuMSAzcmQgcGFyYSAoYWZ0ZXIgZm9ybXVsYSk6ICJjaGFu Z2UgaXMgc2tldyIgc2hvdWxkIGJlICJpbiINTmV4dCBzb21lIHRlY2huaWNhbCBpc3N1ZXM6 DTMuMSAybmQgcGFyYTogVGhpcyBzYXlzIGl0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4g dGhlIGZpcnN0IGFuZCB0aGUgc2Vjb25kLiBJZiB0aGUgc2Vjb25kIGlzIGdyZWF0ZXIsIHRo aXMgd291bGQgeWllbGQgYSBuZWdhdGl2ZSBudW1iZXIuIFRoZSBkZWZpbml0aW9uIHNob3Vs ZCBiZSBzZWNvbmQgbWludXMgZmlyc3QsIHRoZXJlZm9yZSBpdCBtaWdodCBiZSBiZXR0ZXIg dG8gc2F5ICJkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHNlY29uZCBhbmQgdGhlIGZpcnN0Ii4N My4zIFRoaXMgd2hvbGUgaXNzdWUgb2YgdGhlIGRlZmluaXRpb24gb2YgInNrZXciIGFuZCAi ZHJpZnQiIGFuZCB0aGUgZHVhbCBtZWFuaW5ncyBvZiAiY2xvY2siIGhhcyBiZWVuIGNvbmZ1 c2VkIGluIG90aGVyIHJlZmVyZW5jZXMuIFRoaXMgUkZDIGRvZXNuJ3QgbmVlZCB0byByZXBl YXQgYWxsIHRoaXMsIG90aGVyIHRoYW4gdG8gc2F5IHRoYXQgb2Zmc2V0IGJldHdlZW4gdGhl IHNvdXJjZSBhbmQgZGVzdGluYXRpb24gcmVhbCB0aW1lIGNsb2NrcyBpcyBub3QgaW1wb3J0 YW50IGFuZCB0aGF0IGNoYW5nZXMgaW4gdGhlIG9mZnNldCBiZXR3ZWVuIHRoZSBjbG9ja3Mg aGFzIGFuIGVmZmVjdCBhbmQgbmVlZHMgdG8gYmUgY29udHJvbGxlZC4gSXQgaXMgY2xlYXIg dGhhdCB0aGUgcG9zc2libGUgdmFyaWF0aW9uIGR1ZSB0byBjaGFuZ2VzIGluIHRoZSBmcmVx dWVuY3kgb2YgY3J5c3RhbHMgaXMgaW5zaWduaWZpY2FudCBhbmQgc2hvdWxkIG5vdCBiZSBt ZW50aW9uZWQuIEkgc3VnZ2VzdCBkZWxldGluZyBldmVyeXRoaW5nIGFmdGVyIHRoZSBmaXJz dCBzZW50ZW5jZS4NSW4gZmFjdCwgdGhlIG9ubHkgY29uY2VybiBzaG91bGQgYmUgaWYgcHJv Y2VkdXJlcyB1c2VkIHRvIHVwZGF0ZSBhIGNsb2NrIChsaWtlIHdoZW4gYW4gb3BlcmF0b3Ig ZmluZHMgaXQgaXMgd3JvbmcpIGNhdXNlIGRpc2NvbnRpbnVpdGllcywgYnV0IHRoaXMgaXMg YSBjb21tb24sIHdlbGwta25vd24gcHJvYmxlbSBhbmQgZG9lc24ndCBuZWVkIHRvIGJlIGRl YWx0IHdpdGggaW4gZGV0YWlsLg01LiBUaGlzIHByZXN1bWVzIHRoYXQgYSBQb2lzc29uIGRp c3RyaWJ1dGlvbiAob2YgZ2VuZXJhdGlvbiB0aW1lcykgaXMgcmVxdWlyZWQuIFRoaXMgaXMg b25lIHBvc3NpYmlsaXR5LCBidXQgd2hlbiBhIHJlYWwgZGlzdHJpYnV0aW9uIG9mIGFsbCBk aWZmZXJlbmNlcyBpcyB0YWtlbiwgaXQgaXMgbGVzcyBpbXBvcnRhbnQgZm9yIHRoZSBnZW5l cmF0aW9uIHRvIGJlIFBvaXNzb24uIElmIHRoZSBzZXJ2aWNlIGJlaW5nIG1lYXN1cmVkIGlz IG9uZSB0aGF0IHVzZXMgcGVyaW9kaWMgcGFja2V0cywgdGhlbiB0aGUgbWVhc3VyZW1lbnQg b2YgImRlbGF5IHZhcmlhdGlvbiIgY2FuIHVzZSB0aGUgc2FtZSBwZXJpb2RpYyBwYWNrZXRz Lg02LjIgVGhpcyBkaXNjdXNzaW9uIG9mIHRoZSBmaW5pdGUgZGlzdHJpYnV0aW9uIG9mIHZh bHVlcyBzdGlsbCBwcmVzdW1lcyB0aGF0IHdlIGFyZSBsb29raW5nIGF0IGEgc2FtcGxlIGlu IHdoaWNoIHRoZSBmaXJzdCBwYWNrZXQgb2YgZWFjaCBwYWlyIGlzIHRoZSBzZWNvbmQgcGFj a2V0IG9mIHRoZSBwcmV2aW91cy4gSSByZWFsbHkgZG9uJ3Qga25vdyB3aGF0IHRoZSBzaWdu aWZpY2FuY2Ugb2YgdGhpcyBpcy4gU2luY2UgIGl0IGlzIGFsd2F5cyBwb3NzaWJsZSB0aGF0 IGEgcGFja2V0IGlzIGRlbGF5ZWQgYW55IGxlbmd0aCwgdGhlcmUgaXMgbm8gYm91bmQgb24g dGhlIGlwZHYtdmFsdWUuIEluIGxvb2tpbmcgYXQgYW55IHNhbXBsZSwgdGhlIGRpc3RyaWJ1 dGlvbiBpcyB3aGF0ZXZlciBpdCBpcy4NNi4zIGFuZCA2LjQgVGhlc2UgcmVmZXIgdG8gYSAi VHlwZS1QLU9uZS13YXkgc2FtcGxlIiBidXQgbm90IGFzIGEgZGVmaW5lZCBtZXRyaWMgbmFt ZS4gKE5vdGUgdGhhdCB0aGVyZSBpcyBubyBoeXBoZW4gYmV0d2VlbiBpcGR2IGFuZCBzYW1w bGUuKQ02LjUgSSB3b3VsZCBzdWdnZXN0IG5vdCByZWZlcnJpbmcgdG8gdGhlICJqaXR0ZXIi IGRlZmluaXRpb24gaW4gUkZDIDI1OTguIEkgdGhpbmsgdGhleSB1c2VkIHRoZSB0ZXJtIGlu IGEgdmVyeSBnZW5lcmFsIHNlbnNlLCBhbmQgZGVmaW5lZCBpdCBhcyAiYWJzb2x1dGUgdmFs dWUgb2YgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiAuLi4gYWRqYWNlbnQgcGFja2V0cyIuIFRo ZWlyIGRlZmluaXRpb24gZGlkbid0IHRhbGsgYWJvdXQgc2FtcGxlcyBvZiBtdWx0aXBsZSB2 YWx1ZXMuDTYuNiBUaGlzIHNlZW1zIGxpa2UgYW4gYXdmdWwgY29tcGxpY2F0ZWQgd2F5IHRv IGRlc2NyaWJlIHRoZSBkZXJpdmF0aW9uIG9mICJwZWFrLXRvLXBlYWsiIGppdHRlci4gVGhl IHNhbWUgd2FzIGFscmVhZHkgaW1wbGllZCBieSB0aGUgZGVzY3JpcHRpb24gaW4gNi41IChz YW1lIHRpdGxlKS4gKFNob3VsZCA2LjUgYW5kIDYuNiBzaW1wbHkgYmUgY29tYmluZWQ/KSBJ biBmYWN0LCB0aGUgZGVyaXZhdGlvbiBpcyBiYXNlZCBvbiBhIG11bHRpcGxlIHN0ZXAgcHJv Y2VzcyB3aGljaCBuZWVkcyB0byBiZSBkZXRhaWxlZC4gSXQgcmVxdWlyZXMgY2FsY3VsYXRp bmcgYSBzdGF0aXN0aWMgZm9yIGVhY2ggc3ViLWludGVydmFsLCBmb3JtaW5nIGEgc2FtcGxl IG9mIG1hbnkgb2YgdGhlc2UsIGFuZCB0aGVuIGNhbGN1bGF0aW5nIGEgc3RhdGlzdGljIGJh c2VkIG9uIHRoZSBzYW1wbGUgb2YgdGhlIHdob2xlIG1lYXN1cmVtZW50IHBlcmlvZCAoc2Vl IGJlbG93KS4NVGhlIGRlc2NyaXB0aW9uIGFzc3VtZXMgdGhhdCB0aGVyZSBpcyBhIHNhbXBs ZSBvZiBkZWxheSB2YWx1ZXMgZm9yIGFsbCBwYWNrZXRzIGluIGVhY2ggc3ViLWludGVydmFs LiBUbyBiZSBjb21wbGV0ZSwgdGhhdCBzYW1wbGUgbWV0cmljIHNob3VsZCBiZSBkZWZpbmVk IGZpcnN0Lg1BcyBpbiBvdGhlciBzZWN0aW9ucywgdGhpcyBzaG91bGQgYmUgInRoZSBmaXJz dCBwYWNrZXQgb2YgZWFjaCBwYWlyIGlzIHRoZSBtaW5pbXVtIGFuZCB0aGUgc2Vjb25kIGlz IHRoZSBtYXhpbXVtIiBzbyB0aGF0IGEgcG9zaXRpdmUgdmFsdWUgbWVhbnMgdGhhdCB0aGUg c2Vjb25kIGlzIGxhcmdlci4gT3IganVzdCBlbGltaW5hdGUgdGhpcyBjb25jZXB0IG9yICJm aXJzdCIgYW5kICJzZWNvbmQiIGFuZCAicGFpcnMiIGFuZCBzYXkgdGhhdCAidGhlIHBlYWst dG8tcGVhayBkZWxheSB2YXJpYXRpb24gZm9yIGVhY2ggc3ViLWludGVydmFsIG9mIHRoZSBt ZWFzdXJlbWVudCBwZXJpb2QgaXMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgbWF4aW11 bSBUeXBlLVAtT25lLXdheS1EZWxheSBhbmQgdGhlIG1pbmltdW0gVHlwZS1QLU9uZS13YXkt ZGVsYXkiLg1UaGUgbWV0cmljIGRlc2NyaWJlZCBpbiA2LjYgaXMgYSAic2FtcGxlIiBiYXNl ZCBvbiB0aGUgZGVmaW5pdGlvbiBpbiBSRkMgMjMzMCwgbm90IGEgIlN0YXRpc3RpYyIgKHRp dGxlIG9mIHNlY3Rpb24gNikuDUkgd291bGQgc3VnZ2VzdCB0aGUgZm9sbG93aW5nOg1DaGFu Z2UgdGhlIHRpdGxlIGFuZCBiZWdpbm5pbmcgdGV4dCBvZiA2IGFzIGZvbGxvd3MNNi4gU3Rh dGlzdGljIGFuZCBTYW1wbGUgTWV0cmljcyBmb3IgT25lLXdheS1pcGR2Ig1Tb21lIHNhbXBs ZXMgYW5kIHN0YXRpc3RpY3MgLi4uDUFkZCBuZXcgc2VjdGlvbiBiZXR3ZWVuIDYuMiBhbmQg Ni4zDTYuMyBUeXBlLVAtT25lLXdheS1EZWxheS1TYW1wbGUNVGhpcyBzYW1wbGUgY29uc2lz dHMgb2YgYSBzZXF1ZW5jZSBvZiBUeXBlLVAtT25lLXdheS1EZWxheSB2YWx1ZXMgKGFzIGRl ZmluZWQgaW4gUkZDIDI2NzkpIGZvciBhIHN0cmVhbSBvZiBwYWNrZXRzLiBUaGlzIHN0cmVh bSBtYXkgYmUgZWl0aGVyIGEgUG9pc3NvbiBkaXN0cmlidXRpb24gb3IgYSBwZXJpb2RpYyBz dHJlYW0sIGRlcGVuZGluZyBvbiB0aGUgdHlwZSBvZiBwYWNrZXRzIGJlaW5nIGNvbnNpZGVy ZWQuDUNvcnJlY3QgcmVmZXJlbmNlcyBpbiB0aGUgY3VycmVudCA2LjMgYW5kIDYuNCB0byBy ZWZlciB0byB0aGUgYWJvdmUgZGVmaW5lZCBtZXRyaWMgKGFuZCByZW51bWJlciA2LjQgYW5k IDYuNSkuDUNvbWJpbmUgdGhlIGN1cnJlbnQgU2VjdGlvbiA2LjUgYW5kIDYuNSBhcyBmb2xs b3dzIHRvIGRlc2NyaWJlIGEgc3RhdGlzdGljIGZvciBlYWNoIGluZGl2aWR1YWwgaW50ZXJ2 YWw6DTYuNiBUeXBlLVAtT25lLXdheS1QZWFrLXRvLXBlYWstaXBkdg1UaGlzIHN0YXRpc3Rp YyBtZXRyaWMgaXMgYmFzZWQgb24gdGhlIGRlZmluaXRpb24gb2YgImppdHRlciIgYW5kIHRo ZSBhbmFseXNpcyBvZiBkZWxheSB2YXJpYXRpb25zIGZvdW5kIGluIFs3XS4gSW4gdGhhdCBk b2N1bWVudCwgY29uc2VjdXRpdmUgcGFja2V0cyBvZiB0aGUgVHlwZS1QIHN0cmVhbSBhcmUg c2VsZWN0ZWQgZm9yIHRoZSBwYWNrZXQgcGFpcnMgdXNlZCBpbiB0aGUgZGVsYXkgdmFyaWF0 aW9uIGNvbXB1dGF0aW9uLiBUaGUgbWF4aW11bSB2YWx1ZSBvZiB0aGUgYWJzb2x1dGUgdmFs dWUgb2YgdGhlIGluZGl2aWR1YWwgZGVsYXkgdmFyaWF0aW9uIHZhbHVlcyBpbiB0aGUgc2Ft cGxlIGlzIHRoZW4gdXNlZCBmb3IgdGhlIGFuYWx5c2lzLg1UaGUgVHlwZS1QLU9uZS13YXkt UGVhay10by1wZWFrIGlwZHYgc3RhdGlzdGljIG1ldHJpYyBpcyBjb21wdXRlZCBmb3IgYSBz cGVjaWZpZWQgaW50ZXJ2YWwgYnkgZGV0ZXJtaW5pbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2Vl biB0aGUgbWF4aW11bSBhbmQgbWluaW11bSB2YWx1ZXMgaW4gVHlwZS1QLU9uZS13YXktRGVs YXktU2FtcGxlIGR1cmluZyB0aGF0IGludGVydmFsLg1BZGQgYSBuZXcgc2FtcGxlIG1ldHJp YyB0byBjb250YWluIHBlYWstdG8tcGVhayBpcGR2IHZhbHVlcyBmb3IgbXVsdGlwbGUgaW50 ZXJ2YWxzOg02LjcgVHlwZS1QLU9uZS13YXktUGVhay10by1wZWFrLWlwZHYtU2FtcGxlDVRo aXMgc2FtcGxlIG1ldHJpYyBpcyBmb3JtZWQgYnkgdGFraW5nIGEgc2VxdWVuY2Ugb2YgVHlw ZS1QLU9uZS13YXktUGVhay10by1wZWFrLWlwZHYgdmFsdWVzIGZvciBhIHNlcmllcyBvZiBz dWItaW50ZXJ2YWxzIHdoaWNoIG1ha2UgdXAgYSBsYXJnZXIgbWVhc3VyZW1lbnQgaW50ZXJ2 YWwuIFRoZSBzdWItaW50ZXJ2YWxzIG1heSBiZSBjb250aWd1b3VzIG9yIGRpc2NvbnRpZ3Vv dXMuIFRoZXkgc2hhbGwgbm90IG92ZXJsYXAuDUFkZCBhIG5ldyBzdGF0aXN0aWMgbWV0cmlj IHRvIHNob3cgb25lIHBvc3NpYmxlIGRlcml2YXRpb24gb2YgaW5mb3JtYXRpb24gZnJvbSB0 aGUgYWJvdmUgZGVmaW5lZCBzYW1wbGUgYW5kIGEgc2VjdGlvbiB0byBpbmRpY2F0ZSB0aGF0 IHRoZXJlIGFyZSBvdGhlcnM6DTYuOCBUeXBlLVAtT25lLXdheS1QZWFrLXRvLXBlYWstaXBk di1QZXJjZW50aWxlDUZvciBhbGwgc3ViLWludGVydmFscyBpbiB0aGUgbWVhc3VyZW1lbnQg cGVyaW9kIGFuZCBmb3IgYSBnaXZlbiBwZXJjZW50YWdlIFgsIHRoaXMgc3RhdGlzdGljIG1l dHJpYyBpbmRpY2F0ZXMgdGhlIHBlYWstdG8tcGVhayBkZWxheSB2YXJpYXRpb24gd2hpY2gg cmVwcmVzZW50cyB0aGUgWC1wZXJjZW50aWxlIG9mIHRoZSBzYW1wbGUuIEZvciBleGFtcGxl LCBUeXBlLVAtT25lLXdheS1QZWFrLXRvLXBlYWstaXBkdi1QZXJjZW50aWxlLTkwJSA9IDUw bXMgbWVhbnMgdGhhdCA5MCUgb2YgdGhlIHN1Yi1pbnRlcnZhbHMgaGFkIGEgcGVhay10by1w ZWFrIGRlbGF5IHZhcmlhdGlvbiBsZXNzIHRoYW4gb3IgZXF1YWwgdG8gNTBtcy4NNi45IE90 aGVyIFN0YXRpc3RpYyBNZXRyaWNzDU90aGVyIHN0YXRpc3RpY3MgbWF5IGJlIGRlcml2ZWQg ZnJvbSB0aGUgVHlwZS1QLU9uZS13YXktRGVsYXktU2FtcGxlIGFuZCB0aGUgVHlwZS1QLU9u ZS13YXktUGVhay10by1wZWFrLWlwZHYtU2FtcGxlIG1ldHJpY3MuDQ0NAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAEAAAXBAAAmB0AAPv4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAEQ0oWAAAHNQiBQ0oWAAACAAQAABcEAABUBAAAhAQAAKsE AADcBAAAIAUAAIoFAACuBQAA0wUAAAgGAABCBgAAgwYAAMEGAADdBgAA6gcAABIKAADyCgAA WgwAAOoNAAB5DgAAiQ8AAHERAAASEgAAwhMAADkUAABYFAAAjBQAAL4UAADeFAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAMAAA+E aAEAAQAAAB0ABAAAFwQAAFQEAACEBAAAqwQAANwEAAAgBQAAigUAAK4FAADTBQAACAYAAEIG AACDBgAAwQYAAN0GAADqBwAAEgoAAPIKAABaDAAA6g0AAHkOAACJDwAAcREAABISAADCEwAA ORQAAFgUAACMFAAAvhQAAN4UAAACFQAAIhUAABAWAAB/FgAA6BYAAA0XAACBGAAAVhkAAKoZ AADWGQAAzBoAAGUbAACVGwAA/BwAABgdAACWHQAAlx0AAJgdAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL94UAAACFQAAIhUAABAWAAB/FgAA 6BYAAA0XAACBGAAAVhkAAKoZAADWGQAAzBoAAGUbAACVGwAA/BwAABgdAACWHQAAlx0AAJgd AAD9AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAPhGgB AAEAAAASIAAmUAEAH7DQLyCw4D0hsKAFIrCgBSOQoAUkkKAFJbAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASABUACgABAFsADwACAAAAAAAAAD4A AEDx/wIAPgAAAAYATgBvAHIAbQBhAGwAAAAYAAAAE6RQABSkKAANxgsAA9ACoAVwCEBAQAgA Q0oYAG1ICQQ8AAEAAQACADwAAAAJAEgAZQBhAGQAaQBuAGcAIAAxAAAADAABAAYkAROk8ABA JgALADUIgUNKIABLSBwAADgAAgABAAIAOAAAAAkASABlAGEAZABpAG4AZwAgADIAAAAMAAIA BiQBE6R4AEAmAQcANQiBQ0ocAAA4AAMAAQACADgAAAAJAEgAZQBhAGQAaQBuAGcAIAAzAAAA DAADAAYkAROkeABAJgIHADUIgUNKHAAANAAEAAEAAgA0AAAACQBIAGUAYQBkAGkAbgBnACAA NAAAAAgABAAGJAFAJgMHADUIgUNKGAAAMgAFAAEAAgAyAAAACQBIAGUAYQBkAGkAbgBnACAA NQAAAAUABQBAJgQABwA1CIFDShgAADIABgABAAIAMgAAAAkASABlAGEAZABpAG4AZwAgADYA AAAFAAYAQCYFAAcANQiBQ0oYAAAyAAcAAQACADIAAAAJAEgAZQBhAGQAaQBuAGcAIAA3AAAA BQAHAEAmBgAHADUIgUNKGAAAMgAIAAEAAgAyAAAACQBIAGUAYQBkAGkAbgBnACAAOAAAAAUA CABAJgcABwA1CIFDShYAADIACQABAAIAMgAAAAkASABlAGEAZABpAG4AZwAgADkAAAAFAAkA QCYIAAcANQiBQ0oWAAA8AEFA8v+hADwAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcA cgBhAHAAaAAgAEYAbwBuAHQAAAAAAAAAAAAAAAAAAAAuAD4AAQASAC4AAAAFAFQAaQB0AGwA ZQAAAAUAEABAJgAACwA1CIFDSiAAS0gcAAA6ADAAAQASAToAAQALAEwAaQBzAHQAIABCAHUA bABsAGUAdAAAABEAEQAKJgALRgEAE6QUABSkFAAAAAA6ADEAAQAiAToAAAALAEwAaQBzAHQA IABOAHUAbQBiAGUAcgAAABEAEgAKJgALRgIAE6QUABSkFAAAAAA+ADYAAQAyAT4AAQANAEwA aQBzAHQAIABCAHUAbABsAGUAdAAgADIAAAARABMACiYAC0YGABOkFAAUpBQAAAAAPgA6AAEA QgE+AAAADQBMAGkAcwB0ACAATgB1AG0AYgBlAHIAIAAyAAAAEQAUAAomAAtGBwATpBQAFKQU AAAAAAAAAACYGQAABgAAKAAAAAD/////AAQAAJgdAAAQAAAAAAQAAN4UAACYHQAAEQAAABMA AAAABAAAmB0AABIAAAAAAAAAXAAAAGAAAACMAAAAkAAAAOQAAADoAAAAKAEAACwBAAB1AQAA fAEAAIEBAACHAQAAkgEAAJYBAAC2AQAAugEAANsBAADfAQAA+QEAAPwBAAADAgAABgIAAEoC AABOAgAAiwIAAI8CAADlAgAA6QIAAKUWAACyFgAAmhkAAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA//8CAAAACwBNAGkA awBlACAAUABpAGUAcgBjAGUAJgBDADoAXABtAHkAXwBkAG8AYwBzAFwAVwBvAHIAawBcAGkA ZQB0AGYAXABjAG8AbQBtAGUAbgB0AHMAXwBpAHAAZAB2AC4AZABvAGMABwB/////4lRwyRQA /w//D/8P/w//D/8P/w//DwEAgP///06gJKr/D/8P/w//D/8P/w//D/8P/w8BAIH///8+jgq6 /w//D/8P/w//D/8P/w//D/8PAQCC////zL0Gev8P/w//D/8P/w//D/8P/w//DwEAg////zQ7 aI0TAP8P/w//D/8P/w//D/8P/w8BAIj///8w82agEgD/D/8P/w//D/8P/w//D/8PAQCJ//// kCBQGBEA/w//D/8P/w//D/8P/w//DwEAAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+E 0AIRhJj+FcYFAAHQAgYCAAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4QIBxGE mP4VxgUAAQgHBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAP hKAFEYSY/hXGBQABoAUGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAA CxAAAA+EOAQRhJj+FcYFAAE4BAZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAA AAAAAAALEAAAD4TQAhGEmP4VxgUAAdACBk9KAQBRSgEAbygAAQC38AEAAAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAABcAAAAAAAAAAAAAAAAA AAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AHAAAAif///wAAAAAA AAAAAAAAAIj///8AAAAAAAAAAAAAAACA////AAAAAAAAAAAAAAAAgf///wAAAAAAAAAAAAAA AIL///8AAAAAAAAAAAAAAACD////AAAAAAAAAAAAAAAAf////wAAAAAAAAAAAAAAAP////// /////////////////////////////////wcAAAAAAAAAAAAAAAAAAAAAAP9AA4ABAFMAAABT AAAA2HHoAAEAAQBTAAAAAAAAAFIAAAAAAAAAAhAAAAAAAAAAmBkAAGAAAAgAQAAAAwAAAEcW kAEAAAICBgMFBAUCAwQDAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABUAGkAbQBlAHMAIABOAGUA dwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAA AABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgQDAAAAAAAAAAAAAAAAAAAAAQAAAAAA AABBAHIAaQBhAGwAAAAiAAQAcQiIGIEQ0AIAAGgBAAAAAGtMUqZrTFKmAAAAAAIAAAAAALMD AAAaFQAAAQAKAAAABAADEC0AAAAAAAAAAAAAAAEAAQAAAAEAAAAAAAAAJAOBEAAQAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApQbAB7QAtACAABIwAAAAAAAA AAAAAAAAAADqGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAP//EgAAAAAAOABDADoAXABQAHIAbwBnAHIA YQBtACAARgBpAGwAZQBzAFwATQBpAGMAcgBvAHMAbwBmAHQAIABPAGYAZgBpAGMAZQBcAFQA ZQBtAHAAbABhAHQAZQBzAFwATQB5AF8AYgBsAGEAbgBrAC4AZABvAHQABQBUAGkAdABsAGUA AAAAAAAACwBNAGkAawBlACAAUABpAGUAcgBjAGUACwBNAGkAawBlACAAUABpAGUAcgBjAGUA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCF n/L5T2gQq5EIACsns9kwAAAAeAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAAKgAAAAEAAAA tAAAAAUAAADIAAAABwAAANQAAAAIAAAA7AAAAAkAAAAAAQAAEgAAAAwBAAAKAAAAKAEAAAsA AAA0AQAADAAAAEABAAANAAAATAEAAA4AAABYAQAADwAAAGABAAAQAAAAaAEAABMAAABwAQAA AgAAAOQEAAAeAAAABgAAAFRpdGxlAGYAHgAAAAEAAAAAaXRsHgAAAAwAAABNaWtlIFBpZXJj ZQAeAAAAAQAAAABpa2UeAAAADQAAAE15X2JsYW5rLmRvdAAAbwAeAAAADAAAAE1pa2UgUGll cmNlAB4AAAACAAAAMgBrZR4AAAATAAAATWljcm9zb2Z0IFdvcmQgOC4wAABAAAAAAAAAAAAA AABAAAAAAAAAAAAAAABAAAAAALJnp+mSwAFAAAAAALJnp+mSwAEDAAAAAQAAAAMAAACzAwAA AwAAABoVAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP7/AAAECgIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOX CAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a4wAQAA7AAAAAwAAAABAAAAaAAAAA8AAABwAAAA BQAAAHwAAAAGAAAAhAAAABEAAACMAAAAFwAAAJQAAAALAAAAnAAAABAAAACkAAAAEwAAAKwA AAAWAAAAtAAAAA0AAAC8AAAADAAAAM4AAAACAAAA5AQAAB4AAAACAAAAIAAAAAMAAAAtAAAA AwAAAAoAAAADAAAA6hkAAAMAAABqEAgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAA AAAeEAAAAQAAAAYAAABUaXRsZQAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAACYAAAA AwAAAAAAAAAgAAAAAQAAADYAAAACAAAAPgAAAAEAAAACAAAACgAAAF9QSURfR1VJRAACAAAA 5AQAAEEAAABOAAAAewA4ADQAMQBFADYAMQA2ADMALQA5ADAARgAwAC0AMQAxAEQAMgAtADkA QgBEAEIALQBGADcAOQA2AEMAMgAzADQAQwBDADEANgB9AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwA AAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAAP7///8WAAAAFwAAABgAAAAZAAAA GgAAABsAAAAcAAAA/v///x4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAD+////JgAAACcA AAAoAAAAKQAAACoAAAArAAAALAAAAP7////9////LwAAAP7////+/////v////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////// //8DAAAABgkCAAAAAADAAAAAAAAARgAAAABAOXAL1JLAAWDcbsDpksABMQAAAIAAAAAAAAAA MQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA4AAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAVAAAAABAAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQUAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiKAAAAAAAAAUAUwB1AG0AbQBhAHIA eQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB AgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHQAAAAAQ AAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQA aQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAlAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUA YwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAWAAEA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAABg3G7A6ZLAAWDcbsDpksAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA/v////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQgRG9j dW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --part1_d6.2258c7e.27b5d058_boundary-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Feb 9 20:01:50 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05413 for ; Fri, 9 Feb 2001 20:01:50 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1A0r3m20761; Fri, 9 Feb 2001 19:53:03 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1A0qem20738 for ; Fri, 9 Feb 2001 19:52:41 -0500 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id TAA09272 for ; Fri, 9 Feb 2001 19:52:43 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id CED7F898; Fri, 9 Feb 2001 19:52:41 -0500 (EST) To: ippm@advanced.org From: stanislav shalunov Date: 09 Feb 2001 19:52:41 -0500 Message-ID: <87wvazs6jq.fsf@cain.internet2.edu> Lines: 15 X-Mailer: Gnus v5.7/Emacs 20.4 Subject: [ippm] DEADLINE: draft-ietf-ippm-owdp-01.txt comments Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Our internal deadline for -02 has already slipped. This is to let you know that comments that don't make it to the list by Wednesday February 14 are realistically much less likely to be considered when preparing -02 version than comments submitted before this date. Please send your comments ASAP so that we can prepare new version before draft submission deadline. Thanks a lot! -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ A fool's brain digests philosophy into folly, science into superstition, and art into pedantry. Hence University education. -- G. B. Shaw _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Feb 13 10:03:52 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20867 for ; Tue, 13 Feb 2001 10:03:51 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1DEx3302554; Tue, 13 Feb 2001 09:59:03 -0500 Received: from brixcorp2.brixnet.com ([63.122.27.34]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1DEgD301529; Tue, 13 Feb 2001 09:42:14 -0500 X-Authentication-Warning: mailhost.advanced.org: Host [63.122.27.34] claimed to be brixcorp2.brixnet.com Received: by BRIXCORP2 with Internet Mail Service (5.5.2650.21) id <1ZMY1VLA>; Tue, 13 Feb 2001 09:42:13 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB9B7F6E@BRIXCORP2> From: "Cucchiara, Joan" To: "'shalunov@internet2.edu'" , "'ben@advanced.org'" , "'matt@advanced.org'" Cc: "'ippm@advanced.org'" , "Harvell, Scott" , "Hedayat, Kaynam" , "Kaufman, David" , "Dunning, John" , "Naylor, Bob" , "Pyrik, Dan" , "Pacheco, John" , "Cucchiara, Joan" Date: Tue, 13 Feb 2001 09:42:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [ippm] Comments on draft-ietf-ippm-owdp-01.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Hello Stanislav, Ben, and Matt, As you probably know BRIX Networks has also implemented a One-Way Delay Measurement Protocol with GPS. We have read the draft-ietf-ippm-owdp-01.txt and have a few comments and questions for you. First, we want to say that what you are proposing is very similar to what we have in place. We have separated our protocol into a control plane using TCP and a data plane using UDP also. So it was good to see that you were also approaching the protocol in that same way. We have divided the following into 2 parts: Part I. Questions on the draft. Part II. Requests for changes/additions to the draft. Thanks. Part I. Questions on the draft? ------------------------------------- * Can both conf-sender and conf-receiver be set in the Request-Session message? If so, what is the behavior? If not, could this be clearly stated in the draft? * Why can't the server close the TCP connection when it rejects a Request-Session command? If the request is rejected, the server should be able to close the connection in order to save resources. * What format is Start Time in the Request-Session message? * Why is sender/receiver precision repeated when data is sent during the Retrieve-Session process? * Padding test packets with zero's should be optional. Tests may want to xmit non-zero data to mimic multi-media traffic. Part II. Request for Changes or Additions to the Draft ------------------------------------------------------ 1) A clearer picture of the requirements/goals and non-goals upfront would be helpful. This was also discussed recently on the list. 2) In addition to the software-based timestamp method presented in the draft, could an option be added for out-of-band communication of hardware-based timestamps from the session-sender be added? This could be between either the session-sender and session-receiver, or between session-sender and the server. Please note, hardware-based timestamping prevents the transmission of timestamps inside packets (by its nature, the timestamp is retrieved after the packet is sent out). 3) We'd like to see suppport for an "application level" mimicing capability. This could be assigned in the control plane. For example, having the UDP mimic the RTP format. We'd especially like to see multimedia (voice, video) data mimiced and would request support of VoIP and Streaming protocols added as a requirement. 4) Are there any plans for a "flights of packets" approach? 5) There should be a way to choose other encryption options such as SSL. Having AES be the only one and having this as required is not particularly flexible or extensible, Are there any plans to add additional options here? 6) We would also like to see the one-way delay in both directions, so from A to B, and then back from B to A. This would be a good indication of where time is spent in the round-trip time (which leg, from A to B or B to A.) (It has been particularly appreciated by our customers). This could be an option and may require adding a "bi-directional" flag somewhere, perhaps, in the request-session message and another "mode" to indicate this capability in the server greeting message (i.e. as a option when the session starts.) 7) For a standard, we thought the format of the control plane messages should be modeled after a TLV. The TLV format is flexible and extensible. We believe this approach would help to advance the one-way delay protocol as a standard. Also, this would allow vendors to add their own features. Assuming that a type code was for "vendor's use". 8) The calculation for acceptible jitter may be simplified (and perhaps made more precise?) by including a "length of time for test". Since you are including how many packets, this would also be a reasonable piece of information to include in the control plane. Also, this would eliminate the requirement for AES based pseudo-random sample interval calculation that allows the receiver to determine the packet send time. We'd also like to see an acceptable jitter parameter that could be used to tag late packets vs. lost packets. This is the approach take by most VoIP equipment. This would be an option instead of sending the inverse-lambda in the Request-Session message. 9) Has support for Keep-Alives (or another message that could be exchanged during the session) with the ability to append user data to the messages, been considered? Thank you for this opportunity to comment! _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Feb 14 10:11:57 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01431 for ; Wed, 14 Feb 2001 10:11:57 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1EF54301444; Wed, 14 Feb 2001 10:05:04 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1E363308340 for ; Tue, 13 Feb 2001 22:06:04 -0500 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id WAA01072; Tue, 13 Feb 2001 22:05:56 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id 75E938A3; Tue, 13 Feb 2001 22:05:53 -0500 (EST) To: "Cucchiara, Joan" Cc: ippm@advanced.org, "Harvell, Scott" , "Hedayat, Kaynam" , "Kaufman, David" , "Dunning, John" , "Naylor, Bob" , "Pyrik, Dan" , "Pacheco, John" Subject: Re: [ippm] Comments on draft-ietf-ippm-owdp-01.txt References: <07B0D4912B83D31188F300A0C9F62EBB9B7F6E@BRIXCORP2> From: stanislav shalunov Date: 13 Feb 2001 22:05:52 -0500 In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB9B7F6E@BRIXCORP2> Message-ID: <873ddiklpr.fsf@cain.internet2.edu> Lines: 217 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Joan, Thanks a lot for the comments and suggestions. "Cucchiara, Joan" writes: > Part I. Questions on the draft? > ------------------------------------- > > * Can both conf-sender and conf-receiver be set in the Request-Session > message? If so, what is the behavior? If not, could this > be clearly stated in the draft? You can set both. Setting each means that the server is asked to configure the corresponding end-point. Setting both therefore is meant to ask the server to configure both. Example: a set of measurement nodes under same administrative control, with a single OWDP-Control gateway to them can be used to provide on-demand measurements to third parties. I suppose we'll need to clarify this (work item). > * Why can't the server close the TCP connection when it > rejects a Request-Session command? If the request > is rejected, the server should be able to close the > connection in order to save resources. If you requested three sessions, and they were accepted (but not started yet), it'd be inconvenient to lose them all if the forth session is rejected for a policy reason of some sort... > * What format is Start Time in the Request-Session message? It was supposed to be in the normal NTP-style format. I suppose we'll need to clarify this (work item). > * Why is sender/receiver precision repeated when data is sent during the > Retrieve-Session process? This way, the only thing a collection database would need to know about a session is its SID. (Remember that Control-Client and Retrieve-Client can be different hosts.) > * Padding test packets with zero's should be optional. Tests may > want to xmit non-zero data to mimic multi-media traffic. We say now (page 17): Finally, Packet Padding SHOULD be pseudo-random (generated independently of any other pseudo-random numbers mentioned in this document). However, implementations MUST provide a configuration parameter, an option, or a different means of making Packet Padding consist of all zeros. And further down (page 18): OWDP-Test sessions could be used as covert channels of information. Environments that are worried about covert channels should take this into consideration. Pseudo-random padding is meant for situations where there can be hardware compression in the path (modems like to do that). Emulating any particular application wasn't a goal. > Part II. Request for Changes or Additions to the Draft > ------------------------------------------------------ > > 1) A clearer picture of the requirements/goals and non-goals > upfront would be helpful. This was also discussed recently > on the list. ...and will be provided. > 2) In addition to the software-based timestamp method presented > in the draft, could an option be added for out-of-band > communication of hardware-based timestamps from the > session-sender be added? > > This could be between either the session-sender > and session-receiver, or between session-sender and the server. > > Please note, hardware-based timestamping prevents the transmission > of timestamps inside packets (by its nature, the timestamp is > retrieved after the packet is sent out). I'm not sure I understand. If timestamps aren't in the packets, where are they? I'm not sure what you mean. Say, when SmartBits puts timestamps into their packets on the PIC, they insert it in the packet (where else?). > 3) We'd like to see suppport for an "application level" mimicing capability. This was not a goal. One of the reasons is that effective application emulation would require substantial new (non-existing) research far beyond packet formats. > 4) Are there any plans for a "flights of packets" approach? I'm not sure I understand. Do you mean non-Poisson inter-packet distribution? We had some pretty extensive discussion on this internally, and the short summary of what I believe we came to was that it'd be nice to be able to specify a number of other distributions (in particular, back-to-back tuples), but we don't really have ideas on how to do it in a good general way. Since there's an IPPM singleton metric, which essentially implies Poisson, we decided we'll stick with just that for now. This doesn't mean non-Poisson distribution is off the agenda for the future. > 5) There should be a way to choose other encryption options > such as SSL. Having AES be the only one and having this > as required is not particularly flexible or extensible, > Are there any plans to add additional options here? There are no such plans. Why would you want an extensible or flexible something where requirements are quite clear? In particular regard to SSL, none of the ciphers, versions, or modes (all the zillions of total combinations provided because of U.S. govt stance on encryption technology) provide individual message authentication. Blocks of zeros in CBC mode for an 128-bit-block block cipher provides it. > 6) We would also like to see the one-way delay in both > directions, so from A to B, and then back from B to A. > This would be a good indication of where time is spent in the > round-trip time (which leg, from A to B or B to A.) The idea is that once you have the primitive that allows you to measure one-way, you can easily measure in both directions with two individual OWDP-Test sessions. > 7) For a standard, we thought the format of the control > plane messages should be modeled after a TLV. This wasn't really ingestigated as any serious extensibility goes contrary to the goal of having a really simple easy-to-implement control protocol. We didn't have a goal to design a flexible general-purpose protocol for "passing things". If you feel strongly about the issue and have a specific model in mind, do tell us! > Also, this would allow vendors to add their own features. > Assuming that a type code was for "vendor's use". While it's a limited expansion machanism, one can steal a mode bit now for "I support Frobnitz extensions set". > 8) The calculation for acceptible jitter may be simplified > (and perhaps made more precise?) by including a "length of time > for test". Since you are including how many packets, this > would also be a reasonable piece of information to include > in the control plane. I don't think I understand how calculation of jitter would be simplified by that, since the way it is now you can compute jitter in one pass while getting Retrieve-Session results back (it's just the standard deviation of the difference of send/receive timestamps). How could it possibly be any simpler than one pass on the data as it is coming? Or do I misunderstand something? Where do you want to have total duration--in Request-Session or in Retrieve-Session results? > Also, this would eliminate the requirement for AES based > pseudo-random sample interval calculation that allows the receiver to > determine the packet send time. How so? You still need to know when the next packet is scheduled to be sent to know when to decide it's not coming, right? > We'd also like to see an acceptable jitter parameter that could > be used to tag late packets vs. lost packets. This is > the approach take by most VoIP equipment. This would be an option > instead of sending the inverse-lambda in the Request-Session > message. Inverse-Lambda is the mean time between packets. It determines the properties of the test stream and must be in the protocol. Max latency threshold, on the other hand, is a matter of processing. You can always discard packets that you consider "late". We decided that the protocol needs to provide complete information. What you do with it is your choice. It's always easy to discard some data. > 9) Has support for Keep-Alives (or another message that could be > exchanged during the session) with the ability to append user > data to the messages, been considered? No, why? Any traffic on the TCP connection during the session (between Start-Sessions and Stop-Sessions) was considered bad for two reasons: * If there's a lot of it, it can affect measurement results. * If there's connectivity loss during a session (say, an hour), we'd like to continue to record losses rather than have the session fail. Thanks again for your feedback! -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ All revolutions are bloody. The October Revolution was bloodless, but it was only the beginning. -- Dmitri Volkogonov _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Feb 14 10:22:02 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02077 for ; Wed, 14 Feb 2001 10:22:01 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1EFE2302233; Wed, 14 Feb 2001 10:14:02 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1EF9Q301740 for ; Wed, 14 Feb 2001 10:09:27 -0500 Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id QAA14648; Wed, 14 Feb 2001 16:07:07 +0100 (CET) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id QAA19759; Wed, 14 Feb 2001 16:07:06 +0100 (CET) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Wed, 14 Feb 2001 16:07:06 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Undisclosed recipients: ; Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [ippm] PAM2001 registration opens (reminder) Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List ---------- Forwarded message ---------- Date: Wed, 3 Jan 2001 14:53:19 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Undisclosed recipients: ; Subject: PAM2001 registration opens Passive & Active Measurement: PAM-2001 Registration Opens A workshop on passive and active measurement techniques for high speed computer networks and the Internet Amsterdam, the Netherlands, April 23-24, 2001 As the Internet has grown over the last decade the need for precise measurement of network traffic has become steadily more apparent; most of today's Internet Service Providers and many of their large network customers are collecting and analysing traffic data for the purposes of performance monitoring, network engineering and cost recovery, but the engineering quality of these measurements vary. A steadily growing number of research groups have been working in the areas of: - Active Measurements, i.e. sending test packets and observing their progress through the Internet, - Passive Measurements, i.e. observing actual traffic on 'live' networks, - Performance Metrics, i.e. developing measures or indicators which can be used to characterise traffic behavior, - Traffic Statistics, i.e. attempting to understand and develop models of 'real' Internet traffic, and - Visualisation, i.e. finding effective ways to display what's happening in a network. After the successful workshop PAM2000 in Hamilton, New Zealand, in April 2000, the RIPE NCC will be organising another workshop on this topic in Amsterdam in April 2001. Registration for this workshop has now been opened. To register online, go to: http://www.ripe.net/cgi-bin/pamreg Also available on the web-site are the preliminary program: http://www.ripe.net/pam2001/program.html as well as general information on the workshop: http://www.ripe.net/pam2001/ and hotel information: http://www.ripe.net/pam2001/hotels.html Rooms are available at the conference hotel. The rate is 285 Euro/night (including taxes, approximately 255 US$). To reserve a room, call, fax or email the hotel. Contact details can be found on the web page. If you prefer to stay in another hotel, then there are rooms available in all price classes between 35 Euro/night and 1500 Euro/night within a 5 km radius of the conference site. A selection of hotels and links to reservation sites can be found on the webpage. There are still opportunities for participants to present measurement equipment and software. Proposals for demonstrations (about 500 words, plain ASCII) should be sent by email to the conference chair at pam2001@ripe.net by 5 March 2001. Contact information: * PAM 2001 c/o RIPE-NCC Singel 258 1016 AB Amsterdam The Netherlands * Phone: +31.20.5354444 * Fax: +31.20.5354445 * Email: pam2001@ripe.net * Webpage: http://www.ripe.net/pam2001 ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 15 06:14:58 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12540 for ; Thu, 15 Feb 2001 06:14:58 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1FBC3324872; Thu, 15 Feb 2001 06:12:03 -0500 Received: from dmz0101.rrl.co.uk (mail.rrl.co.uk [195.166.68.179]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1FBB4324825; Thu, 15 Feb 2001 06:11:05 -0500 X-Authentication-Warning: mailhost.advanced.org: Host mail.rrl.co.uk [195.166.68.179] claimed to be dmz0101.rrl.co.uk Received: from nts006.rrl.co.uk (unverified) by dmz0101.rrl.co.uk (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 15 Feb 2001 11:10:25 +0000 Received: from nts006.rrl.co.uk (unverified) by nts006.rrl.co.uk (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 15 Feb 2001 11:08:37 +0000 Received: by nts006.rrl.co.uk with Internet Mail Service (5.5.2650.21) id <1V358T8S>; Thu, 15 Feb 2001 11:08:37 -0000 Message-ID: From: "Hamid.Asgari" To: "'shalunov@internet2.edu'" , "'ben@advanced.org'" , "'matt@advanced.org'" Cc: "'ippm@advanced.org'" Date: Thu, 15 Feb 2001 11:08:36 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [ippm] Comments on OWDP IETF draft Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Hello Stanislav, Benjamin, and Matthew Please find below some comments on the OWDP IETF draft. I am new to the list. Please forgive me if these issues have already been raised in the list. 1- There is the possibility that a server may want to initiate an active test measurement between a source and destination. I mean, shouldn't be better that the request also come from the server to instruct a source client (located at a measurement machine) for creating test sessions and inform the destination. This is normally done in large private networks where a centralised server is responsible for initiating and collecting measurement information for SLA purposes. 2- Is OWDP protocol aimed to be used at best-effort networks or it is also aimed at QoS-enabled networks where one-way delay measurements play an important role for traffic engineering purposes? Traffic forwarded in the QoS-enabled networks might encounter a differentiation into several CoS. As traffic belonging to each CoS has certain requirements and exhibit a certain behaviour, there is no longer a single metric result adequate for all packets belonging to a different CoS. Therefore, the measurement methodology must be aware of these classes of services. The OWDP test packets are UDP using unspecified ports. I think the protocol doesn't incorporate the DiffServ Code Points awareness. If the protocol is aimed at QoS-enabled network, I think the DSCP must be taken into account in the request session messages. This must enable a source to have multiple test sessions (each for a CoS) with a single destination. The ability to mark the test packets with appropriate DSCP, enables the test packet to the pass through the same queues and follow the same path as the particular QoS traffic under test. It is obvious that the DSCP can be set in the IP header but with the current method, the source must be able to map it to the requested port somehow and the test recipient must be aware of this mapping in order to be able to distinguish between the test packets coming from a single source belonging to different code points. 3- Section 4.2: the packet IP header (source, destination, port , etc.) needs to be stored as the destination may have multiple test sessions with one or more sources. Best regards, Hamid Asgari Thales Research Limited Worton Drive, Worton Grange Industrial Est. Berkshire RG2 0SB, UK Email: Hamid.Asgari@rrl.co.uk ******************************************************************************* This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and may not be divulged to any third party without the express permission of the originator. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thales Research Ltd. Following the acquisition of Racal Electronics plc by Thomson-CSF, please note that our new name is Thales Research Ltd. For more information regarding the Thales Group (formerly Thomson-CSF) please see our website www.Thalesgroup.com ******************************************************************************* _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 15 11:31:15 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22432 for ; Thu, 15 Feb 2001 11:31:15 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1FGQ6307949; Thu, 15 Feb 2001 11:26:06 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1FGPo307925 for ; Thu, 15 Feb 2001 11:25:50 -0500 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id LAA09306 for ; Thu, 15 Feb 2001 11:25:49 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id BDF7B8B1; Thu, 15 Feb 2001 11:25:48 -0500 (EST) To: ippm@advanced.org Subject: Re: [ippm] Comments on OWDP IETF draft References: From: stanislav shalunov Date: 15 Feb 2001 11:25:48 -0500 In-Reply-To: Message-ID: <87bss3hq0j.fsf@cain.internet2.edu> Lines: 43 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Hamid, "Hamid.Asgari" writes: > 1- There is the possibility that a server may want to initiate an > active test measurement between a source and destination. [...] In this case, the server by definition becomes a client (and can follow the normal test initiation procedure). > 2- [...] I think the DSCP must be taken into account in the request > session messages. We heard the request before and want to include something to that effect. As you know, DSCP values per se have only local significance, and we're still unsure how we should approach this (one could use a 16-bit PHB descriptor, but then you have the problem of mapping those to DSCP values, and the only reasonable way for an implementor to solve that problem for now is via a config file; ouch). Unfortunately, for now there's not a lot of understanding how DSCP values will actually be used. We may simply include DSCP, or go for PHB descriptor. > 3- Section 4.2: the packet IP header (source, destination, port , > etc.) needs to be stored as the destination may have multiple test > sessions with one or more sources. I don't quite understand what you mean here; Section 4.2 is 14 lines and titled "OWDP-Control Commands". In any case, naturally the server is expected to store the data in such a way that it can serve a Retrieve-Session command. What precisely will be done is up to implementors. Thanks for the comments. -- 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@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 15 12:13:03 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23761 for ; Thu, 15 Feb 2001 12:13:03 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1FH83311129; Thu, 15 Feb 2001 12:08:03 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1FH7q311094 for ; Thu, 15 Feb 2001 12:07:52 -0500 Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id SAA11850 for ; Thu, 15 Feb 2001 18:07:48 +0100 (CET) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id SAA29782 for ; Thu, 15 Feb 2001 18:07:48 +0100 (CET) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Thu, 15 Feb 2001 18:07:48 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: ippm@advanced.org Subject: Re: [ippm] Comments on OWDP IETF draft In-Reply-To: <87bss3hq0j.fsf@cain.internet2.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List On 15 Feb 2001, stanislav shalunov wrote: > Hamid, > > "Hamid.Asgari" writes: > > > 1- There is the possibility that a server may want to initiate an > > active test measurement between a source and destination. [...] > > In this case, the server by definition becomes a client (and can > follow the normal test initiation procedure). Is this true? If I understood it correctly, then the standard case in OWDP is that A sets up a session that sends traffic from A to B, then starts sending traffic. However, Hamid wants the opposite: A sets up a session that then sends traffic from B back to A. This is certainly a useful feature to have, but it does require that different processes are started on both ends. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 15 13:19:31 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26365 for ; Thu, 15 Feb 2001 13:19:31 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1FII3315900; Thu, 15 Feb 2001 13:18:03 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1FIHL315838 for ; Thu, 15 Feb 2001 13:17:21 -0500 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id NAA12299 for ; Thu, 15 Feb 2001 13:17:21 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id 347228B1; Thu, 15 Feb 2001 13:17:20 -0500 (EST) To: ippm@advanced.org Subject: Re: [ippm] Comments on OWDP IETF draft References: From: stanislav shalunov Date: 15 Feb 2001 13:17:20 -0500 In-Reply-To: Message-ID: <873ddfhkun.fsf@cain.internet2.edu> Lines: 23 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List "Henk Uijterwaal (RIPE-NCC)" writes: > If I understood it correctly, then the standard case in OWDP is that > A sets up a session that sends traffic from A to B, then starts > sending traffic. However, Hamid wants the opposite: A sets up a > session that then sends traffic from B back to A. Now you can open an OWDP-Control session from A to B (A is Control-Client and B is Server in draft terminology), after which A can proceed to request OWDT-Test sessions going from an arbitrary place to another arbitrary place (this may be from B to A). Is that sufficient? I (mis?)interpreted Hamid's request as asking to include functionality to allow B to request OWDP-Test sessions in the same OWDP-Control session. This functionality is not present. B would have to open an OWDP-Control session back to A if it decides it wants anything from A. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ I never let school stand in the way of my education. -- Mark Twain _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Feb 16 02:54:32 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24651 for ; Fri, 16 Feb 2001 02:54:32 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1G7p4323971; Fri, 16 Feb 2001 02:51:04 -0500 Received: from fw1b.telekom.de (gw1.telekom.de [194.25.15.11]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f1G7oU323950 for ; Fri, 16 Feb 2001 02:50:30 -0500 X-Authentication-Warning: mailhost.advanced.org: Host gw1.telekom.de [194.25.15.11] claimed to be fw1b.telekom.de Received: by fw1b.telekom.de; (5.65v4.0/1.3/10May95) id AA15268; Fri, 16 Feb 2001 08:50:28 +0100 Received: from Q9J99.mgb01.telekom.de by U9JWN.mgb01.telekom.de with ESMTP for ippm@advanced.org; Fri, 16 Feb 2001 08:50:15 +0100 Received: from g8pbr.blf01.telekom.de by Q9J99.mgb01.telekom.de with ESMTP for ippm@advanced.org; Fri, 16 Feb 2001 08:50:09 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2650.21) id <1RPASBHV>; Fri, 16 Feb 2001 08:50:02 +0100 Message-Id: From: "Geib, Ruediger" To: ippm@advanced.org Subject: RE: [ippm] Comments on OWDP IETF draft Date: Fri, 16 Feb 2001 08:50:08 +0100 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id f1G7oU323950 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.advanced.org id f1G7p4323971 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA24651 Stan, >> 2- [...] I think the DSCP must be taken into account in the request >> session messages. > We heard the request before and want to include something to that > effect. As you know, DSCP values per se have only local significance, > and we're still unsure how we should approach this (one could use a > 16-bit PHB descriptor, but then you have the problem of mapping those > to DSCP values, and the only reasonable way for an implementor to > solve that problem for now is via a config file; ouch). > > Unfortunately, for now there's not a lot of understanding how DSCP > values will actually be used. > > We may simply include DSCP, or go for PHB descriptor. The above mentioned usage of the 16 bit PHB descriptor is the better one. The mapping which may occur could very well be one of the issues why a remote domain wants to initiate a measurement. As a remote domain doesn't know which DSCPs are used in your local network, there's no point in requesting a DSCP only. Another attempt may be to signal for a test stream making use of a "globally well known service", which would be mapped to a PHB and from there to a DSCP. Today that's obviously science fiction, but it may be good to leave space for extension in the protocol which would allow to signal for a globally well defined service. Maybe having some two bits in front of the 16 bit PHB descriptor saying: 00-DSCP, 01-PHB Descriptor and 10-Globally Well Known Service. You'll always need just one of these. default would be "all zero"-Best Effort. (If we can agree about the idea, we'll replace "globally well known service" by a suitable term then.) Regards, Rüdiger _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Feb 16 11:51:11 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03677 for ; Fri, 16 Feb 2001 11:51:11 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1GGk3315898; Fri, 16 Feb 2001 11:46:03 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1GGjY315877 for ; Fri, 16 Feb 2001 11:45:34 -0500 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id LAA06338 for ; Fri, 16 Feb 2001 11:45:34 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id 1AE1A8B1; Fri, 16 Feb 2001 11:45:33 -0500 (EST) To: ippm@advanced.org Subject: [ippm] DSCP vs. PHB descriptor in OWDP References: From: stanislav shalunov Date: 16 Feb 2001 11:45:33 -0500 In-Reply-To: Message-ID: <878zn6efv6.fsf@cain.internet2.edu> Lines: 39 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List "Geib, Ruediger" writes: > The above mentioned usage of the 16 bit PHB descriptor is the better > one. Vote recorded. > The mapping which may occur could very well be one of the issues why > a remote domain wants to initiate a measurement. How so? If I initiate measurements (using PHB descriptor or well-known service) wouldn't I see the DSCP I'd expect to see in my network because of mappings? > As a remote domain doesn't know which DSCPs are used in your local > network, there's no point in requesting a DSCP only. The idea was I think that this way you can get a shot at what you think it could be ("umm, will 46 work"?). If it comes out right on your end, you know you got it right if your network polices/remaps uniformly. > Maybe having some two bits in front of the 16 bit PHB descriptor > saying: 00-DSCP, 01-PHB Descriptor and 10-Globally Well Known > Service. You'll always need just one of these. This seems like an excellent resolution of the problem to me personally (with possible reservation about well-known services). Thanks a lot for the suggestion. Would you like to go into detail in re space needed for expressing a globally well-known service, and where should we refer for a list? (Wishful thinking.) What do you think should we do? -- 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@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Sat Feb 17 18:20:40 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08542 for ; Sat, 17 Feb 2001 18:20:39 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1HNG3323706; Sat, 17 Feb 2001 18:16:03 -0500 Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f1HJNc314826 for ; Sat, 17 Feb 2001 14:23:39 -0500 X-Authentication-Warning: mailhost.advanced.org: Host louie.udel.edu [128.175.2.33] claimed to be mail.eecis.udel.edu Received: from galois.cis.udel.edu by mail.eecis.udel.edu id aa20868; 17 Feb 2001 14:22 EST Date: Sat, 17 Feb 2001 14:20:50 -0500 (EST) From: Constantinos Dovrolis To: Constantinos Dovrolis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [ippm] ICNP 2001 - Call for papers Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List (you will probably receive this message multiple times.. my apologies) -------------------------------------------------------------------------- CALL FOR PAPERS -------------------------------------------------------------------------- 9th International Conference on Network Protocols (ICNP 2001) Mission Inn, Riverside, California November 11-14, 2001 http://www.cis.udel.edu/icnp2001/ In just eight years, ICNP has established itself as one of the premier conferences in the computer networking field. ICNP deals with all aspects of communication protocols, from design and specification, to verification, testing, performance analysis, and implementation. Protocol functions of interest include network access, switching, routing, flow and congestion control, multimedia transport, wireless and mobile networks, network security, web protocols and applications, electronic commerce, network management, interoperability, internetworking, home computing and networks and digital broadcasting. ICNP 2001 will be held in Riverside, California, at the Mission Inn, a place filled with history. Riverside is located in the Sunny Southern California, 60 miles from Los Angeles, 45 miles from Palm Springs and 40 miles from Disney Land. The city is served by three nearby airports: Los Angeles, Ontario (California) and Orange County Airport. Important Dates: Paper Submission Deadline: May 7, 2001 Notification of Acceptance: July 13, 2001 Camera Ready Due: August 8, 2001 Tutorials: November 11, 2001 Conference: November 12 - 14, 2001 General Chair Satish K. Tripathi, University of California - Riverside Technical Program Co-Chairs Magda El Zarki, University of California, Irvine Klara Narhstedt, University of Illinois, Urbana-Champaign Tutorial Co-Chairs Pravin Bhagwat, AT&T Research Ed Knightly, Rice University Local Arrangement and Registration Co-Chairs Michalis Faloutsos, University of California - Riverside Srikant Krishnamurthy, University of California - Riverside Publicity Co-Chairs Constantinos Dovrolis, University of Delaware Samar Singh, La Trobe University, Australia ICNP Steering Committee Mostafa Ammar, Georgia Insitute of Technology Mohamed Gouda, University of Texas at Austin Simon Lam, University of Texas at Austin David Lee, Bell Labs Ming T. (Mike) Liu, Ohio State University Raymond Miller, University of Maryland, College Park Krishan Sabnani, Bell Labs ------------------------------------------------------------------ Constantinos Computer and Information Sciences - University of Delaware http://www.cis.udel.edu/~dovrolis/ _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 19 03:52:29 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00512 for ; Mon, 19 Feb 2001 03:52:29 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1J8l4303618; Mon, 19 Feb 2001 03:47:04 -0500 Received: from fw1b.telekom.de (gw1.telekom.de [194.25.15.11]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f1J8kD303592 for ; Mon, 19 Feb 2001 03:46:14 -0500 X-Authentication-Warning: mailhost.advanced.org: Host gw1.telekom.de [194.25.15.11] claimed to be fw1b.telekom.de Received: by fw1b.telekom.de; (5.65v4.0/1.3/10May95) id AA04768; Mon, 19 Feb 2001 09:46:12 +0100 Received: from Q9J99.mgb01.telekom.de by U9JWN.mgb01.telekom.de with ESMTP for ippm@advanced.org; Mon, 19 Feb 2001 09:44:35 +0100 Received: from g8pbr.blf01.telekom.de by Q9J99.mgb01.telekom.de with ESMTP for ippm@advanced.org; Mon, 19 Feb 2001 09:26:06 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Feb 2001 09:25:22 +0100 Message-Id: From: "Geib, Ruediger" To: ippm@advanced.org Subject: RE: [ippm] DSCP vs. PHB descriptor in OWDP Date: Mon, 19 Feb 2001 08:18:33 +0100 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id f1J8kD303592 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.advanced.org id f1J8l4303618 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA00512 > Stanislav Shalunov wrote > Would you like to go into detail in re space needed for expressing a > globally well-known service, and where should we refer for a list? > (Wishful thinking.) What do you think should we do? To me a two bit indicator (indicating the trailor to be either DSCP, PHB ore service) followed by a 16 bit trailor seems to be ok. If you don't care about coding space, a single 32 bit word (which may only be partially used by now) seems perfect to me. I have to decline on suggestions of globally well known services. Maybe the settings for the globally well known service should get the status "experimental". I think field trials have to be performed to validate the few services defined today (QBone Premium, Virtual Wire, ITU's and some others currently under construction). Once the community has the feeling, a service gets globally well known, an IPPM measurement code point (or a general "Per Domain Behaviour ID") should be specified. Regards, Rüdiger _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Feb 20 20:15:03 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01141 for ; Tue, 20 Feb 2001 20:15:02 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1L1B3314684; Tue, 20 Feb 2001 20:11:03 -0500 Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1L1Av314663 for ; Tue, 20 Feb 2001 20:10:59 -0500 X-Authentication-Warning: mailhost.advanced.org: Host ckmso1.att.com [12.20.58.69] claimed to be ckmso1.proxy.att.com Received: from hogpa.mt.att.com ([135.16.74.2]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f1L1Au123610 for ; Tue, 20 Feb 2001 20:10:56 -0500 (EST) Received: from acmortonw.att.com by hogpa.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id UAA18535; Tue, 20 Feb 2001 20:11:33 -0500 Message-Id: <5.0.0.25.0.20010219123312.02b08a70@hogpa.mt.att.com> X-Sender: acm1@hogpa.mt.att.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 20 Feb 2001 20:10:08 -0500 To: ippm@advanced.org From: Al Morton Subject: Re: [ippm] New ipdv draft (attached) In-Reply-To: <3A78AD0D.13214834@torrentnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Phil and all, Here's a few more comments on the "ippm-list-only" draft, you sent At 07:25 PM 01/31/2001 -0500: * Section 4.4 Definition (of singleton metric) The first paragraph is new. It's not clear why an index number should be assigned at the Dst (MP2). The Dst/MP2 index would not increment when a packet is lost. Perhaps you meant MP1? The ipdv definition is based on sending times (T1 and T2) and the need to track sending sequence is clear. Also, Mike Pierce noted that the third paragraph (a single line) is redundant. It appears to be the last line fragment of a NOTE that you deleted, and should go too. * Section 4.5 Discussion In the last paragraph, you give the assumption of Poisson sampling described in the Framework RFC. Given the development of the npmps draft, would it be appropriate to allow for alternative sampling methods here (and in Section 5, as Mike suggested)? I also want to be sure that ipdv is applicable to passive measurement, e.g., on a stream of RTP/UDP/IP packets conveying constant bit rate media. * Section 5.5 Discussion (of Samples) The third paragraph gives two examples of the selection function. The 2nd example gives the triple: where D(i) denotes the one-way delay of the ith packet of a stream. If ipdv is reported, should the triple be to be consistent with the definition in section 4.4? The last paragraph in Sec 5.5 gives two references (both to [9]), and one of them should probably be [3] or [8]. (the latest draft of [8] is dated 11/2000). * Section 6 Statistics for One-way-ipdv Mike had substantial comments here. I would like to see the jitter definition [RFC 2598] in current section 6.5 preserved. This is a good spot to mention similarities to the computation of smoothed jitter in RTP [RFC 1889 section 6.3.1]. It should be valuable to include a statistic that can be related to measurements made by user's endpoints. Thanks for your efforts, Phil. The flexibility you've built into this draft accommodates a range of opinions on delay variation. Al _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 22 02:11:55 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05544 for ; Thu, 22 Feb 2001 02:11:55 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1M783k27410; Thu, 22 Feb 2001 02:08:03 -0500 Received: from galatea (localhost [127.0.0.1]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f1M77Ik26856; Thu, 22 Feb 2001 02:07:18 -0500 X-Authentication-Warning: mailhost.advanced.org: Host localhost [127.0.0.1] claimed to be galatea From: "Matthew J Zekauskas" To: "Phil Chimento" , Cc: "Matt Zekauskas" Subject: RE: [ippm] New ipdv draft (attached) Date: Thu, 22 Feb 2001 02:20:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <5.0.0.25.0.20010219123312.02b08a70@hogpa.mt.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit In addition to the comments already received... Perhaps we can change the name in section 5.1 from Type-P-One-way-ipdv-stream to Type-P-One-way-ipdv-Poisson-stream; we did this in drafts for RFC 2679 and RFC 2680 to allow for the possibility of other types. A nit: In the last sentence of 5.5, you say "proposed in [9] and the one proposed in [9]." 7 and 9? --Matt _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 22 07:09:04 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08163 for ; Thu, 22 Feb 2001 07:09:04 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1MC48k25266; Thu, 22 Feb 2001 07:04:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1MC3Kk24015 for ; Thu, 22 Feb 2001 07:03:20 -0500 X-Authentication-Warning: mailhost.advanced.org: Host odin.ietf.org [132.151.1.176] claimed to be ietf.org Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07440; Thu, 22 Feb 2001 07:03:19 -0500 (EST) Message-Id: <200102221203.HAA07440@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 22 Feb 2001 07:03:19 -0500 Subject: [ippm] I-D ACTION:draft-ietf-ippm-ipdv-06.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : IP Packet Delay Variation Metric for IPPM Author(s) : C. Demichelis, P. Chimento Filename : draft-ietf-ippm-ipdv-06.txt Pages : 10 Date : 21-Feb-01 This memo refers to a metric for variation in delay of packets across Internet paths. The metric is based on the difference in the One-Way- Delay of selected packets. This difference in delay is called 'IP Packet Delay variation.' The metric is valid for measurements between two hosts both in the case that they have synchronized clocks and in the case that they are not synchronized. We discuss both in this draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-ipdv-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-ipdv-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010221145012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-ipdv-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-ipdv-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010221145012.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 22 07:09:08 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08174 for ; Thu, 22 Feb 2001 07:09:07 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1MC43k25251; Thu, 22 Feb 2001 07:04:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1MC3Fk24002 for ; Thu, 22 Feb 2001 07:03:19 -0500 X-Authentication-Warning: mailhost.advanced.org: Host odin.ietf.org [132.151.1.176] claimed to be ietf.org Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07423; Thu, 22 Feb 2001 07:03:15 -0500 (EST) Message-Id: <200102221203.HAA07423@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 22 Feb 2001 07:03:15 -0500 Subject: [ippm] I-D ACTION:draft-ietf-ippm-owdp-02.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : A One-way Delay Measurement Protocol Author(s) : S. Shalunov, B. Teitelbaum, M. Zekauskas Filename : draft-ietf-ippm-owdp-02.txt Pages : 22 Date : 21-Feb-01 The IETF IP Performance Metrics (IPPM) working group has proposed draft standard metrics for one-way packet delay [RFC2679] and loss [RFC 2680] across Internet paths. Although there are now several measurement platforms that implement collection of these metrics [SURVEYOR], [RIPE], there is to date no standard that would permit initiation of test streams or exchange of packets to collect singleton metrics in an interoperable manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-owdp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-owdp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010221144956.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-owdp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-owdp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010221144956.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 22 15:37:56 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26536 for ; Thu, 22 Feb 2001 15:37:56 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1MKW3m27282; Thu, 22 Feb 2001 15:32:03 -0500 Received: from brixcorp2.brixnet.com ([63.122.27.34]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1MK4xm21480 for ; Thu, 22 Feb 2001 15:04:59 -0500 X-Authentication-Warning: mailhost.advanced.org: Host [63.122.27.34] claimed to be brixcorp2.brixnet.com Received: by BRIXCORP2 with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Feb 2001 15:04:58 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB9B7FA4@BRIXCORP2> From: "Cucchiara, Joan" To: "'stanislav shalunov'" , "Cucchiara, Joan" Cc: ippm@advanced.org, "Harvell, Scott" , "Hedayat, Kaynam" , "Kaufman, David" , "Dunning, John" , "Naylor, Bob" , "Pyrik, Dan" , "Pacheco, John" Subject: RE: [ippm] Comments on draft-ietf-ippm-owdp-01.txt Date: Thu, 22 Feb 2001 15:04:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Hi Stanislav, Part 1 is removed. Thank you for those clarifications. Additional comments and questions on Part 2 are inline. -Joan > "Cucchiara, Joan" writes: > > > > Part II. Request for Changes or Additions to the Draft > > ------------------------------------------------------ > > > > 1) A clearer picture of the requirements/goals and non-goals > > upfront would be helpful. This was also discussed recently > > on the list. > > ...and will be provided. Thanks! > > > 2) In addition to the software-based timestamp method presented > > in the draft, could an option be added for out-of-band > > communication of hardware-based timestamps from the > > session-sender be added? > > > > This could be between either the session-sender > > and session-receiver, or between session-sender and the server. > > > > Please note, hardware-based timestamping prevents the > transmission > > of timestamps inside packets (by its nature, the timestamp is > > retrieved after the packet is sent out). > > I'm not sure I understand. If timestamps aren't in the packets, where > are they? I'm not sure what you mean. Say, when SmartBits puts > timestamps into their packets on the PIC, they insert it in the packet > (where else?). Our system has a very accurate method of timing packets without incorporating software time into the measurement. In this context software time means the time spent in the IP stack and network drivers of the measurement system. We timestamp packets as they are transmitted onto the wire. Therefore we have the timestamp after the packet has left the box. This is the only true measurement of timing that is not affected by system timing and load. As you can see our timestamps are not inside the packets and have to be communicated out of band. > > > 3) We'd like to see suppport for an "application level" > mimicing capability. > > This was not a goal. One of the reasons is that effective application > emulation would require substantial new (non-existing) research far > beyond packet formats. I agree with your comment however emulating certain data streams is in effect emulating certain packet formats (i.e RTP). Our intention is not to emulate the whole application but to emulate the application's stream. (more on this later). > > > 4) Are there any plans for a "flights of packets" approach? > > I'm not sure I understand. Do you mean non-Poisson inter-packet > distribution? > > We had some pretty extensive discussion on this internally, and the > short summary of what I believe we came to was that it'd be nice to be > able to specify a number of other distributions (in particular, > back-to-back tuples), but we don't really have ideas on how to do it > in a good general way. Since there's an IPPM singleton metric, which > essentially implies Poisson, we decided we'll stick with just that for > now. > > This doesn't mean non-Poisson distribution is off the agenda for the > future. We are eager to contribute to non-Poisson distribution. Non-poisson inter-packet distribution is another means to emulate certain application stream patterns. We feel that is a more effective way to measure performance metrics for a given application with certain non-poisson inter-packet distribution. (this is related to number 3 above.) > > > 5) There should be a way to choose other encryption options > > such as SSL. Having AES be the only one and having this > > as required is not particularly flexible or extensible, > > Are there any plans to add additional options here? > > There are no such plans. Why would you want an extensible or flexible > something where requirements are quite clear? > > In particular regard to SSL, none of the ciphers, versions, or modes > (all the zillions of total combinations provided because of U.S. govt > stance on encryption technology) provide individual message > authentication. > > Blocks of zeros in CBC mode for an 128-bit-block block cipher provides > it. We are not against having AES only wonder why other encryption methods are not offered. These could be negotiated between the endpoints during setup. > > > > 6) We would also like to see the one-way delay in both > > directions, so from A to B, and then back from B to A. > > This would be a good indication of where time is spent in the > > round-trip time (which leg, from A to B or B to A.) > > The idea is that once you have the primitive that allows you to > measure one-way, you can easily measure in both directions with two > individual OWDP-Test sessions. Although this is not so much an issue for UDP, there is the issue of "same path" being used in both directions. The idea on our system is that you can lower the overhead of the test from control connection, etc. if you do both measurements at the same time. Our customers initial feedback indicates that they find this a useful feature. > > > 7) For a standard, we thought the format of the control > > plane messages should be modeled after a TLV. > > This wasn't really ingestigated as any serious extensibility goes > contrary to the goal of having a really simple easy-to-implement > control protocol. We didn't have a goal to design a flexible > general-purpose protocol for "passing things". > > If you feel strongly about the issue and have a specific model in > mind, do tell us! The TLV format would offer consistency in the packet format. It is also somewhat widely used and understood so would help to advance the protocol. This format is also easy to extend, which may not be a goal at the moment but assuming there is a rev 2 of the protocol, then adopting a consistent packet format would make a rev 2 much easier, e.g. packets could be deprecated based on the "type" and new types added, and that is much easier than trying to rewrite various kinds of packet formats. It is also a lot less coding, debugging, etc. We consider this fairly important because of the reasons stated above, and would encourage use of this format for packets. We can provide examples if you think that would be helpful. > > > Also, this would allow vendors to add their own features. > > Assuming that a type code was for "vendor's use". > > While it's a limited expansion machanism, one can steal a mode bit now > for "I support Frobnitz extensions set". We believe a more flexible method is needed. > > > 8) The calculation for acceptible jitter may be simplified > > (and perhaps made more precise?) by including a "length of time > > for test". Since you are including how many packets, this > > would also be a reasonable piece of information to include > > in the control plane. > > I don't think I understand how calculation of jitter would be > simplified by that, since the way it is now you can compute jitter in > one pass while getting Retrieve-Session results back (it's just the > standard deviation of the difference of send/receive timestamps). > How could it possibly be any simpler than one pass on the data as it > is coming? > > Or do I misunderstand something? Where do you want to have total > duration--in Request-Session or in Retrieve-Session results? > > > Also, this would eliminate the requirement for AES based > > pseudo-random sample interval calculation that allows > the receiver to > > determine the packet send time. > > How so? You still need to know when the next packet is scheduled to > be sent to know when to decide it's not coming, right? > > > We'd also like to see an acceptable jitter parameter that could > > be used to tag late packets vs. lost packets. This is > > the approach take by most VoIP equipment. This would be > an option > > instead of sending the inverse-lambda in the Request-Session > > message. > > Inverse-Lambda is the mean time between packets. It determines the > properties of the test stream and must be in the protocol. > > Max latency threshold, on the other hand, is a matter of processing. > You can always discard packets that you consider "late". > > We decided that the protocol needs to provide complete information. > What you do with it is your choice. It's always easy to discard some > data. By late packets we are refering to packets that arrive to the receiver but with a jitter higher than a given amount. We are not concerned with latency. We are concerned with jitter. Typically VoIP endpoint have a jitter buffer with a certain length. All packets that arrive with a jitter higher than the length of the buffer are marked late and discarded. Specifying an acceptable jitter allows computation of the late packet metric. This is an extremely useful information for media based applications. > > > 9) Has support for Keep-Alives (or another message that could be > > exchanged during the session) with the ability to append user > > data to the messages, been considered? > > No, why? Any traffic on the TCP connection during the session > (between Start-Sessions and Stop-Sessions) was considered bad for two > reasons: > > * If there's a lot of it, it can affect measurement results. If that is a concern, the information can be transmitted when the test is done with transfering its data. > > * If there's connectivity loss during a session (say, an hour), we'd > like to continue to record losses rather than have the session fail. Without keep alives there is no way for transfer of out of band data. As we mentioned above we would like the flexibility of not passing timestamp information in the packets (and instead passing timestamp info out-of-band). Keep alives are also a flexible method for systems that may want to send other forms of out of band data. > > Thanks again for your feedback! > > -- > Stanislav Shalunov http://www.internet2.edu/~shalunov/ > > All revolutions are bloody. The October Revolution was bloodless, > but it was only the beginning. -- Dmitri Volkogonov > _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 22 18:16:00 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29989 for ; Thu, 22 Feb 2001 18:16:00 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1MN93m27669; Thu, 22 Feb 2001 18:09:03 -0500 Received: from galatea (localhost [127.0.0.1]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f1MN8sm27641 for ; Thu, 22 Feb 2001 18:08:54 -0500 X-Authentication-Warning: mailhost.advanced.org: Host localhost [127.0.0.1] claimed to be galatea From: "Matthew J Zekauskas" To: Date: Thu, 22 Feb 2001 18:21:54 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C09CFC.5585D620" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [ippm] draft-bradner-metricstest-00.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C09CFC.5585D620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit FYI. I would like to start a discussion here on this draft, and in particular about - if it's reasonable - what might be appropriate for the numbers that have been left unspecified There will also be an agenda item in Minneapolis, on this draft. --Matt -----Original Message----- From: nsyracus@cnri.reston.va.us [mailto:nsyracus@cnri.reston.va.us]On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, February 22, 2001 7:04 AM To: IETF-Announce: Subject: I-D ACTION:draft-bradner-metricstest-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Advancement of metrics specifications on the IETF Standards Track Author(s) : S. Bradner, A. Mankin et al. Filename : draft-bradner-metricstest-00.txt Pages : 6 Date : 21-Feb-01 The Internet Standards Process [RFC2026] requires that all IETF Standards Track specifications must have 'multiple, independent, and interoperable implementations' before they can be advanced beyond Proposed Standard status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bradner-metricstest-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-bradner-metricstest-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bradner-metricstest-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0000_01C09CFC.5585D620 Content-Type: Message/External-body; name="ATT00056.dat" Content-Disposition: attachment; filename="ATT00056.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20010221145046.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bradner-metricstest-00.txt ------=_NextPart_000_0000_01C09CFC.5585D620 Content-Type: Message/External-body; name="draft-bradner-metricstest-00.txt" Content-Disposition: attachment; filename="draft-bradner-metricstest-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20010221145046.I-D@ietf.org> ------=_NextPart_000_0000_01C09CFC.5585D620-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Feb 23 02:10:40 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23686 for ; Fri, 23 Feb 2001 02:10:40 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1N773m12284; Fri, 23 Feb 2001 02:07:03 -0500 Received: from fw1b.telekom.de (gw1.telekom.de [194.25.15.11]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f1N767m12252 for ; Fri, 23 Feb 2001 02:06:22 -0500 X-Authentication-Warning: mailhost.advanced.org: Host gw1.telekom.de [194.25.15.11] claimed to be fw1b.telekom.de Received: by fw1b.telekom.de; (5.65v4.0/1.3/10May95) id AA24689; Fri, 23 Feb 2001 08:06:06 +0100 Received: from Q9J99.mgb01.telekom.de by U9JWN.mgb01.telekom.de with ESMTP for ippm@advanced.org; Fri, 23 Feb 2001 08:06:06 +0100 Received: from g8pbr.blf01.telekom.de by Q9J99.mgb01.telekom.de with ESMTP for ippm@advanced.org; Fri, 23 Feb 2001 08:06:03 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Feb 2001 08:06:02 +0100 Message-Id: From: "Geib, Ruediger" To: ippm@advanced.org Subject: RE: [ippm] Comments on draft-ietf-ippm-owdp-01.txt Date: Fri, 23 Feb 2001 08:06:02 +0100 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id f1N767m12252 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.advanced.org id f1N773m12284 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA23686 I just wanted to indicate support for Joan's view. If we develop a new control plane protocol, why don't we apply state of the art message encoding rules? Regards, Rüdiger >>> 7) For a standard, we thought the format of the control >>> plane messages should be modeled after a TLV. >> This wasn't really ingestigated as any serious extensibility goes >> contrary to the goal of having a really simple easy-to-implement >> control protocol. We didn't have a goal to design a flexible >> general-purpose protocol for "passing things". >> >> If you feel strongly about the issue and have a specific model in >> mind, do tell us! > The TLV format would offer consistency in the packet format. > It is also somewhat widely used and understood so would help > to advance the protocol. This format is also easy to extend, > which may not be a goal at the moment but assuming there is a > rev 2 of the protocol, then adopting a consistent packet format > would make a rev 2 much easier, e.g. packets could be deprecated > based on the "type" and new types added, and that is much > easier than trying to rewrite various kinds of packet formats. > It is also a lot less coding, debugging, etc. > > We consider this fairly important because of the reasons > stated above, and would encourage use of this format for packets. > We can provide examples if you think that would be helpful. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 26 07:11:28 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06075 for ; Mon, 26 Feb 2001 07:11:28 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1QC63m04669; Mon, 26 Feb 2001 07:06:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1QC5Jm04520 for ; Mon, 26 Feb 2001 07:05:20 -0500 X-Authentication-Warning: mailhost.advanced.org: Host odin.ietf.org [132.151.1.176] claimed to be ietf.org Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04452; Mon, 26 Feb 2001 07:05:18 -0500 (EST) Message-Id: <200102261205.HAA04452@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 26 Feb 2001 07:05:17 -0500 Subject: [ippm] I-D ACTION:draft-ietf-ippm-btc-cap-00.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : A Bulk Transfer Capacity Methodology for Cooperating Hosts Author(s) : M. Allman Filename : draft-ietf-ippm-btc-cap-00.txt Pages : 5 Date : 23-Feb-01 This document specifies a specific Bulk Transfer Capacity (BTC) metric based on the BTC framework outlined in [MA00]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-btc-cap-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-btc-cap-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-btc-cap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010223130619.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-btc-cap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-btc-cap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010223130619.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 26 15:21:26 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25698 for ; Mon, 26 Feb 2001 15:21:26 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1QKF3m08695; Mon, 26 Feb 2001 15:15:03 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1QJdYm24770 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Mon, 26 Feb 2001 14:39:37 -0500 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1QJcI423247; Mon, 26 Feb 2001 14:38:19 -0500 X-Authentication-Warning: mail.internet2.edu: Host localhost [127.0.0.1] claimed to be cain.internet2.edu Received: by cain.internet2.edu (Postfix, from userid 1000) id 5C6428B4; Mon, 26 Feb 2001 14:39:33 -0500 (EST) To: "Cucchiara, Joan" Cc: ippm@advanced.org, "Harvell, Scott" , "Hedayat, Kaynam" , "Kaufman, David" , "Dunning, John" , "Naylor, Bob" , "Pyrik, Dan" , "Pacheco, John" Subject: Re: [ippm] Comments on draft-ietf-ippm-owdp-01.txt References: <07B0D4912B83D31188F300A0C9F62EBB9B7FA4@BRIXCORP2> From: stanislav shalunov Date: 26 Feb 2001 14:39:33 -0500 In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB9B7FA4@BRIXCORP2> Message-ID: <87itlxjksq.fsf@cain.internet2.edu> Lines: 96 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Joan, There are quite a few issues that you raise, so I'll answer one-by-one. I apologize for not sending a reply earlier. In re a posteriori packet sending time acquisition: We have not anticipated using a mechanism such as the one that you describe for timestamping. I'm not even sure what would be the "right" way of coping with such scenario. Transmitting timestamps as packets are sent on the control connection probably isn't right, as it would hinder one's ability to observe extended periods of losses. This needs further understanding and discussion. Can you provide more details about the mechanism? In re application traffic simulation: I think we should at least define metrics we're interested in before we attempt to measure them. Defining useful and relevant metrics for application simulation can be hard, and non-destructive measurement will likely be impossible (it's sort of like Heisenberg principle if applications send a lot of traffic). In any case, defining these metrics would be outside of scope of draft-ietf-ippm-owdp, which defines a protocol for measurement of metrics that already exist, not new metrics. In re AES or other encryption schemes: We have rather specific requirements for encryption (see security considerations section). These requirements appear to be adequately met by the current scheme. Allowing any other options would seems to be a disadvantage for the following reasons: * To interoperate, one would need to require implementation of more than half of total ways to encrypt or requiring to always implement a particular way to encrypt. The former begs the question of why all the other ways are necessary at all, while the latter would quickly bloat the code. For a protocol that we hope can be implemented in embedded systems this is a significant problem. (Say, SSL tarball is currently at 1.5MB compressed with installed package requiring about 3.3MB; it also takes a significant amount of RAM for each session to run.) * To assess overall security, one would need to consider all of the options. The task of assessing security is hard as it is (by the way, security reviews are *very* welcome), why complicate it? * With general purpose encryption layers, we would need to guarantee integrity using a separate approach inside the protocol (using MACs presumably). Thus, instead of generalizing and abstracting, we'd just keep introducing new algorithms. Computing a MAC isn't any easier than doing a block cipher (in fact, many MACs are special applications of block ciphers). * To advance on the Standard Track, one will need to demonstrate interoperability of all options. This means, if we agree to include a whole bunch of options now, we'll need to implement them. What are the advantages and how do they outweigh the disadvantages? In re bidirectional measurements: I think a primitive to perform a unidirectional session is enough. If you will allow to use an analogy (imperfect as all analogies are), embedding bidirectional measurements right into the protocol is like designing an API to copy files, coming up with a function "int filecopy(char* src, char* dst)" and then deciding to provide ability to copy two files at once with "struct two_results* two_filecopy(char* src1, char* src2, char* dst1, char* dst2)". It's kludgey, makes it harder to use with all the auxiliary stuff around, is just as "limited" (why only two files are supported?), and doesn't actually reduce work, since both files still need to be copied (or, in our case, parameters for two sessions still need to be passed along with answers and all you're saving is possibly a measly few bytes on the control connection). Am I missing something? In re extensibility: You're welcome to suggest ways to improve it. Could you also please clarify what you believe is wrong with the scheme of using mode bits for extensions? In re "late packets": I believe that this is strictly a question of post-processing of measurement data and is therefore outside of scope of the protocol. In re keep-alives: Keep-alives per se would be something we'd rather *avoid*, because we *don't* want the TCP connection to break if there's a connectivity outage. We specifically and deliberately took care to not send anything on the control connection while the session is progress. Adding keep-alives to purposefully remove an advantageous property that the protocol currently possesses appears to be counter-intuitive. P.S.: draft-ietf-ippm-owdp-02.txt is out and is in all the usual places. I don't think changes in it have to do with any of your concerns, except the intro section stuff. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ All revolutions are bloody. The October Revolution was bloodless, but it was only the beginning. -- Dmitri Volkogonov _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 26 15:51:12 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26981 for ; Mon, 26 Feb 2001 15:51:12 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1QKm3m17629; Mon, 26 Feb 2001 15:48:03 -0500 Received: from orc.cs.waikato.ac.nz (orc.cs.waikato.ac.nz [130.217.241.22]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1QKljm17575 for ; Mon, 26 Feb 2001 15:47:46 -0500 Received: from orca.cs.waikato.ac.nz ([130.217.244.4] helo=cs.waikato.ac.nz ident=sfd) by orc.cs.waikato.ac.nz with esmtp (Exim 3.16 #6) id 14XUYa-00007E-00 for ippm@advanced.org; Tue, 27 Feb 2001 09:47:44 +1300 Message-ID: <3A9AC0EF.F3733F33@cs.waikato.ac.nz> Date: Tue, 27 Feb 2001 09:47:43 +1300 From: Stephen Donnelly Organization: The University of Waikato X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org Subject: Re: [ippm] Comments on draft-ietf-ippm-owdp-01.txt References: <07B0D4912B83D31188F300A0C9F62EBB9B7FA4@BRIXCORP2> <87itlxjksq.fsf@cain.internet2.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit stanislav shalunov wrote: > In re keep-alives: Keep-alives per se would be something we'd > rather *avoid*, because we *don't* want the TCP connection to break if > there's a connectivity outage. We specifically and deliberately took > care to not send anything on the control connection while the session > is progress. Adding keep-alives to purposefully remove an > advantageous property that the protocol currently possesses appears to > be counter-intuitive. Just a quick thought on keep-alives. Our site uses Cisco's stateful firewalling on the border router. To prevent the router running out of memory, it will reset any connection idle for more than one hour. I realise this isn't 'correct' behaviour, in fact it is a real nuisance, but in practise this kind of thing is probably common? This could be a real problem for owdp-control connections, assuming it is common to perform individual measurements for longer periods than one hour? Stephen. -- ----------------------------------------------------------------------- Stephen Donnelly (BCMS) email: sfd@cs.waikato.ac.nz WAND Group Room GG.15 phone +64 7 838 4086 Computer Science Department, University of Waikato, New Zealand ----------------------------------------------------------------------- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 26 16:26:06 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28242 for ; Mon, 26 Feb 2001 16:26:05 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1QLN3m28445; Mon, 26 Feb 2001 16:23:03 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1QLLwm28174 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Mon, 26 Feb 2001 16:22:03 -0500 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1QLKh421412 for ; Mon, 26 Feb 2001 16:20:43 -0500 X-Authentication-Warning: mail.internet2.edu: Host localhost [127.0.0.1] claimed to be cain.internet2.edu Received: by cain.internet2.edu (Postfix, from userid 1000) id 104E68B4; Mon, 26 Feb 2001 16:21:57 -0500 (EST) To: ippm@advanced.org Subject: [ippm] keep-alives & NATs: draft-ietf-ippm-owdp-02.txt References: <07B0D4912B83D31188F300A0C9F62EBB9B7FA4@BRIXCORP2> <87itlxjksq.fsf@cain.internet2.edu> <3A9AC0EF.F3733F33@cs.waikato.ac.nz> From: stanislav shalunov Date: 26 Feb 2001 16:21:57 -0500 In-Reply-To: <3A9AC0EF.F3733F33@cs.waikato.ac.nz> Message-ID: <87g0h1jg22.fsf_-_@cain.internet2.edu> Lines: 39 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Stephen Donnelly writes: > Just a quick thought on keep-alives. Our site uses Cisco's stateful > firewalling on the border router. To prevent the router running out > of memory, it will reset any connection idle for more than one hour. As a work-around for this particular broken behavior, you could set TCP keep-alive option on the control connection. In fact, you probably have already set net.inet.tcp.always_keepalive or your OS equivalent already--or your life must be really painful... Layer 4 keep-alives are already there. Why would you need layer 5 ones? > I realise this isn't 'correct' behaviour, in fact it is a real > nuisance, but in practise this kind of thing is probably common? If your "stateful firewall" is in fact a NAT, there are far worse problems than keeping the control connection from breaking. OWDP won't do anything interesting across NATs, and fundamentally there isn't anything practical one can do in order to run *any* one-way measurements to a host behind a NAT. That's just a general implication of NAT that has ot be taken into account when you deploy it. Even if your firewall isn't a NAT, how would it like OWDP-Test traffic? I'm willing to bet it'll drop it all. Practically speaking, you'd probably place an OWDP-Control server in the DMZ to be able to measure from it to the outside world, and place another one somewhere inside your network close to "the exit" to be able to measure your network performance. -- 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@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Feb 27 03:32:06 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01679 for ; Tue, 27 Feb 2001 03:32:06 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1R8S3m29850; Tue, 27 Feb 2001 03:28:03 -0500 Received: from mainserver.surfnetusa.com (mail.surfnetusa.com [208.201.152.2]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1R8R6m29818 for ; Tue, 27 Feb 2001 03:27:06 -0500 X-Authentication-Warning: mailhost.advanced.org: Host mail.surfnetusa.com [208.201.152.2] claimed to be mainserver.surfnetusa.com Received: from [63.67.14.34] by mainserver.bookholt.com (NTMail 5.06.0016/AX0201.00.06a07d84) with ESMTP id sbckebaa for ippm@advanced.org; Tue, 27 Feb 2001 00:29:30 -0800 Message-Id: <4.2.0.58.20010227001517.00a99e80@mail.merike.com> X-Sender: kaeo.merike@mail.merike.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 27 Feb 2001 00:17:59 -0800 To: ippm@advanced.org From: Merike Kaeo Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ippm] Fwd: FYI: draft-svdberg-temon-00.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List This may be of interest to some on the list who do not follow TEWG..... -merike >The following draft has been uploaded to the IETF server: > >"Some Issues for Designing a Measurement Architecture for Traffic >Engineered IP Networks." >(http://www.ietf.org/internet-drafts/draft-svdberg-temon-00.txt) > >This document tries to describe some requirements for measurements in >the context of a traffic engineered network. It would be great if the >traffic engineering working group could review this and give us some >comments on this work . > >Best regards, >Steven Van den Berghe _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Feb 27 04:34:33 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02172 for ; Tue, 27 Feb 2001 04:34:32 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1R9R3m02933; Tue, 27 Feb 2001 04:27:03 -0500 Received: from plinius.intec2.rug.ac.be (plinius.intec2.rug.ac.be [157.193.122.4]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1R9QDm02820 for ; Tue, 27 Feb 2001 04:26:14 -0500 Received: from intec.rug.ac.be (daisne.intec2.rug.ac.be [157.193.122.92]) by plinius.intec2.rug.ac.be (Postfix) with ESMTP id 7DD6BEEB6 for ; Tue, 27 Feb 2001 10:25:47 +0100 (CET) Message-ID: <3A9B72A5.6CB93B47@intec.rug.ac.be> Date: Tue, 27 Feb 2001 10:25:57 +0100 From: Steven Van den Berghe X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org Subject: Re: [ippm] Fwd: FYI: draft-svdberg-temon-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Hi Merike et al., I was just about to write the same message to the ippm-list, but it seems i need to learn to type a bit faster :) Thanks for noticing the document. The document is indeed intended to initiate a link between the requirements of traffic engineering and the efforts done in the IPPM working group. I must however warn you that, asside from the numerous spelling mistakes, the document should be consider as a very early first draft. I hope to get some comments from TEWG list to enhance it and to distill further requirements towards measurements. However, the main ingredients might already trigger some IPPM-activity: - distinction between operational and diagnostic measurements - co-ordination of passive and active measurement, (so result retrieval should be decoupeled from the measurement protocol) - higher level "metrics" (like "if metric > value then snmp-trap") to reduce the information flow Also, in the context of our proprietary traffic engineering work, we need to take into account MPLS, Multipath and DiffServ. So, referencing to the OWDP-protocol discussion, a type-P description might need even more then a "well-known service", DSCP or PHB description. Again, these remarks are only intended to be some triggers to get the larger discussion on the practical usage of measurements going. So, thanks for bringing this to the attention of the IPPM-WG and i hope that you all enjoy the document. Steven Van den Berghe PS: all the spelling mistakes are due to too much caffeine, too nightly hours and a crappy spelling checker. I'll fix them in a later version. Merike Kaeo wrote: > This may be of interest to some on the list who do not follow TEWG..... > > -merike > > >The following draft has been uploaded to the IETF server: > > > >"Some Issues for Designing a Measurement Architecture for Traffic > >Engineered IP Networks." > >(http://www.ietf.org/internet-drafts/draft-svdberg-temon-00.txt) > > > >This document tries to describe some requirements for measurements in > >the context of a traffic engineered network. It would be great if the > >traffic engineering working group could review this and give us some > >comments on this work . > > > >Best regards, > >Steven Van den Berghe > > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm Steven Van den Berghe steven.vandenberghe@intec.rug.ac.be Workgroup Broadband-Networks Department Information Technology Ghent University - Belgium Phone: +32 (0)9 267 35 86 | Fax : +32 (0)9 267 35 99 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* "Law of Cybernetic Entomology" There is always one more bug. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Feb 27 14:08:14 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24317 for ; Tue, 27 Feb 2001 14:08:13 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1RJ33m10511; Tue, 27 Feb 2001 14:03:03 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1RJ2jm10485 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Tue, 27 Feb 2001 14:02:49 -0500 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1RJ1UW05712 for ; Tue, 27 Feb 2001 14:01:30 -0500 X-Authentication-Warning: mail.internet2.edu: Host localhost [127.0.0.1] claimed to be cain.internet2.edu Received: by cain.internet2.edu (Postfix, from userid 1000) id BB0F58B4; Tue, 27 Feb 2001 14:02:44 -0500 (EST) To: ippm@advanced.org Subject: Re: [ippm] FYI: draft-svdberg-temon-00.txt References: <3A9B72A5.6CB93B47@intec.rug.ac.be> From: stanislav shalunov Date: 27 Feb 2001 14:02:44 -0500 In-Reply-To: <3A9B72A5.6CB93B47@intec.rug.ac.be> Message-ID: <87itlwkkyz.fsf@cain.internet2.edu> Lines: 27 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Steven Van den Berghe writes: > Also, in the context of our proprietary traffic engineering work, we > need to take into account MPLS, Multipath and DiffServ. So, > referencing to the OWDP-protocol discussion, a type-P description > might need even more then a "well-known service", DSCP or PHB > description. Steven, We've only specified DSCP and PHB ID for now, because these are the things that are standartized. Of course, in the future one might need to, say, send an RSVP packet before transmitting; since we don't yet know what signalling mechanisms will be used, and what services will be provided by them, it's not clear what more we can do at this point... But in the future, one hopes one could use 32-bit Type-P descriptor field with first bit set to 1 to describe whatever appears on the service arena. (There aren't too many services that one can imagine, and it's unlikely that too many mechanisms will be used to request them.) -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "Hey! Who took the cork off my lunch?!" -- W. C. Fields _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Feb 28 04:38:15 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01035 for ; Wed, 28 Feb 2001 04:38:14 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1S9T3m26422; Wed, 28 Feb 2001 04:29:03 -0500 Received: from plinius.intec2.rug.ac.be (plinius.intec2.rug.ac.be [157.193.122.4]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1S9Sgm26393 for ; Wed, 28 Feb 2001 04:28:42 -0500 Received: from intec.rug.ac.be (daisne.intec2.rug.ac.be [157.193.122.92]) by plinius.intec2.rug.ac.be (Postfix) with ESMTP id 35296EEA8; Wed, 28 Feb 2001 10:28:17 +0100 (CET) Message-ID: <3A9CC4B4.3EF74989@intec.rug.ac.be> Date: Wed, 28 Feb 2001 10:28:20 +0100 From: Steven Van den Berghe X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: stanislav shalunov , ippm@advanced.org Subject: Re: [ippm] FYI: draft-svdberg-temon-00.txt References: <3A9B72A5.6CB93B47@intec.rug.ac.be> <87itlwkkyz.fsf@cain.internet2.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Hi Stanislav, Thanks for your response. Your hopes were exactly the answer that i was looking for. Our proprietary architecture will probably be using a seperate configuration mechanism to map the Type-P descriptor to the exact Type-P format, unless the OWDP would allow for TLV-like extensions so we can do the mapping configuration that way (yep, you can count me as a supporter of the TLV-approach:)). I don't think that exentisibilety should be contrary to the easy-implement-goal, since a basic functionality as described by the current draft would be a "SHOULD be supported" and the TLV-extensions a "COULD be supported and SHOULD be ignored if not supported". Best Regards, Steven stanislav shalunov wrote: > Steven Van den Berghe writes: > > > Also, in the context of our proprietary traffic engineering work, we > > need to take into account MPLS, Multipath and DiffServ. So, > > referencing to the OWDP-protocol discussion, a type-P description > > might need even more then a "well-known service", DSCP or PHB > > description. > > Steven, > > We've only specified DSCP and PHB ID for now, because these are the > things that are standartized. Of course, in the future one might need > to, say, send an RSVP packet before transmitting; since we don't yet > know what signalling mechanisms will be used, and what services will > be provided by them, it's not clear what more we can do at this > point... > > But in the future, one hopes one could use 32-bit Type-P descriptor > field with first bit set to 1 to describe whatever appears on the > service arena. (There aren't too many services that one can imagine, > and it's unlikely that too many mechanisms will be used to request > them.) > > -- > Stanislav Shalunov http://www.internet2.edu/~shalunov/ > > "Hey! Who took the cork off my lunch?!" -- W. C. Fields > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm -- Steven Van den Berghe steven.vandenberghe@intec.rug.ac.be Workgroup Broadband-Networks Department Information Technology Ghent University - Belgium Phone: +32 (0)9 267 35 86 | Fax : +32 (0)9 267 35 99 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Computers aren't intelligent, they only think they are. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Feb 28 10:26:10 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09172 for ; Wed, 28 Feb 2001 10:26:10 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f1SFL2m09126; Wed, 28 Feb 2001 10:21:02 -0500 Received: from public.szptt.net.cn (mail2-smtp.szptt.net.cn [202.96.136.222]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f1SFK1m08542 for ; Wed, 28 Feb 2001 10:20:02 -0500 X-Authentication-Warning: mailhost.advanced.org: Host mail2-smtp.szptt.net.cn [202.96.136.222] claimed to be public.szptt.net.cn Received: from public.szptt.net.cn([202.96.136.225]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm53a9d8b3d; Wed, 28 Feb 2001 15:19:27 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm23a9ac089; Mon, 26 Feb 2001 14:39:41 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA14555 for ietf-123-outbound.01@ietf.org; Mon, 26 Feb 2001 07:45:00 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13855 for ; Mon, 26 Feb 2001 07:05:19 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04452; Mon, 26 Feb 2001 07:05:18 -0500 (EST) Message-Id: <200102261205.HAA04452@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 26 Feb 2001 07:05:17 -0500 Subject: [ippm] I-D ACTION:draft-ietf-ippm-btc-cap-00.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : A Bulk Transfer Capacity Methodology for Cooperating Hosts Author(s) : M. Allman Filename : draft-ietf-ippm-btc-cap-00.txt Pages : 5 Date : 23-Feb-01 This document specifies a specific Bulk Transfer Capacity (BTC) metric based on the BTC framework outlined in [MA00]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-btc-cap-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-btc-cap-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-btc-cap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010223130619.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-btc-cap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-btc-cap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010223130619.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm