[ih] Why did congestion happen at all? Re: why did CC happen at all?

[Detlef Bosau]

Am 30.08.2014 um 21:31 schrieb Miles Fidelman:
> Umm... now this makes even less sense. What question are you asking,
> or what point are you toirying to make?


;-) (Isn't the correct simley. I'm not smiling here. I'm simply frustrated.)

For nearly three decades, we hand out doctoral hats and PhD diplomae for
a, may I be honest, if only this one time, nonsense called "congestion
control".

Now, this afternoon (and not only this afternoon, I deal with these
things for more than ten years now), I had a look at this page:

http://www.cs.utexas.edu/users/chris/think/ARPANET/Technical_Tour/hi_flow.shtml

Now to the point.

The one and only purpose of flow control is to have a sender send not
faster than a receiver can accept and process data.

Hence, flow control happens INEVITABLY hop to hop, otherwise it is
simply no flow control,

In TCP, we have a model

Sender ----------(miracle)-------------Receiver

and we use a "flow control" between receiver and sender, and all text
books I know spread the nonsense that the receiver in a TCP session has
to limit the sender via "flow control", and we assume a "miracle" as the
"link model".

Actually, and that's the point, IP is an overlay network - and what I
called (miracle) may be completely congested and neither the sender nor
the receiver is aware of this congestion.

Now, first: If we used the ARPAnet for layer 1 and 2 in the Internet,
this congestion would simply not occur, because the ARPAnet (sie link
above) offered the necessary means for flowwise (!) hop top hop flow
control.

Some day, and I don't now this exactly as I did not attend the meetings,
we wrote RFC 791 - and simply left out flow control on layer 1 and layer 2.

With the very foreseeable result that things would crash. IP nodes
communicated using a "cloud" with miraculous "lines", so that we could
use a model

Sender ------------- (miraculous line) --------- Receiver

and this (miraculous line) has a certain "capacity" (it becomes even
better: This "capacity" is even stationary....) which can be probed,
assessed, modelled
and we introduced "congestion control" as a means of throttling the
sender to the "rate" and "capacity" (both stationary of couse) of our
"(miraculous line)".

And now we complain about
- buffer bloat,
- too long round trip times,
- fairness problems,
- loss differentiation problems
- line underutilization (i.e. lines have to carry probing packets,
retransmissions, which use resources)
which I'm more and more convinced of, result in the one (IMHO wrong)
decision to omit flow control in IP and omit a reasonable scheduling and
allocation of resources, and now we are fully focused on fixing the
consequences of a botch made 30 years ago.

I'm curious about the actual equipment being used for "Internet
connections" used in context with the congavoid paper. And perhaps, I
will have to read the early papers on how the change from ARPAnet to
Internet was actually managed.

And my conjecture is that we made some inconsiderate decisions that
time, which avenged themselves during the last decades.

If I only could, I would give this design a roll back and give TCP a
redesign on an elaborated network (and network model) with propper
- flow-wise
- hop by hop
flow control.

I'm convinced, this wouldn't only spare us the aforementioned problems
but would be cheaper, faster and less resource consumptive than our
Internet today.

However, I feel a bit isolated here.

(And, as I said, as I think about this for many years now, deeply
frustrated.)

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