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

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

The term "channel capacity" was introduced on this list in early 2000 by
John Dawson. It has been used since in most bmwg discussions of
*bandwidth* capacity. This is a different concept than throughput.

"Flow capacity" and "QOS capacity" have problems of their own. For
example, "flow capacity" could refer to the number of concurrent sessions
a device can handle. That may also be a valid metric, but it's a different
one than channel (bandwidth) capacity.

Similarly, "QOS capacity" could refer to number of queues or number of
DSCP markings a box can apply or other aspects of QOS unrelated to
bandwidth. Also, a historical note: This document started life with 
much more liberal use of the term "QOS" but Geoff Huston, Randy Bush, 
and many others objected to the term because it's too vague.

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

We very much do need a comparison with the historical use of latency.

We need to distinguish whether we are:

1. below the tput level;
2. at the tput level; or 
3. above the tput level

Since 2544 covers only (2) above, we need to distinguish what is different 
with this new metric.

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

Don't necessarily disagree, but there are multiple definitions of 
"sequence" and it's not clear which one you mean.

dn

_______________________________________________
bmwg mailing list
bmwg@ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg