draft-ietf-bmwg-lanswitch-05.txt

[Scott Bradner <[e-mail]>]

Hi Bob & all

I'm (belatedly) taking a look at draft-ietf-bmwg-lanswitch-05.txt and
have some comments

---------------
3.1.1 Device under test (DUT)  

Discussion:
A single stand-alone or modular unit generally equipped with its own
power supply.

--

I don't think the reference to a power supply is needed
I'd say something like:

A single stand-alone or modular unit which forwards frames of data
from one or more interfaces to one or more interfaces.

--------------
3.2.1 Unidirectional traffic 

Definition:
Frames presented to a DUT/SUT such that the receiving and transmitting
interfaces are mutually exclusive.

3.3.2 Partially meshed traffic

Definition:
Frames forwarded between mutually exclusive sets of input and output
interfaces of a DUT/SUT.

--

I'm a bit confused by this pair of definitions - they do not seem to
say something different - I'm not quite sure how to change somthing
to fix the definitions  - in general the 3.2 section and the 3.3 
sections seem to overlap and need to have some reworking

and the discussions do not clarify things for me - I suggest that 
the Partially meshed traffic def & discussion should be worked on
to clarify things

-----------------
3.2.1 Unidirectional traffic 

Discussion:

I think the discussion could be clarified to some degree - I took
a cut at part of it

  It is useful to distinguish traffic orientation and traffic distribution
  when considering traffic patterns used in device testing.  Unidirectional
  traffic, for example, is traffic orientated in a single direction
  between mutually exclusive sets of source and destination interfaces
  of a DUT/SUT. Such traffic, however, can be distributed between
  interfaces in different ways. When traffic is sent to two or more
  interfaces from an external source and then forwarded by the DUT/SUT to
  a single output interface the traffic orientation is unidirectional and
  the traffic distribution between interfaces is many-to-one. Traffic can
  also be sent to a single input interface and forwarded by the DUT/SUT
  to two or more output interfaces to achieve a one-to-many distribution
  of traffic.

--
Such traffic distributions can also be combined to test for head of
line blocking or to measure forwarding rates and throughput when
congestion control is active.
--

the See Also section should include 3.7.3 Head of line blocking 
and 3.7 Congestion control 

------------------
3.2.2 Bidirectional traffic

Definition:
Frames presented to a DUT/SUT such that the interfaces of the DUT/SUT both
receive and transmit. 

--

I'd change just a bit

Frames presented to a DUT/SUT such that each of the interfaces of the
DUT/SUT both receive and transmit.

-------------------

3.2.2 Bidirectional traffic 

Discussion:
This definition conforms to the discussions in sections 14 and 16 of
RFC 1944 on bidirectional traffic and multi-port testing. Bidirectional
traffic MUST be offered when measuring throughput on full duplex
interfaces of a switching device. 

--

all RFCs wich use the terms like "MUST" "MAY" etc should now contain
a reference to RFC 2119 - the exact form of the reference is in the RFC

--------------------
3.3.3 Fully meshed traffic

It should be noted that bidirectional multi-port traffic can load
backbone connections linking together two switching devices more
than meshed traffic.

--

it would be nice to expand on this a bit

----------------------
3.3.3 Fully meshed traffic

Bidirectional meshed traffic on half duplex interfaces is inherently
bursty since interfaces must interrupt transmission whenever they
receive frames. This kind of bursty meshed traffic is characteristic
of real network traffic and can be advantageously used to diagnose a
DUT/SUT by exercising many of its component parts simultaneously.
Additional inspection may be warranted to correlate the frame
forwarding capacity of a DUT/SUT when offered meshed traffic and
the behavior of individual elements such as input or output buffers,
buffer allocation mechanisms, aggregate switching capacity, processing
speed or medium access control. 

--

it might be good to add that analysis of the results of such tests
can present a chalenge since you need to take into account the
actual rate at which data was presented to the DUT/SUT rather than
just the rate that the tester attempted to send. (i.e. the offered
vs intended load) - the see also should point to them

-----------------------
3.4.2 Burst size

Discussion:
Burst size can range from one to infinity. In unidirectional traffic
there is no theoretical limit to burst length.

--

I'd tweak this a bit

Burst size can range from one to infinity. In unidirectional traffic
and in bidirectional or meshed bursts on full duplex interfaces
there is no theoretical limit to burst length.


-----------------------
3.4.3 Inter-burst gap (IBG) 

Bidirectional and meshed traffic are inherently bursty since interfaces
share their time between receiving and transmitting frames. External
sources offering bursty traffic for a given frame size and burst size
must adjust the inter-burst gap to achieve a specified rate of
transmission.  

--

I'd tewak this a bit

External sources offering bursty traffic for a given frame size and burst
size must adjust the inter-burst gap to achieve a specified average
rate of frame transmission.

-----------------------
3.5.1 Intended load (Iload) 

In the case of Ethernet an external source of traffic must implement
the truncated binary exponential back-off algorithm to ensure that it
is accessing the medium legally. 

--

I'd change the "must" to "MUST"

the See Also should include references to the burst & interburst gap
sections


------------------------
3.5.2 Offered load (Oload)

I'd also note that analysis of testing where offered ~= intended
must that the difference into account

-----------------------
3.5.4 Overloading

I'd add that information obtained through this type of test can
present opportunities for abuse by marketeers

-----------------------
3.7 Congestion control 

I'd also note the dificulity of understanding performance results
in devices that include congestion control 

---------------------
3.7.3 Head of line blocking 

Definition:
Frame loss observed on an uncongested output interface whenever frames
are received from an input interface which is also attempting to
forward frames to a congested output interface.

--

not just loss, also added delay

---------------------
3.10.1 Broadcast forwarding rate
Definition:
The number of broadcast frames per second that a DUT/SUT can be
observed to deliver to all interfaces located within a broadcast domain
in response to a specified offered load.

--

I'd tweak

The number of broadcast frames per second that a DUT/SUT can be
observed to deliver to all interfaces located within a broadcast domain
in response to a specified offered load of frames to the broadcast
MAC address.

what about multicast?

-----------------------
4. Security Considerations
	This document raises no security issues. 

--

the iesg will no longer OK RFCs that have this type of Security
Considerations section - 

it need to say things like

Documents of this type do not directly effect the security of the Internet
or of corporate networks as long as testers implementing tests of this
type are not connected to operating networks.


Scott