[ih] FC vs CC Re: [e2e] Fwd: Re: Once again buffer bloat and CC. Re: A Cute Story. Or: How to talk completely at cross purposes. Re: When was Go Back N adopted by TCP

[Detlef Bosau]

Am 23.08.2014 um 05:34 schrieb Jack Haverty:
> Not just taxis...
>
> 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.

Although these things are useful if applied correctly, they must not be
applied to things where they don't apply.

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.


Which, and please take hammer, gouge and a plate of marble and gouge it, is
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!
(This ist not a claim by me - read Little's preconditions and
assumptions, they simply do not apply to packet switched networks. Period.)

(I apologize for shouting.)

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.

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.
>
> My recollection is that terms such as "flow control" and "congestion
> control" were used in mathematics, well before they were used in
> computer networks.  
>

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.

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.

=> Please go back to a basic lecture on stochastic processes,
introductory remarks, first two weeks.

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

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.

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.

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

So the new born Dr.-Ing. forgets all about those Kalman Filters,
Luenberger Observers and Ljapunov Equations - and starts engineering.



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

Do you have precise definitions? Particularly for flow control.
Congestion is easy. "A queueing system is congested when at least one
queue is transient."
But what is flow control all about here?

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

And that was not always useful. In many of these scenarios, mathematical
models have been thoughtlessly applied to where they don't apply.
>
> 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.
>

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.
When I take a taxi, I want to reach my destination ASAP. (And I have
only limited compassion for the taxi drivers budget.)
(Extremely spoken. Economically, you will find me at the side of Keynes,
not at the side of Hayek.)

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.

And actually, we don't keep the lines busy, we often keep the queues
overcrowded.

This might be a certain shift of paradigm, because in the 70s, lines
were extremely expensive. Hence the intention was to fully utilize them.
To my knowledge, our actual Tier 1 backbone is - in contrast to the
situation back in the 70s -  rather a bit overprovisioned.


> The whole field of Operations Research is about that kind of math used
> in engineering, business, etc., long before computers did.

Yes. And meanwhile they do it with appropriate care...

(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.)
>
> Of course computers made it possible to actually do the calculations
> fast, and that changed the way the math got used.
>
> /Jack Haverty
>


Please don't mix up mathematics with computing ;-) *SCNR*

-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30   
70565 Stuttgart                            Tel.:   +49 711 5208031
                                           mobile: +49 172 6819937
                                           skype:     detlef.bosau
                                           ICQ:          566129673
detlef.bosau at web.de                     http://www.detlef-bosau.de

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20140823/b322ea04/attachment.htm>