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