headers
Kevin Dubray | 3 Sep 2002 16:46
Favicon

bmwg-mcastm-08.txt: DUT priming

CC'ing group, who might have something to say about the
topic.

Debby Stopp wrote:

 >> Kevin wrote:

>>Hmmm. Simply, this is what I'm proposing:
>>
>>In section 3.1, add a new subsection, 3.1.6, "DUT/SUT Priming".
>>Such a section might say something like:
>>
>>An actual flow of test traffic may be required to prime related 
>>mechanisms, (e.g., process RPF events, build device caches, etc.) to 
>>optimally forward subsequent traffic.  Therefore, before an initial, 
>>measured forwarding test trial, the test apparatus MUST generate test 
>>traffic utilizing the same addressing characteristics to the DUT/SUT 
>>that will subsequently be used to measure the DUT/SUT response.
>>The test monitor should ensure the correct forwarding of traffic by
>>the DUT/SUT. The priming action need only be repeated to keep the 
>>associated information current.
>>
> 
> 
> Ok, that seems reasonable, one last comment, however.  If you say "may be
> required to prime related mechanisms", then why would we say "test apparatus
> MUST generate test traffic"?  Seems like if you have a DUT that doesn't
> require priming, the test doesn't need to send 'priming' traffic.

I can't make an assumption about every tested device or test topology.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Perser, Jerry | 3 Sep 2002 23:46

Congestion Definition in dsmterm03

Kevin,

Below is new definition (and discussion) for congestion.

The plan is to put it in the 04 version along with a change to "delay
variation."  I am current changing "delay variation" to "jitter" because way
we are using the term complies with the use of "jitter" in RFC1889 and
RFC2598 more that "delay variation" in draft-ietf-ippm-ipdv-10.txt (which
IESG has approved as a Proposed Standard).

3.1.3 Congestion

   Definition:
A condition in which one or more egress interfaces are offered more packets
than are forwarded.

   Discussion:
This condition is a superset of the overload definition [2]. The overload
definition assumes the congestion is introduced strictly by the tester on
ingress of a DUT/SUT. That may or may not be the case here.

Another difference between congestion and overload occurs when the SUT
comprises multiple elements, in that congestion may occur at multiple
points. Consider an SUT comprising multiple edge devices exchanging traffic
with a single core device. Depending on traffic patterns, the edge devices
may induce congestion on multiple egress interfaces on the core device. In
contrast, overload [1] deals only with overload on ingress.

Throughput [1] defines the lower boundary of congestion.  Throughput is the
maximum offered rate with no congestion.  At offered rates above throughput,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kevin Dubray | 5 Sep 2002 21:03
Favicon

Re: bmwg-mcastm-08.txt: DUT priming

So, if an organization is testing 2 different DUTs,  how can
you be assured that the same behavior is subjected to both
boxes?  I recommend tying down this one variable for the
non-burdened metrics. (Especially, since we have other metrics to 
ascertain overhead...)

Other folks have thoughts on the use of MUST vs. SHOULD here?

-Kevin

Debby Stopp wrote:

>> kevin wrote:
>> 
>>I can't make an assumption about every tested device or test topology.
>>But defining a universal procedural step, we increase the probability
>>of a normalized collection. (In practice, most folks send a short
>>burst of packets, if nothing else, to ensure they've cabled
>>or configured correctly!)  For DUT/SUT or scenarios where this
>>"priming" isn't needed, no harm.  For non-forwarding burdened metrics,
>>sections 4 and 5, you're still collecting a forwarding response
>>WITHOUT consideration  of overhead processing.  For forwarding
>>burden metrics (section 8), DUT priming might not be desirable.
>>(A note saying such should be added to the above text. (E.g.,
>>Priming is a requirement for section 4 and 5 metrics; priming is
>>not a requirement for section 8 (forwarding burdened) metrics. )
>>
> 
> I'm not disagreeing that priming is a good idea; I'm just suggesting that
> it's not always necessary each vendor may like to choose whether they prime
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Newman | 5 Sep 2002 22:39

RE: Re: bmwg-mcastm-08.txt: DUT priming


> Other folks have thoughts on the use of MUST vs. SHOULD here?

As Kevin noted there is no harm in learning, even if it's not required by
certain DUT/SUTs. There is considerable harm in skipping this step for
DUT/SUTs that require it.

There is also the matter of consistency with earlier methodologies. Learning
is a MUST in RFC 2889, section 5. A MUST also would be consistent with RFC
2544, Section 23(b).

dn
Permalink | Reply | 0 comments |
headers
Kevin Dubray | 24 Sep 2002 22:34
Favicon

Re: Congestion Definition in dsmterm03


On 9/3/2002, Jerry Perser wrote:

 > Kevin,
 >
 > Below is new definition (and discussion) for congestion.
 >

It would appear the delta from the previous version of the
definition is that you remove the temporal component - "at any
given instant."

Also, from the new version of the discussion, you introduce a
relationship between throughput and congestion.

Here's my issue with the current tack this is taking:

     1. Congestion is a _widely_ used term, especially in networking.
        You seem to be putting an extremely fine point on it -
        cite a specialized (egress port) context but choose to utilize
        a generalized handle for the term being defined.

     2. Your discussion alludes to throughput and rates, yet the
        definition refers more to a quantity than rate.  In a
        1997 Nanog presentation, Steve Polit suggested network device
        congestion is: "...when packets arrive faster than can be
        forwarded".  While you allude to throughput in the
        discussion, the notion of arrival rates is missing in
        the definition.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Poretsky | 24 Sep 2002 23:12

Re: Congestion Definition in dsmterm03

Kevin,

I think you are 100% correct.

Scott

At 04:34 PM 9/24/02 -0400, Kevin Dubray wrote:

>On 9/3/2002, Jerry Perser wrote:
>
> > Kevin,
> >
> > Below is new definition (and discussion) for congestion.
> >
>
>It would appear the delta from the previous version of the
>definition is that you remove the temporal component - "at any
>given instant."
>
>Also, from the new version of the discussion, you introduce a
>relationship between throughput and congestion.
>
>Here's my issue with the current tack this is taking:
>
>     1. Congestion is a _widely_ used term, especially in networking.
>        You seem to be putting an extremely fine point on it -
>        cite a specialized (egress port) context but choose to utilize
>        a generalized handle for the term being defined.
>
>     2. Your discussion alludes to throughput and rates, yet the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hickman, Brooks | 25 Sep 2002 17:32

draft-ietf-bmwg-firewall-06.txt Delta

Below is a list of the deltas between revision 5 and revision 6 of the
draft-ietf-bmwg-firewall. Please review and provide any feedback. Thank you.

1) Added Section 4.10

   4.10 TCP Stack Considerations

   Some test instruments allow configuration of one or more TCP stack
   parameters, thereby influencing the traffic flows which will be
   offered and impacting performance measurements. While this document
   does not attempt to specify which TCP parameters should be
   configurable, any such TCP parameter(s) MUST be noted in the test
   report. In addition, when comparing multiple DUT/SUTs, the same TCP
   parameters MUST be used.

2) Added following to test parameters to Sections 5.4.2, 5.6.2.1, 5.8.2.1

   Close Method - Defines method for closing TCP connections. The test
   MUST be performed with either a three-way or four-way handshake. In
   a four-way handshake, each side sends separate FIN and ACK messages.
   In a three-way handshake, one side sends a combined FIN/ACK message
   upon receipt of a FIN.

   Close Direction - Defines whether closing of connections are to be
   initiated from the client or from the server.

3) Edited section 5.1.3

   WAS:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Dubray | 25 Sep 2002 22:49
Favicon

bmwg-mcastm-08.txt: *capsulation methodologies

Kevin Dubray wrote:

  > Lastly, when RFC 2432 was put out, DVMRP was the driver for
  > the encapsulation related metrics. It appears that folks
  > employ other tunneling mechanisms (e.g., GRE, MPLS) to carry
  > their multicast through the unicast world. Do folks agree
  > that the level of detail stated in sections 4.4.1 - 4.4.3 is
  > adequate?

OK.  Let's see if I can crisp up my concerns.  They center around:
1) traffic rates, 2) test topology, and 3) reporting specifications
for the encapsulation, decapsulation, and re-encapsulation throughput
methodologies.

First, in the throughput methodologies, there's generally
symmetry regarding packet size as to what's offered to the DUT
and what's measured from the DUT. For example, 64 byte packets in,
64 byte packets out.

If one is measuring, say, the encapsulation throughput of GRE wrapped
multicast packets, an encapsulated output packet is 24 bytes larger
(presuming, of course, same transport medium). So, while you can count 
packets in-to-out to determine loss for some collection window, the 
outbound link maybe oversubscribed wrt to Oload at the higher end of
the medium's capacity.  This consideration should be reflected in
the metric's procedure.

IMO, the methodology leans too much on RFC 2544 for its specification. 
Shouldn't *capsulation throughput methodologies be aligned more with
multicast-oriented throughput methodologies?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Dubray | 26 Sep 2002 20:16
Favicon

WG Last Call: draft-ietf-bmwg-firewall-06.txt

BMWG'ers:

A WG Last Call period for the Internet-Draft on
     "Benchmarking Methodology for Firewall Performance,"

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

will be open from 26 September 2002 until 04 October 2002.

This I-D version reflects changes from its previous Last Call.

If you feel that this draft should not be given to the Area Directors
for consideration in progressing the I-D to an Informational RFC,
please cite your basis to this list or kdubray <at> juniper.net.  This must
be done prior to close of the last call period. Of course, notes of
support are always welcome.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-bmwg-firewall-06.txt
Permalink | Reply | 0 comments |

Gmane