RE: [bmwg] WG Last Call: draft-ietf-bmwg-dsmterm-06.txt

[Tony DeLaRosa <[e-mail]>]

Just a few comments:

3.1.3 Forwarding Congestion

- Suggest changing "The overload discussion deals with how many input
interfaces are required to overload the output interfaces."  

  to 

  "[MA98] deals with overloading input and output interfaces beyond the
maximum transmission allowed by the medium."

- Suggest deleting the following:

          "[Ra99] states that it is impractical to build a
          black-box test to externally observe Incipient Congestion in
          a router.  For the purpose of "black-box" testing a DUT/SUT,
          Packet Loss as the indicator of Forwarding Congestion is
          used. "

  The reason is that this statement is taken out of context.  [RA99] states
"Treating the network as a "black-box" and treating loss as an indication of
congestion in the network is appropriate for pure best-effort data carried
by TCP which has little or no sensitivity to delay or loss of individual
packets."  I don't believe the author meant the inverse was true.

- Suggest adding the following sentence at the end of the 6th paragraph to
improve clarity

  "Forwarding Congestion is observed between Incipient Congestion and
Congestion Collapse."  

3.2.1 Channel Capacity

- Suggest changing the "Channel Capacity" term to "Flow Capacity" or "CoS
Capacity."  The definition as it stands today is practically identical to
the throughput definition.  Where is "channel" defined?  Channel is such a
vague term.  I can see cofusion when this term is discuss in context with
channelized interfaces.

- Question on the following paragraph

          "Understanding channel capacity is a necessary precursor to
          any measurement involving congestion.  Throughput numbers can
          be higher than channel capacity because of queueing."

  Does "measurement involving congestion" refer to forwarding congestion?
If so, please modify the text or clarify the meaning.

3.2.2 Conforming
- Suggest changing the "Conforming" term to "Conforming Packets."  This is
more consistent with Section 3.3 terminology definitions.

3.2.3 Nonconforming
- Suggest changing the "Nonconforming" term to "Nonconforming Packets."
This is more consistent with Section 3.3 terminology definitions.

3.2.4 Forwarding Delay
- Question on the definition.  Are the inputs and outputs cited in this
definition referring to the ports on the test device or the DUT/SUT?  In the
previous sections, ports on the DUT/SUT are referenced as ingress and egress
ports (or interfaces).

- Suggest changing the following sentence for improved clarity.  

          "Forwarding Delay is the same metric, measured the same way,
          regardless of the architecture of the DUT/SUT."

  To

          "Forwarding Delay is measured the same way
          regardless of the architecture of the DUT/SUT."

- Suggest changing the following:

          "4. Forwarding Delay can be measured at any offered load,
          whereas the latency methodology [Br99] recommends measurement
          at, and only at, the throughput level.  Comparing the
          Forwarding Delay below the throughput to Forwarding Delay
          above the channel capacity will give insight to the traffic
          control mechanisms."

  To

          "4. Forwarding Delay can be measured at any offered load.
Comparing the
          Forwarding Delay below the throughput to Forwarding Delay
          above the channel capacity will give insight to the traffic
          control mechanisms."

  There is no reason to compare to the latency methodology.  The differences
have already been discussed.

- Question:  What kind of congestion and delay does this example refer to?

          "For example, non-congested delay may be measured with an
          offered load that does not exceed the channel capacity, while
          congested delay may involve an offered load that exceeds
          channel capacity."

3.2.5 Jitter

- Question:  Jitter is currently defined for streams.  Should this
definition be extended to include flows.  If not, perhaps rename Jitter to
Stream Jitter to provide clarification.

3.2.6 Undifferentiated Response
- Comment:  This configuration term is currently defined as a vector;
however, the term 'vector' is not defined until section 3.4.  If this term
is truly a 'vector', it should be moved into section 3.4; if this term is
not a vector, then the definition should be rewritten without using the term
'vector'.

3.3 Sequence Tracking

- Suggest providing a discussion on the value of sequence tracking in the
context of measuring traffic control mechanisms prior to defining terms in
this section.  Also, Out of Sequence packet classifications have already
been defined in the following paper:
http://www.icir.org/vern/imw-2002/imw2002-papers/197.pdf.  In particular:

Out-of-Sequence Packets
    o Retransmissions
    o Unneeded Retransmissions
    o Network Duplicates
    o Reorderings
    o Unknown

3.3.1 Duplicate Packet
- Suggest indenting this to 3.3.2.1 as it is one particular instance of
out-of-Sequence packets.

3.3.2 Out-of-order Packet
- Suggest change "Out-of-order Packet" to "Out-of-Sequence Packet".  The
latter term is use much more pervasively in the technical community.

3.3.4 Stream 
- Suggest moving this section into 3.1 Configuration terms, after 3.1.5
Flow.  These are like terms.  Also note that stream is currently referenced
before it is defined. 

3.3.6 Test Sequence number

- Suggest moving this section before 3.3.1 In-Sequence Packet.  It is
referenced before it is defined.


-----Original Message-----
From: Al Morton [mailto:[e-mail]] 
Sent: Wednesday, May 07, 2003 7:48 PM
To: [e-mail]
Subject: [bmwg] WG Last Call: draft-ietf-bmwg-dsmterm-06.txt


BMWG:

A WG Last Call period for the Internet-Draft on

"Terminology for Benchmarking Network-layer Traffic Control Mechanisms"

<draft-ietf-bmwg-dsmterm-06.txt>

will be open from 07 May 2003 through 21 May 2003.

A WG Last Call was issued on version 05 of this draft,
ending on March 25.  Version 06 addresses comments from
the previous Last Call and the ensuing discussion.

Please weigh-in on whether or not you feel that this Internet-Draft should
be given to the Area Directors for consideration in progressing the Draft to
an Informational RFC.  Send your comments to this list or [e-mail].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-dsmterm-06.txt


_______________________________________________
bmwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/bmwg
_______________________________________________
bmwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/bmwg