Re: [bmwg] Benoit Claise's No Objection on draft-ietf-bmwg-imix-genome-04: (with COMMENT)
Benoit Claise <bclaise@cisco.com> Tue, 28 May 2013 21:53 UTC
Return-Path: <bclaise@cisco.com>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB37611E8101; Tue, 28 May 2013 14:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level:
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOl9CmSvo6-Z; Tue, 28 May 2013 14:53:14 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0D18D11E80FA; Tue, 28 May 2013 14:53:13 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4SLr88L029833; Tue, 28 May 2013 23:53:08 +0200 (CEST)
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4SLqhnQ024023; Tue, 28 May 2013 23:52:53 +0200 (CEST)
Message-ID: <51A5272B.60809@cisco.com>
Date: Tue, 28 May 2013 23:52:43 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "MORTON JR., ALFRED C (AL)" <acmorton@att.com>
References: <20130528140014.20675.12462.idtracker@ietfa.amsl.com> <F1312FAF1A1E624DA0972D1C9A91379A1C9F46A0FD@njfpsrvexg7.research.att.com>
In-Reply-To: <F1312FAF1A1E624DA0972D1C9A91379A1C9F46A0FD@njfpsrvexg7.research.att.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "bmwg-chairs@tools.ietf.org" <bmwg-chairs@tools.ietf.org>, The IESG <iesg@ietf.org>, "bmwg@ietf.org" <bmwg@ietf.org>, "draft-ietf-bmwg-imix-genome@tools.ietf.org" <draft-ietf-bmwg-imix-genome@tools.ietf.org>
Subject: Re: [bmwg] Benoit Claise's No Objection on draft-ietf-bmwg-imix-genome-04: (with COMMENT)
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bmwg>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 May 2013 21:53:19 -0000
Hi Al, Thanks for the quick reaction. All my points are addressed with your temp version. Regards, Benoit > Hi Benoit, > thanks for your comments, minimal replies where needed below. > Al > >> -----Original Message----- >> From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On Behalf Of >> Benoit Claise > ... >> COMMENT: >> ... Please engage in the discussion. >> >> >> - z=MTU is seen as valuable, so MTU MUST be specified if used. >> Where? by whom? The tester? Following Section 4 " The tester MUST >> complete the following table" example", you might need something such as: >> >> If the z (MTU) is used, the tester MUST specifiy the MTU value in the >> report > acm - I have added the sentence above (with slight clarification, see below), > and appended the following sentence to the scope and goals in section 2, > which should help to clarify the role of the document: > > Thus, the requirements presented in this specification, expressed in > [RFC2119] terms, are intended for those performing/reporting laboratory > tests to improve clarity and repeatability. > > >> - While this approach allows some flexibility, there are also >> constraints. >> >> o Non-RFC2544 packet sizes would need to be approximated by those >> available in the table. >> >> o The Genome for very long sequences can become undecipherable by >> humans. >> >> o z=MTU is seen as valuable, so MTU MUST be specified if used. >> >> o "jumbo" sizes are included. >> >> "jumbo" sizes are included: is this a constraint or an advantage? I >> thought it was an advantage. > acm - it is, but it evolved from a constraint when jumbo sizes were > not included. > Removed that last two bullets, above. > > > <editorial change fixed> > >> - >> +-----------------------+-------------------------+-----------------+ >> | Source | Destination | Corresponding | >> | Address/Port/Blade | Address/Port/Blade | IMIX | >> +-----------------------+-------------------------+-----------------+ >> | x.x.x.x Blade2 | y.y.y.y Blade3 | IMIX - aaafg | >> +-----------------------+-------------------------+-----------------+ >> >> I don't see the port in the examples. >> Maybe you meant Address/{Port|Blade} ? >> Or maybe you meant Address/{Port AND/OR Blade} ? > acm - Address + (Port AND/OR Blade) > > >> - Section 4. >> The custom IMIX can use the MTU size, by setting it up in the Genome. >> However, the MTU semantic is not conveyed. >> Is this intentional? I was thinking that Z would be the MTU, with the >> constraint that the tester MUST specify the MTU value in the report? > acm - the sentence that covers this now reads: > If z (MTU) is used, the tester MUST specify the length of the MTU > in the report. > > (so the MTU semantic remains in the table) > >> - Section 4. >> Isn't it an issue that only 26 discrete values are possible? > acm - even if a sequence of different sizes is too long to describe, > the packet sizes are usually chosen from bins in a histogram and > therefore some summarization of lengths. > > At the end of Section 5, we have provisions for pseudo-random > packet size generation, where the algorithm and seed need to be > specified. The size generation you mention below: > >> Don't we have test for which the packet size increases by 1 >> monotonically? > acm - could also be included, but we didn't have this suggestion previously > and it would seem fairly obvious how to report the method, as > you've done above. > > If a deterministic packet size generation method is used (such as > monotonic increase by one octet from start value to MTU), then the > generation algorithm SHOULD be reported. > > >> - Section 5 >> I guess that the sentence "When a sequence can be decomposed into a >> series of short repeating sequences, then a run-length encoding approach >> MAY be used as shown below:" can also apply to custom IMIX. The example >> doesn't show it. If this is the case, you should mention it. > acm - yes, added that point. > >> Editorial >> "Genome" versus "genome" throughout document >> > acm - ok > >> _______________________________________________ >> bmwg mailing list >> bmwg@ietf.org >> https://www.ietf.org/mailman/listinfo/bmwg
- [bmwg] Benoit Claise's No Objection on draft-ietf… Benoit Claise
- Re: [bmwg] Benoit Claise's No Objection on draft-… MORTON JR., ALFRED C (AL)
- Re: [bmwg] Benoit Claise's No Objection on draft-… Benoit Claise