<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [ih] why did CC happen at
all?</title></head><body>
<div>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.</div>
<div><br></div>
<div>RFNMs made it pretty difficult to over load the IMPs with just
packet traffic, right?</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div><br></div>
<div>At 12:17 PM +0200 9/1/14, Detlef Bosau wrote:</div>
<blockquote type="cite" cite>Am 31.08.2014 um 08:24 schrieb Vint
Cerf:<br>
<blockquote type="cite" cite>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").</blockquote>
<blockquote type="cite" cite><br></blockquote>
</blockquote>
<blockquote type="cite" cite><br>
That's what I referred to.<br>
<blockquote type="cite" cite>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.<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
That's what I missed. And this point is important.<br>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>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.<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
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.<br>
<br>
As far as I see, both problems can be overcome.<br>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>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.<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
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".<br>
(Which is a bit a contradiction in terms, because EITHER Little's law
applies to a system EXCLUSIVE OR a system suffers from drops.)<br>
<br>
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.)<br>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>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.<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
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.<br>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>v</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><br>
<br>
</blockquote>
<blockquote type="cite" cite>On Sat, Aug 30, 2014 at 12:25 PM, Detlef
Bosau <<a
href="mailto:detlef.bosau@web.de">detlef.bosau@web.de</a>>
wrote:<br>
<blockquote>I'm yet to understand the sitch from the ARPAnet to the
Internet in<br>
1983, however, if this happened that way, that an Internet host sent
a<br>
message to its peer using the "message switching system"
(may I call it<br>
that way?) in the ARPAnet, CC would be an "impossible
fact".<br>
<br>
(Some German readers might enjoy this little text here:</blockquote>
<blockquote><a
href="http://ingeb.org/Lieder/palmstre.html"
>http://ingeb.org/Lieder/palmstre.html</a>)<br>
<br>
In the ARPAnet, congestion was avoided by flow control - and in
fact,<br>
actually, there is nothing like "congestion" when networks
are<br>
implemented correctly.<br>
<br>
To my understanding, "congestion" is an excuse for missing
(or botched)<br>
flow control.<br>
<br>
So, what was the scenario, VJ describes in the congavoid paper? Up
to<br>
know, I always thought, the ARPAnet infrastructure was still in
use,<br>
although adopted by the Internet protocol stack, but I thought, IP<br>
datagrams were sent like ARPAnet messages?<br>
<br>
Detlef<br>
<br>
--<br>
------------------------------------------------------------------<br>
Detlef Bosau<br>
Galileistraße 30<br>
70565
Stuttgart <span
></span
> <span
></span> Tel.: <a
href="tel:%2B49%20711%205208031">+49 711 5208031</a><br>
<span
></span
> <span
></span
> <span
></span> mobile:
<a href="tel:%2B49%20172%206819937">+49 172 6819937</a><br>
<span
></span
> <span
></span
> <span
></span>
skype: detlef.bosau<br>
<span
></span
> <span
></span
> <span
></span>
ICQ:
566129673<br>
<a
href="mailto:detlef.bosau@web.de">detlef.bosau@web.de</a
> <span
></span> <a
href="http://www.detlef-bosau.de">http://www.detlef-bosau.de</a><br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br></blockquote>
</blockquote>
<blockquote type="cite" cite><br>
<br>
</blockquote>
<blockquote type="cite" cite><tt>--<br>
------------------------------------------------------------------<br>
Detlef Bosau<br>
Galileistraße 30 <br>
70565
Stuttgart <span
></span
> <span
></span> Tel.: +49 711
5208031<br>
<span
></span
> <span
></span
> <span
></span> mobile:
+49 172 6819937<br>
<span
></span
> <span
></span
> <span
></span>
skype: detlef.bosau<br>
<span
></span
> <span
></span
> <span
></span>
ICQ:
566129673<br>
</tt><a
href="mailto:detlef.bosau@web.de"><tt>detlef.bosau@web.de</tt></a><tt
> <span
></span> </tt> <a
href="http://www.detlef-bosau.de"><tt>http://www.detlef-bosau.de</tt></a
></blockquote>
<div><br></div>
</body>
</html>