[ih] Flow Control in IP

[Steve Crocker]

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
[image: Sent by a Verified sender]
<https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y>
sender