[ih] why did CC happen at all?
Dave Walden
dave.walden.family at gmail.com
Mon Sep 1 07:05:43 PDT 2014
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.
>>>>>
>>>>>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
>>>>
>>>>
>>>>--
>>>>------------------------------------------------------------------
>>>>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:
<http://www.walden-family.com/bbn/>http://www.walden-family.com/
More information about the Internet-history
mailing list