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

From: Tony DeLaRosa <[email-masked]>
Date: Thu, 22 May 2003 15:10:21 -0700

Channel Capacity

I just don't have a clear definition on what is a channel and how it relates
to QoS.  I can imagine the questions a customer may have when told that the
channel capacity on their channelized interface is XYZ.  I recommend that a
more meaningful term be used to describe channel capacity.  Here are some
other terms to consider:  CoS Forwarding Rate, code-point capacity, queue
capacity, or code-point forwarding rate. 

Forwarding Delay

I requested that the reference to [Br99] be dropped because the paragraph
infers that latency is measured only at throughput.  In reality, latency
[Br91] is defined free of any context to device load.  Please see BMWG
discussion
http://www1.ietf.org/mail-archive/working-groups/bmwg/current/msg00517.html.

Out of Order Packet

I see what you mean.  Out-of-Order packets and Duplicate packets are subsets
of Out-of-Sequence packets.  I recommend that 3.3.2 be renamed
"Out-of-Sequence Packets" and a brief introduction given on the three type
of conditions that results in Out-of-Sequence packets.  That paper can state
that Retransmission packets will not being considered since stateful packets
will not be transmitted by the traffic generator.  The paragraph should cite
the paper "Measurement and Classification of Out-of-Sequence Packets in a
Tier-1 IP Backbone".  Then section 3.3.1 is defined to be Out-of-Order
Packets and sectioin 3.3.2 is defined to be Duplicate Packets.  

-----Original Message-----
From: David Newman [mailto:[email-masked]] 
Sent: Wednesday, May 21, 2003 2:52 PM
To: Tony DeLaRosa
Cc: [email-masked]'
Subject: 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: "David Newman" <[email-masked]>
Date: Mon, 26 May 2003 22:23:59 -0700

> I just don't have a clear definition on what is a channel

The Egyptians carved out and measured canals at least 5000 years ago. The
term's history in networking is only slightly newer:

Leonard Kleinrock. Information Flow in Large Communications Nets. MIT
doctoral thesis proposal, July 1961.
http://www.lk.cs.ucla.edu/LK/Bib/REPORT/PhD/part1.pdf

Robert M. Metcalfe and David R. Boggs. Ethernet: Distributed Packet
Switching for Local Computer Networks. Communications of the ACM,
19(5):395--404, July 1976.
http://www.acm.org/classics/apr96/

David R. Boggs, Jeffrey C. Mogul, and Christopher A. Kent. Measured Capacity
of an Ethernet: Myths and Reality. Digital Western Research Lab Report 88/4,
September 1988.
ftp://gatekeeper.research.compaq.com/pub/DEC/WRL/research-reports/WRL-TR-88.
4.pdf

I gave John Dawson's February 2000 example only because AFAIK it was the
first reference to channel capacity within the bmwg. Obviously the concept
of channel capacity -- *in the way in which we use it* -- has been around
quite a bit longer than that.

and how
> it relates

No, no, no, and no, because a channel may carry multiple traffic classes.
All these terms cover a single class or codepoint, and thus none are
appropriate here.

> infers that latency is measured only at throughput.

Not infers. That's exactly what it says in RFC 2544 [Br99], section 26.2.

In reality, latency

Yes, and Jim McQuaid is the coauthor of 2544 (as he said at the time, Scott
did 80 percent of the work and he did the other 50 percent). I see nothing
in Jim's message contradicting, as you suggest here, the language of 2544
specifying that we measure latency at the throughput level. On the contrary.

Whether we like it or not (and I personally do not), 2544's
latency-at-throughput measurement is current industry practice. This
reference is necessary if for no other reason than to explain how dsterm
delay differs from the current (and IMO too limited) practice of measuring
latency only at the throughput level.

I take measurements all the time at iloads other than the throughput level,
but I refer to these measurements as delay so as not to conflict with the
methodology given in 2544.

> Packets and sectioin 3.3.2 is defined to be Duplicate Packets.

Retransmissions are out of scope. This ID is solely concerned with
diff-serv, a layer-3 mechanism.

Same problem with the paper by Jaisal et al; we're not concerned with TCP
here, and they were.

dn