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