Re: [bmwg] Fwd: New Version Notification for draft-cerveny-bmwg-ipv6-nd-02.txt

"MORTON, ALFRED C (AL)" <acmorton@att.com> Tue, 22 October 2013 17:15 UTC

Return-Path: <acmorton@att.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 538A511E82BF for <bmwg@ietfa.amsl.com>; Tue, 22 Oct 2013 10:15:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 mAICnVYbcYi3 for <bmwg@ietfa.amsl.com>; Tue, 22 Oct 2013 10:15:20 -0700 (PDT)
Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0F211E81BF for <bmwg@ietf.org>; Tue, 22 Oct 2013 10:15:17 -0700 (PDT)
Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id D4904120AE2; Tue, 22 Oct 2013 13:15:15 -0400 (EDT)
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by mail-azure.research.att.com (Postfix) with ESMTP id 25F63E02C5; Tue, 22 Oct 2013 13:15:16 -0400 (EDT)
Received: from njfpsrvexg9.research.att.com (unknown [135.207.255.240]) by mail-blue.research.att.com (Postfix) with ESMTP id 20200F019A; Tue, 22 Oct 2013 13:15:16 -0400 (EDT)
Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg9.research.att.com ([fe80::e596:b2e3:df5e:6b93%15]) with mapi; Tue, 22 Oct 2013 13:14:55 -0400
From: "MORTON, ALFRED C (AL)" <acmorton@att.com>
To: William Cerveny <bmwg@wjcerveny.com>, "bmwg@ietf.org" <bmwg@ietf.org>
Date: Tue, 22 Oct 2013 13:14:52 -0400
Thread-Topic: [bmwg] Fwd: New Version Notification for draft-cerveny-bmwg-ipv6-nd-02.txt
Thread-Index: Ac7ObHpGL+1YV7ITRCa8NobHYFGfuAA1eKEQ
Message-ID: <2845723087023D4CB5114223779FA9C8AB2EAC8E@njfpsrvexg8.research.att.com>
References: <20131017194613.32568.83136.idtracker@ietfa.amsl.com> <1382366730.22661.36608317.4A66F96D@webmail.messagingengine.com>
In-Reply-To: <1382366730.22661.36608317.4A66F96D@webmail.messagingengine.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [bmwg] Fwd: New Version Notification for draft-cerveny-bmwg-ipv6-nd-02.txt
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, 22 Oct 2013 17:15:27 -0000

Hi Bill,

I read the draft today, and want to share a few comments,
as a participant. I like the draft, and since I know there
are more comments coming, these will get us started.

Al

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Title: you could just drop "Problems"

I think you need a motivation section, beyond the reference to
the "Problems" RFC, before we get to the test setup.
What are we going to benchmark here?
something along the lines of recommended behavior in RFC6583?

Thanks for including the "Overview of NDP" section.
A nit is that the last two items (indented 3, 4)
are alternative results for 
sending the neighbor solicitation packet, and
could be further indented and re-numbered 1,2. 

sec 6.1, max number of valid hosts:

In the test procedure (for this and similar for other procedures),
the last step should end with:
"The number of hosts in the cache is the value of the
Max Valid Hosts benchmark for this configuration."
(or something like that, don't leave the benchmark in mystery)

sec 6.2, Stable state time:
It appears this procedure actually benchmarks the 
*return to stable state time* following overload.
overload may not be the best term, but I think we can 
improve on the text: 
"the intermediate node has gotten into a state where packets are dropped."

sec 6.3.1 NDP Prioritization:
new stream needed here, tester-unreachable stream.
maybe list all streams and other equipment capabilities up front
(more streams defined in section 6.5).
Also, step 5. "not always get responses/packets be received",
let's discuss clarifying this condition, so it's clear when achieved.





 



> -----Original Message-----
> From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On Behalf Of
> William Cerveny
> Sent: Monday, October 21, 2013 10:46 AM
> To: bmwg@ietf.org
> Subject: [bmwg] Fwd: New Version Notification for draft-cerveny-bmwg-ipv6-
> nd-02.txt
> 
> I've updated the "Benchmarking Neighbor Discovery Problems" draft.
> 
> Updates since v00 and v01
> 
> - Transition to writing from the perspective of testing via standalone
> Linux boxes to using specialized testers.
> - Added narrative describing more about how NDP works and the problems
> that are being benchmarked.
> - Removed tests/measurements that rely upon information obtained from
> DUT, such as CPU load, etc.
> - Lots of text changes since v00.
> 
> To-do:
> - New tests need to be understood better. In particular, specific value
> and procedure needs to be clarified.
> - I have left the concept of a “non-participating” network in the draft,
> which is a leftover from v00. I’ve left it in for now because I might
> have a use for it as I experiment more in testing. If it turns out I
> don’t need it, I’ll remove references to non-participating network/node
> in future revisions.
> - Looking back at my IETF-86 notes, Scott Bradner had issues with
> benchmarking “problems”, as this is currently a benchmarking
> instantiation of RFC 6583, “Operational Neighbor Discovery Problems”.  I
> haven’t changed this yet and need to determine what it should change to
> …
> 
> Bill Cerveny
> 
> ----- Original message -----
> From: internet-drafts@ietf.org
> To: William Cerveny <None@ietfa.amsl.com>, William Cerveny
> <bill@wjcerveny.com>, William Cerveny
> Subject: New Version Notification for draft-cerveny-bmwg-ipv6-nd-02.txt
> Date: Thu, 17 Oct 2013 12:46:13 -0700
> 
> 
> A new version of I-D, draft-cerveny-bmwg-ipv6-nd-02.txt
> has been successfully submitted by William Cerveny and posted to the
> IETF repository.
> 
> Filename:        draft-cerveny-bmwg-ipv6-nd
> Revision:        02
> Title:           Benchmarking Neighbor Discovery Problems
> Creation date:   2013-10-17
> Group:           Individual Submission
> Number of pages: 12
> URL:
> http://www.ietf.org/internet-drafts/draft-cerveny-bmwg-ipv6-nd-02.txt
> Status:
> http://datatracker.ietf.org/doc/draft-cerveny-bmwg-ipv6-nd
> Htmlized:
> http://tools.ietf.org/html/draft-cerveny-bmwg-ipv6-nd-02
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-cerveny-bmwg-ipv6-nd-02
> 
> Abstract:
>    This document is a benchmarking instantiation of RFC 6583:
>    "Operational Neighbor Discovery Problems" [RFC6583].  It describes a
>    general testing procedure and measurements that can be performed to
>    evaluate how the problems described in RFC 6583 may impact the
>    functionality or performance of intermediate nodes.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> bmwg mailing list
> bmwg@ietf.org
> https://www.ietf.org/mailman/listinfo/bmwg