Dismiss
IP.com applications will be updated on Sunday, March 5, from 11 am to 2 pm ET, to add new functionality and content. You may experience brief service interruptions during this period. We apologize for any inconvenience.
Browse Prior Art Database

Current flow-control scheme for IMPSYS (RFC0442)

IP.com Disclosure Number: IPCOM000004970D
Original Publication Date: 1973-Jan-24
Included in the Prior Art Database: 2001-Jul-12
Document File: 8 page(s) / 16K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

V. Cerf: AUTHOR

Abstract

BB&N quarterly report #13 outlines part of the current flow control scheme in the IMP operating system. A meeting held March 16, 1972, at BB&N was devoted to the description of this new scheme for the benefit of interested network participants.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 27% of the total text.

Network Working Group V. Cerf Request for Comments: 442 24 January 1973 NIC: 13774

The Current Flow-Control Scheme for IMPSYS

BB&N quarterly report #13 outlines part of the current flow control scheme in the IMP operating system. A meeting held March 16, 1972, at BB&N was devoted to the description of this new scheme for the benefit of interested network participants.

This note represents my understanding of the flow control mechanism. The essential goal is to eliminate unnecessary retransmissions when the load is heavy, eliminate the retransmission time-out period when the load is light, increase bandwidth, prevent re-assembly lock-up, control traffic from HOSTS into the net more strictly than the earlier link blocking method, and secure the rights of life, liberty, and the pursuit of happiness for ourselves and our posterity,...oops.

Source IMP-to-Destination IMP Protocol

There are two different protocols depending on message length (i.e. single or multi-packet). We illustrate first the single packet case.

Source Imp Destination Imp

case 1) message (1) implicit req (1)--->

RFNM (arrived ok) [discard copy of msg]

case 2) message (1) implicit req (1)---> no room, don't respond

All (1) (room available) message (1) [discard copy of msg] RFNM (arrived ok)

In the first case, a single packet message is sent to the destination IMP. This message acts as an implicit request for single packet buffer space. If there is room, as in case 1, the destination IMP responds with a RFNM. The source IMP, which has retained a copy of the message, deletes its copy and goes on.

The second case illustrates what happens when the source IMP sends a message to a destination IMP at which there is no room for the one- packet message. The arrival of the single packet message constitutes a request for single packet buffer space, and is recorded as such by the destination IMP in a first-come-first-served buffer reservation

Cerf [Page 1]

RFC 442 The Current Flow-Control Scheme for IMPSYS January 1973

request queue. When space is available, the destination IMP will transmit an ALL (1) to the requesting source IMP which can then send the single packet message again, this time knowing that space has been reserved at the destination.

For multi-packet messages, the procedure is somewhat different. When a message enters an IMP from a HOST, and the "last bit" flag is not set when the number of bits in a maximum length single packet have arrived, the IMP halts the HOST->IMP transmission line while it determines whether space has been reserved at the dest. IMP. If space (8 packets worth) has been reserved, the HOST->IMP line is re- opened, and the message is sent out normally. If space has not been reserved, the HOST->IMP line is kept closed while the source IMP makes a request for multi-packet buffer storage at the destination IMP. When 8 buffers are available, the destination IMP responds with an ALL (8). The source IMP then transmits the message, and waits for a combination RFNM and ALL (8) from the...