[ih] Flow Control in IP

Tue Apr 30 13:20:22 PDT 2024

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