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

[Miles Fidelman]

Detlef Bosau wrote:

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

Right off the bat, you seem to be conflating two very different problems:
- Flow control is about limiting the rate at which traffic is received.
- Congestion control is about bottlenecks in intermediate resources 
BETWEEN the sender and receiver.

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

First off, ARPANET was a single network, providing a reliable message 
service, and an end-to-end flow control mechanism.  It was NOT a catenet 
comprised of networks with varying types of service.

Second, while the original BBN 1822 protocol was primarily connection 
oriented - which allowed for management of resources from end-to-end; 
1822L, and later releases of the IMP software supported a datagram service.

Third, ARPANET had it's own congestion issues, particularly when 
datagram service started to be emphasized - nodes and links congested, 
packets got dropped.

Fourth, congestion really became an issue when we moved into the 
Internet era - with ARPANET being the main "choke point."  When you have 
1mbps ethernets at the edges, linked by a network built with 64kbps 
links - you get congestion.  That remains the issue today - edges are 
faster than the center; with the exception of the mobile world, where 
the edges are the chokepoints.

ARPANET-style flow control is not an answer for congestion control 
across a catenet.

Different problems, requiring different solutions.
>
> 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.

As Paul Vixie pointed out,

"It was not simply left out. The omission of flow control and 
retransmission at L2 was deliberate, and reflects IP's need to run on 
links that by their nature cannot support transmission state. Had the 
RFC 791 authors been willing to limit themselves to a known set of link 
layer protocols we would not today have any Internet at all."

<snip>

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

Seems kind of useless, unless it's part of either:

a. A connection-oriented service (a la telephony) - with end-to-end call 
setup and resource reservation.  Leads to rather complex (and expensive) 
switching gear; and pretty much useless for bursty traffic.  Perhaps one 
of the reasons that telcos are migrating to datagram fabrics.

b. a store-and-forward network, where packets are re-transmitted 
hop-by-hop - which is what we're seeing emerge in the realm of 
delay/disruption-tolerant networks
> 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.

You and all those who argued for connection-oriented networks, back in 
the day (can you say X.25?).  Experience suggests that you're wrong.

Miles Fidelman





-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra