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

["Perser, Jerry" <[e-mail]>]

Tony,

Here a few responses to you comments.  Some I could not respond to.  I will
get the person(s) who contributed that section to respond:

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

The rewording sound more in tune with [Ma98].  I'll ask the particular
author of this paragraph if there is any thing you and I overlooked.

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

We had many (many) discussions on this point.  We removed this reference
based on: A.) is can not be externally observed, B.) It can not be proven.
We believe this happens most of the time.  But could not come to the
mathematically conclusion that this is ALWAYS the case.

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

I missed one.  Fixed.
 
> 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).

The definition states "port of the DUT/SUT".  I am not sure what you mean by
'test device' and how you confused it with the DUT/SUT.  The I-D does not
use the term 'test device' anywhere.

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

Forwarding.  Would it be clearer if it said forwarding congestion and
forwarding delay?  The expression 'congested delay' would turn into
'forwarding delay while under the state of forwarding congestion'.  A lot
longer and harder to read (IMHO).  If there is a consensus to make it
longer, then I will make the change.
 
> 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.

The math involved in Jitter can only be applied to microflows or streams.
You could use statistics to combine the mircoflows' (or streams') jitter
into a flow jitter, or even DUT/SUT jitter.  But then you would have to
appended the statistically method suffix to jitter.
 
> 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

Good paper, I have read it.  Spirent has had their own definition of Out of
Sequence packet since 1998.  Do you have any objections to using the IETF's
definition versus Spirent's or ICIR's?
 
> 3.3.1 Duplicate Packet
> - Suggest indenting this to 3.3.2.1 as it is one particular 
> instance of
> out-of-Sequence packets.

Separate and independent metric from 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.

The two terms have very different meanings with different results. I
recommend applying the two definitions to different test sequences to see
why they are not the same.  Try the sequence 1 2 4 5.  Packet 3 was lost,
not reordered.  There is a good discussion on this at
http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-02.txt
 
Jerry.

___________________________________________________________ 
Jerry Perser                         Spirent Communications
Director of Test Methodology         SmartBits Division 
Phone: [phone]                  26750 Agoura Road 
Lab:   818.676.2337                  Calabasas, CA, 91302 
Cell:  818.292.6457                  Corp:  818.676.2300

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