<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Am 23.08.2014 um 05:34 schrieb Jack
Haverty:<br>
</div>
<blockquote cite="mid:53F80BC6.4080707@3kitty.org" type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=utf-8">
<div class="moz-cite-prefix">Not just taxis...<br>
<br>
It's been a looonnggg time, but I still remember studying a lot
of mathematics about 50 years ago - queueing theory, graph
theory, etc. Used to be able to do it too.<br>
</div>
</blockquote>
<br>
Although these things are useful if applied correctly, they must not
be applied to things where they don't apply.<br>
<br>
To be more drastically (and perhaps enter some killfiles): To my
understanding, the common denominator in buffer bloat, problems in
VJCC, problems with isarithmic networks is Little's theorem.<br>
<br>
<br>
Which, and please take hammer, gouge and a plate of marble and gouge
it, is <br>
L I T T L E `S T H E O R E M , W H I C H D O E S N O T A P P L
Y T O C O M P U T E R N E T W O R K S!<br>
(This ist not a claim by me - read Little's preconditions and
assumptions, they simply do not apply to packet switched networks.
Period.)<br>
<br>
(I apologize for shouting.)<br>
<br>
Neither does the whole queueing theory as often employed by people,
who made great contributions to networking, but when Len Kleinrock
and Raj Jain talk about queueing systems, they talk about
mathematical models which well provide insight in how systems work -
unfortunaley, and that's really a pity, hardly anyone of them
applies to computer networks. <br>
<br>
So a good networker should be able to deal with models in order to
understand how systems work - while he is basically an engineer
which must keep his feet in solid coupling to the ground.<br>
<blockquote cite="mid:53F80BC6.4080707@3kitty.org" type="cite">
<div class="moz-cite-prefix"> <br>
My recollection is that terms such as "flow control" and
"congestion control" were used in mathematics, well before they
were used in computer networks. <br>
<br>
</div>
</blockquote>
<br>
Where? All our queueing models deal with loss free systems. We don't
even have a notion of stability here - although years ago I was
asked whether we could prove the Internet to be "stable". The pure
question is simply ludicrous and makes obvious that the questioner
has absolutely no idea what he is talking about.<br>
<br>
In a scientifc (!) paper I think to have read a notion (my memory
may cheat me here) a queueing system were stable if the queues
cannot grow beyond all limits.<br>
<br>
=> Please go back to a basic lecture on stochastic processes,
introductory remarks, first two weeks.<br>
<br>
When I enqueue at the cash point in my local supermarket, the queue
sometimes grows beyond all limits. (Which is relative. In some
cases, there are 3 customers, each one with 1 item, and the queue is
beyond all limits, the collector close to a heart attach and the
customers close to insanity, in other cases, there are 50 customers,
each with 150 times, and the queueing delay is not observable.)<br>
<br>
To my understanding, a queue may well grow beyond all limits, and
this is perfectly acceptable, if there is a probality > 0,
definitely != 0, that the queue will ever return to a finite length
or even the queue may run empty. <br>
<br>
But these are abstractions. With infinite queues, stationary
processes, Poisson processes, Markov Processes. A (translated word
by word) a glass bead game, perhaps the term "Glasperlenspiel" is
known even to the Englisch speaking world.<br>
<br>
In control theory, professors award PhD students their hat with the
words: "Congratulations to your hat, but now, it's time to forget
anything what you've learned here and to go outside - and deal with
reality."<br>
<br>
So the new born Dr.-Ing. forgets all about those Kalman Filters,
Luenberger Observers and Ljapunov Equations - and starts
engineering.<br>
<br>
<br>
<br>
<blockquote cite="mid:53F80BC6.4080707@3kitty.org" type="cite">
<div class="moz-cite-prefix"> I suspect the answer to "when were
the terms "flow control" and "congestion control" coined will be
found in the history of mathematics - not computers. Such terms
have been in use a long time. They were coined long before
computers.<br>
</div>
</blockquote>
<br>
Do you have precise definitions? Particularly for flow control.
Congestion is easy. "A queueing system is congested when at least
one queue is transient."<br>
But what is flow control all about here?<br>
<br>
<blockquote cite="mid:53F80BC6.4080707@3kitty.org" type="cite">
<div class="moz-cite-prefix"> <br>
Computer and later network people just used the terms to
describe the behavior of flows of bits, just as earlier
engineers and scientists used them to describe the flow of
people, railroad cars, components in manufacturing lines,
warehouse inventory, etc.<br>
</div>
</blockquote>
<br>
And that was not always useful. In many of these scenarios,
mathematical models have been thoughtlessly applied to where they
don't apply. <br>
<blockquote cite="mid:53F80BC6.4080707@3kitty.org" type="cite">
<div class="moz-cite-prefix"> <br>
For example, the problem of where to put railroad tracks, and
where to put railroad yards (and how big) to provide "buffers"
for flows of goods is fundamentally the same as where to put
packet switches, memory, circuits, etc., in computer networks.<br>
<br>
</div>
</blockquote>
<br>
And it is - sorry for being harsh here - sometimes the same
nonsense. I already said this some posts ago. To my understanding
the main reason for adopting a sliding window scheme in
telecommunication is to avoid idle times. (Or deadheading.) Just
another example for a wrongly applied model.<br>
When I take a taxi, I want to reach my destination ASAP. (And I have
only limited compassion for the taxi drivers budget.) <br>
(Extremely spoken. Economically, you will find me at the side of
Keynes, not at the side of Hayek.)<br>
<br>
Back to networks: Networks shall convey data as soon as possible -
and they shall serve the user. Not the other way round. More
precisely: It is simply mot the user's job to keep the lines busy.<br>
<br>
And actually, we don't keep the lines busy, we often keep the queues
overcrowded. <br>
<br>
This might be a certain shift of paradigm, because in the 70s, lines
were extremely expensive. Hence the intention was to fully utilize
them. <br>
To my knowledge, our actual Tier 1 backbone is - in contrast to the
situation back in the 70s - rather a bit overprovisioned.<br>
<br>
<br>
<blockquote cite="mid:53F80BC6.4080707@3kitty.org" type="cite">
<div class="moz-cite-prefix"> The whole field of Operations
Research is about that kind of math used in engineering,
business, etc., long before computers did.<br>
</div>
</blockquote>
<br>
Yes. And meanwhile they do it with appropriate care...<br>
<br>
(Engineers are not mathematicians. There are very few people who can
successfully act in both roles. Many people tend to be extreme in
one direction.)<br>
<blockquote cite="mid:53F80BC6.4080707@3kitty.org" type="cite">
<div class="moz-cite-prefix"> <br>
Of course computers made it possible to actually do the
calculations fast, and that changed the way the math got used.<br>
<br>
/Jack Haverty<br>
<br>
</div>
</blockquote>
<br>
<br>
Please don't mix up mathematics with computing ;-) *SCNR*<br>
<pre class="moz-signature" cols="72">--
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30
70565 Stuttgart Tel.: +49 711 5208031
mobile: +49 172 6819937
skype: detlef.bosau
ICQ: 566129673
<a class="moz-txt-link-abbreviated" href="mailto:detlef.bosau@web.de">detlef.bosau@web.de</a> <a class="moz-txt-link-freetext" href="http://www.detlef-bosau.de">http://www.detlef-bosau.de</a>
</pre>
</body>
</html>