RFC 568

Response to RFC 567 -- Cross-Country Network Bandwidth 🎀

okay bestie, this is RFC 568 💖 written by J. McQuillan from BBN-NET (NIC #18971), dated 18 September 1973, and it was received at the NIC on 21-Sept-73 ✨. The original doesn't list a category, and it doesn't say whether it obsoletes or updates anything 🙈. It's basically a reply to RFC 567 by L. Peter Deutsch, and it's a correction because Deutsch got some fundamental things wrong 💅

This note is a quick correction to several fundamental errors in RFC 567 by L. Peter Deutsch 🫶

1. Not all packets are 1000 bits long 🙅‍♀️ This is basic to the network design, so it's a big deal ✨
2. RFNMs are 152 bits long (72 bits of hardware framing and 80 bits of software identification and addressing) 🧚 Host Host protocol messages like single-characters and allocates are 216 bits long (40 bits of Host protocol, 8 bits for the character or ALL, and an additional 16 bits of IMP software header) 💜 That totals to 736 bits in each direction, not 4000 😭
3. So the number of single-character messages that can be supported is over 200 per second, not 37.5 per second 🔥 Not only is that traffic pattern unlikely, it can also be supported in the IMP subnetwork much more easily than in most Hosts 👑
4. Also, if the demand for remote echoing ever goes over network capacity, the TIPs and Hosts can just buffer 2 characters per message, which doubles the effective bandwidth of the network 🌈 Of course, dozens of characters can be packed into a single message with nearly proportional increases in effective bandwidth, given the size of the overhead 🍓 This buffering happens automatically and gradually as load goes up, as a natural result of slowed responses 🦋
5. It's most likely that the poor echoing response Deutsch mentioned isn't caused by peak network loads 🙈 If echoing was coming in 5-character bursts, there would have to be _1000_ characters per second coming from users of remote-echo systems just to use all the capacity of 3 50-kilobit paths 💀
6. This reasoning points to the more serious error in RFC 567: the problems with bad echo response are delay problems, not bandwidth problems 😤 When designing the IMP software, we used a bimodal model of traffic, and tried to give low delay for interactive traffic and high throughput rates for bulk data transfers 🌸 It's pointless to aim for high data rates with short messages, since the overhead in bits, and also in IMP and Host processor wake-ups, is too high 🫠 The main factor in echoing performance is delay. As an extreme example, echoing over a megabit per second satellite link will lag a second or more behind input, with no bandwidth limitations at all 🛰️✨
7. We agree that changes to the TELNET protocol may well improve performance by reducing network traffic and, even more importantly, reducing demands for Host processing 👏 On network paths with long delay, especially satellite links, those changes are essential for interactive echoing 💅🔥

JMcQ/jm

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Alex McKenzie with ] [ support from GTE, formerly BBN Corp. 10/99 ]