RFC 47

BBN's Comments on NWG/RFC #33 🎀

Okay so the title block first: this is RFC 47 from the Network Working Group, written by J. Postel and S. Crocker at UCLA, dated 20 April 70 🌸. The doc doesn't list a category or status, and it doesn't say it obsoletes or updates anything 🧚.

BBN sent over some comments on NWG/RFC 33, but they wouldn't publish them because they didn't want to be embarrassed 💀. Embarrassment aside, the comments were super useful, so we're sharing them with our friends 🫶. Bill Crowther is the author.

I found two substantial errors in the Host Protocol Paper, which was otherwise an excellent paper ✨. Both come from misunderstanding what the IMP is as a communications device, especially how much buffering an IMP has to do 🦋. The authors picture the network as a place you push a message into, where it wanders around, sits in buffers for ages, and then pops out at the destination. A better picture is that the message pops back out an instant after it goes in. There is a delay, sure, but mostly it's the phone line hardware causing it. IMP buffering is minimal and only exists for error control and momentary traffic surges 💅.

Since we can't force a Host to take a message, we built a super elaborate RFNM mechanism to suspend new input until it does 🔥. It's an imperfect attempt at a seriously hard communications problem. The goal is to regulate traffic so that, as the Host takes its message from the IMP, the next message is arriving on the phone line and no buffering happens at all 🌈.

We can't actually pull that off, so we included buffering to handle traffic surges. Those buffers only work for their purpose if they're empty, because only empty buffers can soak up a surge 😭.

Two Errors, Page 5 🍓

The first error: the authors say "Implicit in this purpose is the assumption that a user does not use multiple links to achieve a wide band." But one of the main reasons links exist is to get a wider band, so this is the opposite of the vibe ✨.

We want as much bandwidth as possible. Our troubles aren't about wide band, they're about an imbalance of input and output. The authors correctly noticed that multiple links subvert the RFNM mechanism and make our job harder, but they labeled the problem wrong 👑.

Also on page 5: "An even more basic assumption, of course, is that the network's load comes from some users transmitting sequences of messages rather than many users transmitting single messages coincidentally." We're in great shape against single-message users when their messages are randomly related. The stats are all on our side, and we have special procedures for the rare coincidences 🦋. Our real problems come from non-random coincidences, so we've taken special precautions against users sending bursts (sequences) of messages. We assume all kinds of users and protect ourselves accordingly 💜.

The Buffer Drama, Pages 23 and 24 🙈

On pages 23 and 24 there are 4 critical sentences that imply the system design could've been better if the Host could pick which of several waiting inputs to accept. We agree the Host needs to buffer these messages for its users, but we strongly disagree that the IMP can do that buffering 💀.

In ideal mode we'd have at most one message for the Host at any time. If we have more than one, we urgently need the Host to accept them, because our ability to handle surges is now below standard 🚨. Right now we allow three full length messages in an IMP for its Host before we start backing traffic up in the network. "Three" isn't enough to help the Host and keep a reserve for surges 😭.

"But if buffering is needed why not get more memory and do it in the IMP?" Because buffering is a Host function, it's different in each time share system, it's hard to control over a busy serial channel, it might not be needed at all in some places, and it's better done where the extra memory can be efficiently shared by the Host operating system 🧚.

I repeat: the IMP's buffers need to be empty or they aren't serving their communication purpose 🔥.

The offending sentences are:

     Paragraph 2 sentence 3
           "   3 all
           "   4 sentences 1 and 2 (80ms is hardware screw adjustable)
           "   4 sentence last

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Jeff & Christy McClellan 2/98]