Switch draft Q&A

[Kevin Dubray <[e-mail]>]

Hi Scott and all,

I have given your remarks a lot of consideration as I think you will see from 
the amendments I have made to the document. I have commented on your comments 
and annotated them in the reply message below. Each of my comments starts with 
'<Bob replies . . .'  and ends with '>'. In general I think that you will find 
that your comments have led me to say things more simply and, I hope, more 
clearly. In a rush of optimism I have taken out the time to 'freeze' the 
document by formatting it as per the Guideline RFC.

Thanks for the comments and have a good read.
Bob



[from Scott]
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.

<
Bob replies:
Agreed. I have reworked the discussion and included what I think is an essential 
reference to addressing information.

Discussion:
A single stand-alone or modular unit which receives frames on or more 
of its interfaces and then forwards them to one or more interfaces 
according to the addressing information contained in the frame.
>

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

<Bob replies: to deal with your concerns (which I share) I have first cast the 
definition of unidirectional traffic in different terms to underline that this 
defintion has to do with traffic orientation. It now reads:

3.2.1 Unidirectional traffic Definition:When all frames presented to the input 
interfaces of a DUT/SUT are addressed to output interfaces which do not 
themselves receive any frames.

I have also put the following paragraph to clarify the discussion section:

When a tester offers unidirectional traffic to a DUT/SUT reception and 
transmission are handled by different interfaces or sets of interfaces of the 
DUT/SUT. All frames received from the tester by the DUT/SUT are transmitted back 
to the tester from interfaces which do not themselves receive any frames.

As for Partially meshed traffic (3.3.2) I have modified the definition to better 
reflect that we are talking about traffic distribution:

3.3.2 Partially meshed traffic

Definition:
Frames offered to one or more input interfaces of a DUT/SUT and addressed to one 
or more output interfaces where input and output interfaces are 
mutually exclusive and mapped one-to-many, many-to-one or many-to-many.

I have also modified the discussion on partially meshed traffic to show how it 
ties in with the terms unidirectional and bidirectional traffic. It now reads:

When partially meshed traffic is distributed in a one-to-many or many-to-one 
mapping of receiving to transmitting interfaces of a DUT/SUT traffic orientation 
will be unidirectional. When traffic is partially meshed and distributed in a 
many-to-many mapping of receiving to transmitting ports which are mutually 
exclusive traffic orientation will be bidirectional.
>
-----------------
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. 

<Bob replies: Agreed: wording got to be somewhat abstruce as attempts were made 
to "tune" this discussion. Your paragraph reads much better so I have pasted it 
in as is. In addition I have added the new paragraph just above: "When a tester 
. . .".
>
--
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 

<Bob replies: agreed and done
See Also:
bidirectional traffic (3.2.2)
one-to-one mapped traffic (3.3.1)
partially meshed traffic (3.3.2)
fully meshed traffic (3.3.3)
congestion control (3.7)
head of line blocking (3.7.3)
>

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

<Bob replies: agreed and done with your suggested wording:

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

I have also the following sentence to the discussion section to parallel the 
addition to the unidirectional discussion:

When a tester offers bidirectional traffic to a DUT/SUT all the interfaces which 
receive frames from the tester also transmit frames back to the tester.

>

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

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

<Bob replies: thanks for pointing this out. I have put the reference in as per 
RFC 2119 in the Existing Definitions section (2) right after the Introduction 
(1) and just before the Term Definitions (3).
>

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

<Bob replies - I have already had two "off-line" requests making the same point 
so I have expanded the discussion as follows: [by the by: I have received a 
large number of comments on the draft at various stages but their authors seem 
consistently to shy away from posting them on the list despite Kevin Dubray's  
repeated and vigorous call for people to communicate their comments via the 
appropriate channel. Unfortunately this habit does not allow the list to reflect 
the considerable amount of commenting that goes on as a draft such as this one 
gets elaborated.]

It should be noted that bidirectional multi-port traffic can load 
backbone connections linking together two switching devices more 
than fully meshed traffic. In a bidirectional multiport test each one of two 
devices or systems connected over a backbone connection can be configured to 
forward the totality of the frames they receive to the devices or systems placed 
on the opposite side of the backbone connection. All frames generated during 
such a test will traverse the backbone connection. Fully meshed traffic requires 
at least some of the frames received on the interfaces of each one of the 
devices or systems under test to be forwarded locally, that is to the interfaces 
of the receiving devices themselves. Such frames will not traverse the backbone 
connection.
>
----------------------
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

<Bob replies:
Agreed. Here is what I have added:

The analysis of forwarding rate measurements presents a challenge when offering 
bidirectional or fully meshed traffic since the rate at which the tester can be 
observed to transmit frames to the DUT/SUT may be smaller than the rate at which 
it intends to transmit due to collisions on half duplex media or the action of 
congestion control mechanisms. This makes it important to take account of both 
the intended and offered loads defined in sections 3.5.1.and 3.5.2 below when 
reporting the results of such forwarding rate measurements.

The See Also now reads:
See Also:
unidirectional traffic (3.2.1)
bidirectional traffic (3.2.2)
one-to-one mapped traffic (3.3.1)
partially meshed traffic (3.3.2)
burst (3.4.1)
intended load (3.5.1)  [ADDED]
offered load (3.5.2)   [ADDED]
>

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

<Bob replies: fine point. I have made the adjustment. The text now reads:

Burst size can range from one to infinity. In unidirectional traffic as well as 
in bidirectional or meshed traffic 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.

<Bob replies: point well taken. Done. Text now reads:
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 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"

<Bob replies: yes, done. Text now reads:

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

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

<Bob replies: done.
See Also:
burst (3.4.1) [ADDED]
inter-burst gap (3.4.3) [ADDED]
offered load (3.5.2)
>


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

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

<Bob replies:
Agreed. This need be pointed out here. I have added bidirectional,fully meshed 
traffic and forwarding rate to the See Also section where the same point is 
raised. Here is the wording I've put into 3.5.2.:

The load which an external device can be observed to apply to a DUT/SUT may be 
less than the intended load due to collisions on half duplex media or the action 
of congestion control mechanisms. This makes it important to distinguish 
intended and offered load when analyzing the results of forwarding rate 
measurements using bidirectional or fully meshed traffic.
>

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

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

<Bob replies:
Picking up on your lead this is what I have added:

An external source can also overload an interface by transmitting 
frames below the minimum inter-frame gap. A DUT/SUT MUST forward such frames at 
intervals equal to or above the minimum gap specified in standards.

A DUT/SUT using congestion control techniques such as backpressure or forward 
pressure may exhibit no frame loss when a tester attempts to overload one or 
more of its interfaces. This should not be exploited to suggest that the DUT/SUT 
supports rates of transmission in excess of the maximum rate allowed by the 
medium since both techniques reduce the rate at which the tester offers frames 
to prevent overloading. Backpressure achieves this purpose by jamming the 
transmission interfaces of the tester and forward pressure by hindering the 
tester from gaining fair acces to the medium. Analysis of both cases should take 
the distinction between intended load (3.5.1) and offered load (3.5.2) into 
account.

I have also made the appropriate additions to the See Also:
See Also:


See Also:

unidirectional traffic (3.2.1)
intended load (3.5.1) [ADDED]
offered load (3.5.2) [ADDED]
forwarding rate (3.6.1) [ADDED]
backpressure (3.7.1) [ADDED]
forward pressure (3.7.2) [ADDED]

>

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

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

<Bob replies: I have added two paragraphs, one in the backpressure, the other in 
the forward pressure section to point out the pitfalls encountered when trying 
to make sense of performance results on devices using one and the other 
congestion control techniques.

I've added the following to the backpressure section( 3.7.1):

A DUT/SUT applying backpressure may exhibit no frame loss when a tester attempts 
to overload one or more of its interfaces. This should not be interpreted to 
suggest that the interfaces of the DUT/SUT support forwarding rates above the 
maximum rate allowed by the medium. In such cases overloading is only apparent 
since through the application of backpressure the DUT/SUT attenuates the offered 
load by jamming one or more of the interfaces of the tester. 

And added tothe See Also:
See Also:
intended load (3.5.1) [ADDED]
offered load (3.5.2) [ADDED]
overloading (3.5.4) [ADDED]
forwarding rate (3.6.1) [ADDED]
forward pressure (3.7.2)

I have also added the following to the forward pressure section (3.7.2)

A DUT/SUT applying forward pressure may eliminate all or most frame loss when a 
tester attempts to overload one or more of its interfaces. This should not be 
interpreted to suggest that the interfaces of the DUT/SUT can sustain forwarding 
rates above the maximum rate allowed by the medium. Overloading in such cases is 
only apparent since the application of forward pressure by the DUT/SUT enables 
interfaces to relieve saturated output queues by forcing access to the medium 
and concomitantly inhibiting the tester from transmitting frames.

I have added to the See Also accordingly:

See Also:
See also:
intended load (3.5.1) [ADDED]
offered load (3.5.2) [ADDED]
overloading (3.5.4) [ADDED]
forwarding rate (3.6.1) [ADDED]
backpressure (3.7.1)
>
---------------------
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

<Bob replies: yes, I had that in there at one point but took it out for no good 
reason. So back in it goes. Actually it is in the discussion already.

Definition:
Frame loss or added delay 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.
>

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

<Bob replies: done with "destined to" added:
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 of frames directed to the 
broadcast MAC address.
>

what about multicast?

<Bob replies: I don't want to constrain Kevin Dubray in his work on multicasts 
by offering a preemptive definition. Multicasts are complex entities and deserve 
a document of their own.>

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

The document points out that switching devices may violate the IEEE 802.3 
standard by transmitting frames below the minimum interframe gap or unfairly 
accessing the medium by inhibiting the backoff algorithm. Although such 
violations do not directly engender breaches in security, they may perturb the 
normal functioning other interworking devices by obstructing their access to the 
medium.

<Bob replies: done with your wording plus an additional paragraph on standards 
violations. - thanks for the tip.

Documents of this type do not directly effect the security of the Internet
or of corporate networks as long as benchmarking is not performed on devices or 
systems connected to operating networks.

The document points out that switching devices may violate the IEEE 802.3 
standard by transmitting frames below the minimum interframe gap or unfairly 
accessing the medium by inhibiting the backoff algorithm. Although such 
violations do not directly engender breaches in security, they may perturb the 
normal functioning of other interworking devices by obstructing their access to 
the medium. Their use on the Internet or on corporate networks should be 
discouraged.
>

Scott


<Bob replies: Thanks for the broad range of your comments Scott, they cover 
formal points, some very fine points and some minor wording issues, all of 
which had to be addressed. Hope to see this work go forward now and to catch up 
with you in Munich.>

Bob