[pm-dir] draft-bb-2544like-production-tests

Yaakov Stein <yaakov_s@rad.com> Thu, 11 April 2013 14:55 UTC

Return-Path: <yaakov_s@rad.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4615121F8EC6 for <pm-dir@ietfa.amsl.com>; Thu, 11 Apr 2013 07:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.597
X-Spam-Level:
X-Spam-Status: No, score=-103.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qepPIXi1BhRw for <pm-dir@ietfa.amsl.com>; Thu, 11 Apr 2013 07:55:25 -0700 (PDT)
Received: from rad.co.il (mailrelay01-q.rad.co.il [80.74.100.150]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9BB21F8D5F for <pm-dir@ietf.org>; Thu, 11 Apr 2013 07:55:19 -0700 (PDT)
Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 11 Apr 2013 17:52:58 +0300
Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Thu, 11 Apr 2013 17:55:11 +0300
From: Yaakov Stein <yaakov_s@rad.com>
To: "pm-dir@ietf.org" <pm-dir@ietf.org>
Thread-Topic: draft-bb-2544like-production-tests
Thread-Index: AQHONgKcKLcBfq+VNECrksFoS/H/PZjRCv4A
Date: Thu, 11 Apr 2013 14:55:10 +0000
Message-ID: <07F7D7DED63154409F13298786A2ADC904CFB452@EXRAD5.ad.rad.co.il>
References: <95067C434CE250468B77282634C96ED322A5016F@xmb-aln-x02.cisco.com> <516588E4.2010706@cisco.com>
In-Reply-To: <516588E4.2010706@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.17.140.37]
Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC904CFB452EXRAD5adradcoil_"
MIME-Version: 1.0
X-Commtouch-Refid: str=0001.0A090207.5166CED0.01EA,ss=1,fgs=0
Subject: [pm-dir] draft-bb-2544like-production-tests
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2013 14:55:26 -0000

PM-dir'ers

I was very relieved when RFC 6815 was finally published, since we finally convinced had a document
that clearly stated that measuring throughput of operational networks as if they were devices on a workbench was a bad idea.

I must have been sleeping to have missed it, but now I discovered the draft mentioned in the subject line,
which is attempting to bring back 2544 for operational networks, without addressing the main reason that it is such a bad idea.

Not only is this draft not aligned with IPPM work since the original 2544,
but also it rehashes the RFC 2544 method of blasting the network at physical line speed for a long time
instead of proposing the use of any of the modern mechanisms that discover throughput with minimum impact on the network
(e.g., MOSEAB, FORECASTER, etc).

Needless to say it doesn't consider the impact of such blasting without TCP-friendliness on neighboring TCP flows,
nor of dimming the lights in the entire neighborhood.

I think this is a draft that the PM directorate needs to discuss.

Y(J)S