[bmwg] Comments on draft-vpolak-mkonstan-bmwg-mlrsearch-02

"MORTON, ALFRED C (AL)" <acm@research.att.com> Mon, 15 July 2019 12:50 UTC

From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: "bmwg@ietf.org" <bmwg@ietf.org>
Thread-Topic: Comments on draft-vpolak-mkonstan-bmwg-mlrsearch-02
Thread-Index: AdU7BZcv3hlDbgvyQHmdymYl814Aig==
Date: Mon, 15 Jul 2019 12:49:18 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CFA0ACDDC7@njmtexg4.research.att.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/2YlN8IjjB7nfXQckAmKW9dnXsNU>
Subject: [bmwg] Comments on draft-vpolak-mkonstan-bmwg-mlrsearch-02
Precedence: list

Hi Maciek, Vratko, and BMWG,

Here are some comments on the latest version:
https://tools.ietf.org/html/draft-vpolak-mkonstan-bmwg-mlrsearch-02

Section 3 is as far as I could go today,
Al
(as a participant)

Section 1 jumps into terms and definitions, 
relying that the reader will read the abstract first.
It's OK, and typical, that text from the Abstract
becomes part of the Introduction (and Motivation).
I would also expect to hear about FD.io CSIT in
this introduction - these are compelling experiences
in the CI/CD category of testing for NFV.

Section 1 defines many terms, but we should be re-using
as much terminology as we can, from:
https://tools.ietf.org/html/rfc1242
and 
https://datatracker.ietf.org/doc/rfc2285/
(and RFC 2544 and 2889, where some definitions were expanded).

For example, in 1242:
https://tools.ietf.org/html/rfc1242#section-3.5
3.5  Data link frame size

        Definition:
                The number of octets in the frame from the first octet
                following the preamble to the end of the FCS, if
                present, or to the last octet of the data if there
                is no FCS.
overlaps with your :
      Frame size: size of an Ethernet Layer-2 frame on the wire,
      including any VLAN tags (dot1q, dot1ad) and Ethernet FCS, but
      excluding Ethernet preamble and inter-frame gap.  Measured in
      bytes.

The template used in 1242 and 2285 is also helpful
during reviews. Several of the sentences you wrote would
go in the "Discussion" section of the template.

I think we'll find that you've defined many new terms that
are useful, but let's concentrate on those after removing 
the overlapping terms.

Section 2
In this background section, I think it would be appropriate
to mention the ETSI GS NFVTST009, since one of its key 
contributions is on search algorithms.

Section 3

   *  Search:

         +  Start with a large (lower_bound, upper_bound) interval
            width, that determines measurement resolution.
The "interval width" is not_equal to step size, right?
The (lower_bound, upper_bound) define the interval width, AFAICT.

It seems that you need to specify the number of rows in a table
of search values, and then the "measurement resolution" in terms of
the acceptable range of offered loads will be clear (or some similar
conclusion reached through deciding the step size first, which 
determines the number of rows in the search space table).

This terminology is important to nail down, especially when 
you include the geometric search parameter variability.

[bmwg] Comments on draft-vpolak-mkonstan-bmwg-mlr… MORTON, ALFRED C (AL)