[ih] Flow Control in IP

Tue Apr 30 13:40:04 PDT 2024

dedicated connections per BBN 1822 specifications - not counting Distant
Host and Very Distant Host which were pt-pti but more elaborate than direct
bit by bit signaling.
v

On Tue, Apr 30, 2024 at 4:20 PM Detlef Bosau via Internet-history <
internet-history at elists.isoc.org> wrote:

> Steve,
>
>
> first of all, let me thank you for these comments. I don't have any
> first hand experience with the ARPAnet   and it is somewhat arduous to
> find the details. Moreover, it is always helpful to get the ideas behind
> the standards etc. by getting in touch with the guys who build the ARPAnet.
>
> One question for my understanding. How were the IMP and Hosts
> interconnected? Did you use P t P connections? And where these
> synchronous lines as we are used to from WAN? Or "asynchronous" networks
> like, e.g., Ethernet? (Hopefully I will survive the answers. I've seen
> flamewars dealing with the question whether Ethernet is synchronous or
> not....)
>
> I just want to understand your way of thinking in that time.
>
>
> Detlef
>
> On 30.04.24 17:27, Steve Crocker wrote:
> > Detlef,
> >
> > In the Arpanet, the initial implementation of the IMPs had a flow
> > control mechanism that attempted to protect the IMP subnet from being
> > overloaded with too many packets.  This was implemented via an
> > end-to-end protocol between the sending IMP and the receiving IMP that
> > allowed only one message per link.
> >
> > At the host level, the original host-host protocol -- later referred
> > to as the Network Control Protocol (NCP) -- implemented virtual
> > bitstreams. It had a flow control mechanism that gave the receiving
> > host control over how many bits and messages -- yes, both bits and
> > messages were controlled -- could be in flight over each connection.
> >
> > For those who do not remember or who have not studied the details of
> > the Arpanet:
> >
> >     The IMPs were the routers.  A host was connected to an IMP.  The
> >     unit of transmission between a host and an IMP was a "message" of
> >     up to about 8,000 bits.  The IMP receiving (Source IMP) the
> >     message from the sending host (Source host) chopped it into
> >     packets.  Each packet was up to about 1,000 bits.  The Destination
> >     IMP reassembled the packets into a message and transmitted it to
> >     the Destination host.
> >
> >     From a protocol perspective, there were multiple layers:
> >
> >      1. The IMP-IMP protocol governed the transmission of a packet
> >         from one IMP to the next.  It included strong error detection
> >         and retransmission if the packet was not acknowledged as
> >         having been received correctly.
> >
> >      2. The End-to-End IMP protocol (my terminology) governed the
> >         breakdown of a message received from a host into packets and
> >         the reassembly of those packets into a message at the
> >         destination IMP.  The End-to-End IMP protocol imposed a limit
> >         of one message in transit per link.
> >
> >      3. The Host-IMP protocol governed the interaction between a host
> >         and its connected IMP, as noted above. Each message included a
> >         link number.  It was intended that processes within two
> >         communicating hosts would use the same link number for
> >         successive messages. Thus, the End-to-End IMP protocol limited
> >         the flow between two host level processes.  This scheme did
> >         not limit the overall number of connections, nor did it
> >         prevent two processes from using multiple connections if they
> >         chose to.  (And, as we experienced, it was indeed possible to
> >         flood the IMPs with enough packets to cause a system-wide
> lockup.)
> >
> >      4. The host-host protocol, as noted above, implemented virtual
> >         bitstreams between processes.  It included metering of both
> >         the number of bits and the number of messages in transit
> >         between the processes.  The receiving host controlled these
> >         quantities to avoid being overrun.
> >
> > As you can see, there was more than one layer of flow control in the
> > original Arpanet.  At the same time, there was strong interest in
> > real-time use of the Arpanet for applications where timeliness was
> > paramount and loss of a small percentage of packets was tolerable,
> > e.g. speech.  Relatively early in the Arpanet development, an
> > additional protocol was added to the IMPs in parallel with the
> > End-to-End IMP protocol that did not impose flow control but also did
> > not guarantee delivery.  Layers 2, 3 and 4 above were thus accompanied
> > by parallel layers 2r, 3r and 4r (my terminology invented for the
> > purpose of this explanation).
> >
> > By the time IP was being designed, it was fully understood that it
> > would not be possible to achieve perfect reliability within the
> > packet-routing layer of the Internet.  Flow control as well as
> > checksums and retransmission were included in the TCP layer.
> > Explicit flow control within the packet-routing layer was dropped, but
> > achieved implicitly with feedback in the routing protocol via info
> > about queue lengths and dropping of packets when memory was exceeded.
> >
> > In the early days, memory was quite limited.  Over time, Moore's law
> > resulted in a complete reversal.  Memory became inexpensive and
> > plentiful.  Nowadays, the lack of flow control has led to enormously
> > long queues of messages waiting to be delivered. The term of art is
> > bufferbloat.
> >
> > Steve
> >
> > On Tue, Apr 30, 2024 at 3:41 AM Detlef Bosau via Internet-history
> > <internet-history at elists.isoc.org> wrote:
> >
> >     Dear all,
> >
> >
> >     may I ask this question?
> >
> >     RFC 791 explicitly states that there is NO flow control in IP.
> >
> >     As far as I see, some packet switching networks provide flow control
> >     mechanisms, while others don't. So, I have some rough idea, why this
> >     design decision was taken.
> >
> >     I wonder, whether there was a general discussion of this issue in the
> >     past, particularly as this issue should have been relevant for the
> >     ARPANET as well.
> >
> >     Many thanks for any comments on this one
> >
> >
> >     Detlef
> >
> >     --
> >     Internet-history mailing list
> >     Internet-history at elists.isoc.org
> >     https://elists.isoc.org/mailman/listinfo/internet-history
> >
> >
> >
> > --
> > Sent by a Verified
> > Sent by a Verified sender
> > <https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y>
> > sender
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>

-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346

until further notice
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4006 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20240430/41e7c18d/attachment.p7s>