IMIX Genome: Specification of Variable Packet Sizes for Additional Testing
draft-ietf-bmwg-imix-genome-05

No objection to the publication of this document.
However, I have some remarks/questions. 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

- 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.


-
OLD:

   The chosen configuration would be expressed the following general
   form:

NEW:
   The chosen configuration would be expressed in the following general
   form:

- 
   +-----------------------+-------------------------+-----------------+
   | 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} ?

- 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?

- Section 4.
Isn't it an issue that only 26 discrete values are possible?
Don't we have test for which the packet size increases by 1 monotonically?

- 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.

Editorial
"Genome" versus "genome" throughout document

In 1 Introduction:

The term IMIX is defined, but Genome isn't. I know what a Genome is, but having an explicit definition would be helpful.

section 1: s/this draft/this document/g

section 2: I don't see why the sequence length has to
be "not very long" - what's wrong with longer
sequences?

section 4: As a reader who'd never heard of this
before, I found this unclear but got it after a 2nd
reading. I'd suggest adding "This section describes
how to document an IMIX with custom packet sizes, e.g.
representing a 1020 byte packet size as ggg"
somewhere.

section 5: The run length encoding is also unclear.
Do you mean "IMIX - 20abcd40bcd" or something?

A question out of curiosity - did the authors consider using a pseudo-random sequence to generate indexes to their packet length table?

That would allow the genome for a long sequence to be compacted to polynomial, starting value and length.

I don't object to what's documented here, although like Stewart, I was expecting this to involve some kind of pseudorandom sequence.