IMIX Genome: Specification of Variable Packet Sizes for Additional Testing
RFC 6985
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
(Joel Jaeggli; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
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
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Richard Barnes; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
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.
(Stephen Farrell; former steering group member) No Objection
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?
(Stewart Bryant; former steering group member) No Objection
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.
(Ted Lemon; former steering group member) No Objection
I don't object to what's documented here, although like Stewart, I was expecting this to involve some kind of pseudorandom sequence.