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

["David Newman" <[e-mail]>]

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

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.

>
>
> Forwarding Delay
>
> I requested that the reference to [Br99] be dropped because the paragraph
> 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
> [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.

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.

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

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




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

_______________________________________________
bmwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/bmwg