Two protocol suggestions to reduce congestion at swap bound nodes
Two proposed ways to reduce swapping delays at slow ARPANET hosts.
Kreznar, J.E., "Two protocol suggestions to reduce congestion at swap bound nodes", RFC 19, DOI 10.17487/RFC0019, October 1969, <https://www.rfc-editor.org/info/rfc19>.
@misc{rfc19,
series = {Request for Comments},
number = 19,
howpublished = {RFC 19},
publisher = {RFC Editor},
doi = {10.17487/RFC0019},
url = {https://www.rfc-editor.org/info/rfc19},
author = {J.E. Kreznar},
title = {{Two protocol suggestions to reduce congestion at swap bound nodes}},
pagetotal = 2,
year = 1969,
month = oct,
} RFC text
Contents
Network Working Group John E. Kreznar
Request For Comments: 19 SDC
7 October 1969
Two Protocol Suggestions to Reduce Congestion at Swap-Bound Nodes
There is a wide variance in swap rates between core and auxiliary store
among the HOST systems to be nodes in the ARPA IMP network. The slower
of these, of which our 360/50 system with 2303 drump swap store is an
example, might improve the utility of the network not only for
themselves but for all nodes if the two protocol suggestions of this
note were to be adopted.
1. HOST control of ordering of IMP-to-HOST traffic. IMP-HOST protocol
now calls for delivery of messages from IMP to HOST in the order in
which the IMP received them. This may lead to wasted swapping if,
for example, the IMP has messages for its HOST's timeshare users A
and B, in that order, at a time when user B is in HOST core. B
would have to be swapped out, A in, and the first message accepted--
only to discover that now A must be swapped out and B back in again.
If the HOST could a) read the IMP's queue of waiting messages and b)
accept them in the order it found most effective, then a new
mechanism for improvement of network efficiency would be at hand.
Clearly this change would have an impact on BBN's IMP software.
2. Core-to-core transfers between HOSTS. At another level, perhaps not
involving HOST-IMP protocol or IMP software changes, is a HOST-HOST
protocol wherein cooperating HOSTS agree to lock appropriate
programs in core for the duration of a multi-message file transfer
on an auxiliary connection. This could greatly reduce the time to
transfer such a file to and from a swap-bound HOST. Unfortunately,
the numbers mitigate possible advantages of this approach to some
extent: if we assume a 50 kilobit/sec line and support further that
it is dedicated at 100% efficiency to this transfer (which may
require slightly different handling of RFNMs in this case) this
comes out to just over 6 8-kilobit messages per second. It may be
impolitic in a timeshare environment to lock a single program in
core for more than about 2 seconds. If this is the case, then the
method would be applicable only for the rather limited range of file
sizes of 2-16 messages. Nevertheless, the time to move a large file
could be so greatly enhanced by this approach that I think it
deserves consideration.
1. Abhi Bhushan, Proj. MAC 10. Jerry Cole, SDC
2. Steve Crocker, UCLA 11. John Kreznar, "
3. Ron Stoughton, UCSB 12. Dick Linde, "
4. Elmer Shapiro, SRI 13. Bob Long, "
5. Steve Carr, Utah 14. Reg Martin, "
6. John Haefner, RAND 15. Hal Sackman, "
7. Paul Rovner, LL 16. C. Weissman, "
8. Bob Khan, BB & N 17. Marty Bleier, "
9. Larry Roberts, ARPA
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex Portnoy 1/97 ]
ISO Plain Language
On this page
§1Why Message Order Could Waste Time
Hosts differed in how quickly they could move programs between core memory and auxiliary storage. When an IMP delivered messages in the order it received them, a host might have to swap one user's program out and another in, then reverse that work for the next message.
The note suggests that reducing this swapping could improve network use for slower hosts and other nodes.
A host can waste time moving programs in and out of memory when messages arrive for users in an inconvenient order. The note explores ways to reduce that extra work.
§1Let the Host Choose the Next Message
The first proposal would let a host read the IMP's queue of waiting messages and accept them in the order it finds most effective. For example, the host could accept a message for a user whose program is already in core instead of first swapping in another user's program.
The author notes that this change would affect BBN's IMP software.
The host could choose a waiting message for a program already in memory. This could avoid swapping programs just to follow the IMP's arrival order.
§2Keep Programs in Memory During a Transfer
The second proposal is for cooperating hosts to lock the needed programs in core during a multi-message file transfer over an auxiliary connection. The author estimates that a 50-kilobit-per-second line used at 100% efficiency would carry just over 6 messages of 8 kilobits each per second.
The note says keeping a program in core for more than about 2 seconds may be unsuitable in a time-sharing environment. On that assumption, this approach would fit only files of 2-16 messages.
Two hosts could keep the needed programs in memory while sending a file. The note says this would suit only a limited file size because a program should not stay locked in memory too long.
§2Suggestions for Consideration
RFC 19 offers two protocol suggestions: host-controlled selection from the IMP's queue, and core-to-core transfers with programs locked during the transfer. The author points out that the second proposal has a narrow useful range under the stated assumptions.
The note recommends considering the ideas but does not record an adoption decision.
The document offers two possible ways to reduce swapping overhead. It explains a limit on the second idea but does not say whether either proposal was adopted.