[ih] why did CC happen at all?

Mon Sep 1 05:30:19 PDT 2014

Wasn't at least one of the lock up problems that 
ARPANET Messages could be up to 8 packets, and 
the IMP would reassemble a full Message before 
delivering it to the host.  Hence, it was 
possible to get many partially reassembled 
messages in the destination IMP without enough 
memory to finish any of them.  Since the IMP 
wouldn't discard anything, it froze.

RFNMs made it pretty difficult to over load the 
IMPs with just packet traffic, right?

For what it's worth, many years ago Phil Enslow 
told me he had reviewed the proposed ARPANET 
design (before my time) and had said it would 
lock up, but no one believed him.  That is all I 
know about that.

At 12:17 PM +0200 9/1/14, Detlef Bosau wrote:
>Am 31.08.2014 um 08:24 schrieb Vint Cerf:
>
>>ARPANET used an overly constrained system 
>>called RFNM (request for next message). The 
>>mechanism was used to reserve space at the 
>>destination IMP ("get a block" "got a block").
>>
>
>That's what I referred to.
>
>>however it was possible to send multiple 
>>messages over different "links" (logical term) 
>>and overload the network that way. It was also 
>>possible to overload an intermediate IMP simply 
>>by sending traffic between pairs 
>>(source/destination) that happened to pass 
>>through the same intermediate IMP.
>>
>
>That's what I missed. And this point is important.
>
>>
>>The Internet protocols did not use these 
>>methods and except for the "congestion 
>>encountered" signal, all flow control was 
>>end/to/end which still raised the possibility 
>>of intermediate router congestion.
>>
>
>And that's my concern. The only compelling 
>reasons for this seem to me: a) A concern about 
>possible head of line blocking, b) a lack of 
>computing power at the nodes.
>
>As far as I see, both problems can be overcome.
>
>>
>>The TCP flow control was an attempt to adjust 
>>to signals from the receiver and signals 
>>(dropped packet, congestion encountered) from 
>>intermediate nodes. Packet loss was treated as 
>>a flow control signal leading to backoff of the 
>>retransmission mechanism of TCP. Slow start was 
>>a  crude way of sensing where the limits of 
>>capacity lay.
>>
>
>However, this approach treated the "line" 
>between sender and receiver, may I say it 
>extremely dense, as a "queueing system where 
>Little's law applies".
>(Which is a bit a contradiction in terms, 
>because EITHER Little's law applies to a system 
>EXCLUSIVE OR a system suffers from drops.)
>
>However, one could take this as an 
>approximation. (Which is sometimes better, 
>sometimes worse. As always in engineering. 
>Basically, the world is a perfect one  - 
>unfortunately, what we actually have is only an 
>approximation.)
>
>>
>>your claim that there is no congestion with 
>>"proper" implementation may result in lower 
>>resource utilization. Circuit switching 
>>dedicates capacity so there is no congestion, 
>>except for the failure to get a circuit ("all 
>>circuits busy" is a congestion signal). But 
>>dedicating capacity removes the implicit 
>>statistical multiplexing advantage of packet 
>>switching.
>>
>
>That's the very trade off. And I don't advocate 
>circuit switching as an alternative. The strong 
>shortcoming in circuit switching is the 
>"fragmentation loss" of resources: Resources are 
>assigned to users who don't really use them. 
>What I have in mind is basically a flow layer 
>with flow control (in a sense, Ford and Iyengar 
>had something similar in mind in 2009) and - to 
>exploit the flexibility of a packet switched 
>network - an on demand scheduling of resources.
>
>>
>>v
>>
>>
>>
>>On Sat, Aug 30, 2014 at 12:25 PM, Detlef Bosau 
>><<mailto:detlef.bosau at web.de>detlef.bosau at web.de> 
>>wrote:
>>
>>I'm yet to understand the sitch from the ARPAnet to the Internet in
>>1983, however, if this happened that way, that an Internet host sent a
>>message to its peer using the "message switching system" (may I call it
>>that way?) in the ARPAnet, CC would be an "impossible fact".
>>
>>(Some German readers might enjoy this little text here:
>><http://ingeb.org/Lieder/palmstre.html>http://ingeb.org/Lieder/palmstre.html)
>>
>>In the ARPAnet, congestion was avoided by flow control - and in fact,
>>actually, there is nothing like "congestion" when networks are
>>implemented correctly.
>>
>>To my understanding, "congestion" is an excuse for missing (or botched)
>>flow control.
>>
>>So, what was the scenario, VJ describes in the congavoid paper? Up to
>>know, I always thought, the ARPAnet infrastructure was still in use,
>>although adopted by the Internet protocol stack, but I thought, IP
>>datagrams were sent like ARPAnet messages?
>>
>>Detlef
>>
>>--
>>------------------------------------------------------------------
>>Detlef Bosau
>>Galileistraße 30
>>70565 Stuttgart 
>>Tel.:   <tel:%2B49%20711%205208031>+49 711 
>>5208031
>> 
>> mobile: <tel:%2B49%20172%206819937>+49 172 
>>6819937
>>                                            skype:     detlef.bosau
>>                                            ICQ:          566129673
>><mailto:detlef.bosau at web.de>detlef.bosau at web.de 
>> <http://www.detlef-bosau.de>http://www.detlef-bosau.de
>>
>>
>
>
>--
>------------------------------------------------------------------
>Detlef Bosau
>Galileistraße 30  
>70565 Stuttgart                            Tel.:   +49 711 5208031
>                                            mobile: +49 172 6819937
>                                            skype:     detlef.bosau
>                                            ICQ:          566129673
><mailto:detlef.bosau at web.de>detlef.bosau at web.de                     
><http://www.detlef-bosau.de>http://www.detlef-bosau.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20140901/93da7ccc/attachment.htm>