Subject: Re: [bmwg] Benchmarking Neighbor Discovery Problems

From: "MORTON JR., ALFRED (AL)" <[email-masked]>
Date: Tue, 5 Mar 2013 12:18:00 -0500

Hi Bill,

First, Congrats on successfully formatting your first memo using XML2RFC.
We can work together now to help others in BMWG who want to go this route.

I reviewed your draft and have a few minor comments.
(temporary links to the draft are below)

Al
(as participant)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> William Cerveny
> Sent: Tuesday, February 19, 2013 5:23 PM
> To: [email-masked]
> Subject: [bmwg] Benchmarking Neighbor Discovery Problems
> 
...
> 
> http://21st-century-networks.org/draft-cerveny-bmwg-ipv6-nd.txt
> http://21st-century-networks.org/draft-cerveny-bmwg-ipv6-nd.html
> http://21st-century-networks.org/draft-cerveny-bmwg-ipv6-nd.pdf
> 

Editorial:
2.  Terminology

   Neighbor Discovery  SeeRFC 4861 [RFC4861]
suggest 
   Neighbor Discovery  See Section 1 of RFC 4861 [RFC4861]
and then the HTML-ized version will take you exactly where one
can read a description of ND.

-=-=-=-=-=-
3.  Test Set-up

3.1.  Device Under Test (DUT)

   For purposes of this document, the intermediate node will be referred
   to as the device under test (DUT).  The DUT may be any intermediate
   node which retains a neighbor cache.  The tests in this document
   could also be completed with any intermediate node which maintains a
   list of addresses that traverse the intermediate node, although not
   all measurements and performance characteristics may apply.
Comment:
After reading the paragraph above, I expected to find "intermediate node"
defined in one of the key references, like 4861 or 6583, but I didn't.
Is this term defined in the ND context somewhere?

If not, I suggest defining the role of the node as you've described it above,
but as part of section 2.

Also, suggest to label the intermediate node in the Test Set-up figure.

-=-=-=-=-

4.1.  Frequency of NDP triggering events

   The frequency of NDP triggering events could be as high as the
   maximum packet per second rate that the ingress network will support

do you mean
s/ingress/scanner/  ?

more in 4.1

   Optimistically, the scanning rate should be incremented until the
   intermediate node's performance begins deteriorating.  Depending on

suggest:
   Optimistically, the scanning rate should be incremented until the
   (forwarding?) performance of the DUT begins deteriorating.  Depending on

-=-=-=-=-

more in 4.1, 3rd para

   The lowest frequency is the lowest rate for which packets could be
   expected to have an impact on the DUT -- this value is of course,
   subjective.

I think I can figure-out what you're trying to say, if this is a benchmark,
but then I tried to fix the sentence myself, and couldn't quite do it.

-=-=-=-=-=-
4.7.  Testing of Mitigating Options

   It may be desirable to perform some tests in the presence of
   mitigating techniques described in RFC 6583 [RFC6583]
Comment: add the short list of suggested mitigations.

-=-=-=-=-=-
4.8.  Attack where node in target network responds to all neighbor
      solicitations

   [Open Question: Is this an interesting condition, where a device on
   the network responds affirmatively to all incoming NDP requests??
   Are there any non-malicious cases where this could happen?]

I'm inclined to say yes, to prompt the discussion. If not included,
we need to say why.

-=-=-=-=-=-
6.1.  Round-trip time across DUT

   This consists of pinging the target network measurement node from a
   non-participating measurement node and recording reported round-trip
   time.  This measurement should be conducted with an address not yet
   present in the DUT's neighbor cache.  This measurement is included
   because it is perhaps the easiest to conduct and capture.

so, the first ping experiences the time for discovery,
but subsequent pings do not? (the first is not discarded, right?)
the performance report should separate first ping from the rest, if so.

In any case, the max waiting time for each ping echo-reply to arrive
could become important in a stressful scenario, and should be specified
and reported.

-=-=-=-=-=-
6.2.  Rate DUT adds a valid node in the target network to its neighbor
      cache

   There are three distinct time elements associated with this
   measurement:

   1.  The difference in time for which the DUT receives the packet
       which must be forwarded to a node in the target network not yet
       listed in the neighbor cache and the time the DUT sends a
       neighbor solicitation.
...
   3.  The difference in time from which the DUT receives the packet to
       the time for which the DUT adds the neighbor in its neighbor
       cache.
In 3., which packet is referred to?  The same packet in 1.?

There may be a data-plane test possible to infer cache installation,
but needs more thought/experience.

In general, it's easier to record time stamps of significant events
observed in a procedure, and compute the time intervals later
(see my ISSU draft comments).

-=-=-=-=-=-
6.4.  DUT CPU utilization

   Measured in percent utilization, captured via a non-intrusive query
   of the DUT.

Comment: this utilization measurement could be an aid to testing,
but we can't always trust the DUT to measure a benchmark.
Utilization measurement methods could vary from vendor to vendor.

-=-=-=-=-=-
6.5.  Rate DUT forwards packets

Comment: this is our bread and butter, flesh it out.

-=-=-=-=-=-
6.6.  Rate DUT responds to neighbor solicitations for its own address

Comment: the test described is a time difference, not a rate (?).

-=-=-=-=-=-
Other sections need to be fleshed-out.
We have standard text for the Security Section in BMWG.

-=-=-=-=-=-

---

From: William Cerveny <[email-masked]>
Date: Wed, 06 Mar 2013 15:39:15 -0500

Hi Al,

Thank you for the excellent review. Comments inline ...

> We can work together now to help others in BMWG who want to go this

I definitely know XML2RFC better than I did before and am "almost" ready
to say this is one of the easier ways of writing a draft in a conforming
format.  The learning curve is a bit steep, but then it's all downhill
:-)

[snip]

> can read a description of ND.

OK, I'll play with that, not ready to say yet that's easy to do :-)

OK

>    maximum packet per second rate that the ingress network will support

Yes, I started using terms ingress and egress until I decided that
didn't make any sense and I missed changing that instance.

>    (forwarding?) performance of the DUT begins deteriorating.  Depending

I'm not sure if "forwarding" is the right word here but I'll clarify
"performance".

> but then I tried to fix the sentence myself, and couldn't quite do it.

:-) I looked at the sentence a while too and couldn't figure out a
better way of saying it. But I concur it needs to be fixed.

OK.

OK

Good point, I'll clarify

> could become important in a stressful scenario, and should be specified

Concur

OK

Concur

OK

Oh yeah, thanks

Concur; when I wrote the draft, the location of the security section
test wasn't obvious, and didn't know where to look (where should I have
looked?)

---

From: "MORTON JR., ALFRED (AL)" <[email-masked]>
Date: Wed, 6 Mar 2013 20:22:42 -0500

> From: William Cerveny [mailto:[email-masked]]
> Sent: Wednesday, March 06, 2013 3:39 PM
> To: MORTON JR., ALFRED (AL); [email-masked]
> Subject: Re: [bmwg] Benchmarking Neighbor Discovery Problems
> 
...
> test wasn't obvious, and didn't know where to look (where should I have

Quite a few RFCs in the last 4 years or so use the "standard" text.
Also, it's always one of the chair's WG status slides, just as
a reminder since there's almost always new drafts in the works.

Al