[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ih] why did CC happen at all?

At 9:19 AM -0400 9/1/14, Dave Walden wrote:
>i think, john, that you are talking about 
>"reassembly lockup" per vint's message and the 
>kahn-crowther report i referenced. it's 
>described in that report, in a subsequent 
>published paper by them, perhaps in our 1972 imp 
>improvements paper, and perhaps in an NMC paper 
>where Len put some more theory and data around 
>our mistaken idea.

Yea, that was the one!  ;-)  But I assume that 
what Vint is talking about is other ways of 
creating lock ups, right?

>At 08:30 AM 9/1/2014, John Day wrote:
>>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 
>>>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 
>>>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.
>>>>On Sat, Aug 30, 2014 at 12:25 PM, Detlef 
>>>><<mailto:detlef.bosau at web.de>detlef.bosau at web.de> 
>>>>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:
>>>>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 Bosau
>>>>Galileistra?e 30
>>>>70565 Stuttgart 
>>>>Tel.: <tel:%2B49%20711%205208031>+49 711 
>>>>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
>>>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
>home address: 12 Linden Rd., E. Sandwich, MA 02537
>home ph=508-888-7655; cell ph = 503-757-3137 (often don't carry it)
>email address:  dave at walden-family.com; website: