[ih] why did CC happen at all?
John Day
jeanjour at comcast.net
Mon Sep 1 06:57:53 PDT 2014
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/
>
More information about the Internet-history
mailing list