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

[ih] why did CC happen at all?

The report mentions more than one kind of lockup.

At 09:57 AM 9/1/2014, John Day wrote:
>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 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.
>>>>>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:
>>>>>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 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
>>>>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: <http://www.walden-family.com/bbn/>http://www.walden-family.com/

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: