RFC 19

RFC 19: Two Protocol Suggestions to Reduce Congestion at Swap-Bound Nodes 💖

okay bestie, this is RFC 19 🦋 from the Network Working Group, written by John E. Kreznar of SDC on 7 October 1969 ✨ the original doesn't list a category or status, and it doesn't say what it obsoletes or updates, so there's nothing to report on that 🫶

Okay so the HOST systems that are going to be nodes in the ARPA IMP network don't all swap between core and auxiliary store at the same speed 😭 The slower ones, like our 360/50 system with its 2303 drump swap store, could make the network better, not just for themselves but for everyone 🌈 if these two protocol suggestions get adopted 💅

1. HOST control of ordering of IMP-to-HOST traffic. Right now the IMP-HOST protocol says messages get delivered from the IMP to the HOST in the order the IMP received them. That can lead to wasted swapping 💀 Say the IMP has messages for the HOST's timeshare users A and B, in that order, while B is in HOST core. B would have to get swapped out, A swapped in, and the first message accepted. Then surprise, A has to get swapped out and B swapped back in again 🙈 If the HOST could (a) read the IMP's queue of waiting messages and (b) accept them in whatever order it found most effective, that would be a whole new way to level up network efficiency 🔥 Clearly this change would have an impact on BBN's IMP software 👑
2. Core-to-core transfers between HOSTS. On another level, maybe one that doesn't involve HOST-IMP protocol or IMP software changes 🧚 there's a HOST-HOST protocol where 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 a file to and from a swap-bound HOST 😍 Unfortunately the numbers kind of limit how great this is 😩 If we assume a 50 kilobit/sec line that's dedicated at 100% efficiency to this transfer (which may need slightly different handling of RFNMs in this case), that works out to just over 6 8-kilobit messages per second. In a timeshare environment it might be impolitic to lock a single program in core for more than about 2 seconds. If that's the case, the method would only be applicable for the pretty 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 the author thinks 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

The squad behind this note 🎀 These are the names listed at the end, so flowers to all of them 🌸

       [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Alex Portnoy 1/97 ]

That's the whole RFC, periodt 🌈💅