[e2e] evolution of bandwidth as a term

Cannara cannara at attglobal.net
Fri Oct 3 10:40:39 PDT 2003


Well Ted, I was surely not wishing a tumor on you!  Simply trying to get an
example that clarified the importance of clear communication.  You can thank
whomever, or no one, when and if something bad happens to you that good
communication ameliorates.  

Your clarification, however, is internally inconsistent, which is what those
of us against misuse of terms are concerned with.  On one hand you say:  

"...there are
significant problem domains where the signal bandwidth of the underlying
transmission media is completely irrelevant.  Because the signal
bandwidth doesn't even come up, the chance of confusing a protocol
parameter and signal bandwidth is zero.  However, because many protocol
parameters are some kind of contiguous allocation or capacity, there are
obvious analogies that an informed person can make to signal bandwidth."

Which suggests that the meaning of "capacity" eludes you.  In protocol
intercommunication, there is some limiting capacity, in bits/bytes/whatever
per second, whether it's interprocess communication via memory or system or
storage busses, or simply processor speed.  You're right, this is clearly not
a "bandwidthable" term, so capacity in b/s is all you need use.  Why even try
to use "bandwidth" for capcity?  An "informed person" would not be so foolish
as to make such obviously wrong analogies.
 
You go on with:  "In those domains, maintaining the artificial linguistic
distinction impedes reinforcing the similarities between protocol resource
usage and signal bandwidth."  Yet, you said above that "signal bandwidth of
the underlying transmission media is completely irrelevant".  So, you've made
two irrelevancies into some sort of relevant analogy?  This leads nowhere but
to confusion, especially for new students who don't have a strong
signal-theory or electrical-engineering background.  

Furthermore, by saying: "...use 'bandwidth' for the protocol quantity" is
"just like using the word 'current' for the flow of holes in a circuit..." is
simply incorrect.  You should see that from the similarity of your own words
"flow" and "current"; and the irrelevance you claimed above for "bandwidth"
and "protocol capacity".  We should ignore Shannon et al, because Ted says
so?  :]

What you're suggesting demonstrates exactly why sloppy use of scientific terms
is damaging to communication and understanding.

Alex

One way to aid a protocol designer or network
manager's intuition about those similarities is to  aids the intuition for
electrical engineers or
physicists.

Ted Faber wrote:
> 
> On Thu, Oct 02, 2003 at 08:48:26PM -0700, Cannara wrote:
> > "Semantic drift", "metaphor"...  Sounds like the good old '70s and the
> > insurgence of PC thinking.  When your Dr. discovers a malignant tumor in your
> > belly, you'll thank more than God for practical medical science's adherence to
> > strict meanings of technical terms.
> 
> As an atheist, I won't even thank God.
> 
> The tone of that paragraph goes a long way toward establishing your
> calm, rational argumentation style, though.  Wishing a tumor on someone
> who disagrees with you is a nice opening rhetorical flourish.  I'm
> looking forward to your evidence that M.D.'s are more consistent in
> their terminology than conputer scientists and electical engineers.
> 
> On Thu, Oct 02, 2003 at 08:48:26PM -0700, Cannara wrote:
> > I'm certain ISI teaches networking better than to lead students to believe:
> > "For a fixed protocol and transmission system, the two are usually directly
> > related, and therefore straightforward to interchange."  We have "usually" in
> > the sentence, for what purpose?  Perhaps to cover the raw fact that unforeseen
> > symbol choices at the transmission level easily make it false?  Perhaps
> > because the bandwidths of the relevant inter-layer communication paths have
> > little to do with interlayer bitrates?  Perhaps the student is actually never
> > told what Nyquist and Shannon meant, or what Baudot did?  The sentence you
> > supply shows precisely the damage to scientific discussion that misuse of just
> > the term "bandwidth" can bring to a table of discourse.
> 
> The use of the terms "fixed" and "related" also narrow the focus of my
> example.  Of *course* there are cases where protocol throughput and
> signal bandwidth are related in complex ways.  In those problem domains
> using the two terms interchangably is stupid.
> 
> I was understating my case, so let me be more clear: there are
> significant problem domains where the signal bandwidth of the underlying
> transmission media is completely irrelevant.  Because the signal
> bandwidth doesn't even come up, the chance of confusing a protocol
> parameter and signal bandwidth is zero.  However, because many protocol
> parameters are some kind of contiguous allocation or capacity, there are
> obvious analogies that an informed person can make to signal bandwidth.
> In those domains, maintaining the artificial linguistic distinction
> impedes reinforcing the similarities between protocol resource usage and
> signal bandwidth.  One way to aid a protocol designer or network
> manager's intuition about those similarities is to use "bandwidth" for
> the protocol quantity, just like using the word "current" for the flow
> of holes in a circuit aids the intuition for electrical engineers or
> physicists.
> 
> I believe that intelligent, informed people may choose to use
> "bandwidth" in certain problem domains to describe other similar
> protocol attributes in order to reinforce those similarities while being
> in full possession of mastery of signal processing and information
> theory.
> 
> In short, sometimes one should ignore Shannon.
> 
> --
> Ted Faber




More information about the end2end-interest mailing list