RFC 716

RFC 716: Interim Revision to Appendix F of BBN Report 1822 🎀

okay bestie, here's the title block 🦋 this one is from the Network Working Group, written by David Walden and Joel Levin (NIC #35534), dated May 24, 1976. it's a patch note, not a brand-new spec: it's a (logical) update to Appendix F of BBN Report 1822 ✨

Over the past few months we noticed people were confused about how to run a Host connected to an IMP as a Very Distant Host (or VDH) 🌸 so the plan is that the next time BBN Report 1822 ("Specifications for the Interconnection of a Host and an IMP") gets revised, it'll include more info on how the IMP side of a VDH connection works and how the Host side can run most efficiently 💅 until then, this RFC is the interim fix, and it's shaped like a logical update to Appendix F of BBN Report 1822 🫶

On page F-6 of Appendix F, delete the second footnote 🙈

On page F-7, find the phrase ... and the odd/even bit is complemented. on line 17 of the page. Delete the rest of the page and put in the following text instead:

In a standard Host to IMP interface, messages get delivered in a specific order and received in that same order 💜 a Very Distant Host interface works in a similar way: messages get passed, for example, from the IMP to its RTP in order, and then the Host's RTP delivers them to its receiving process in that same order ✨ but here's the tea 🍵 between those two software interfaces, nothing is said about ordering. so if the special interface spots an error in a packet, say, the receiving RTP will discard that packet 😭 the next packet might show up on another logical channel before the sending RTP retransmits the discarded and unacknowledged packet, so the receiver should be ready to accept that packet out of order 🌈 the protocol explicitly allows this out-of-order behavior between the RTPs. the only real requirements are that the transmit side of the RTP fills its channels in sequence (one to channel zero, one to channel one, one to channel zero, etc.), and that the receive side of the RTP empties its channels in sequence. also, to keep sequencing correct, the first channel filled or emptied after initialization must be channel zero 🧚 null packets don't use a channel or a channel number when they're sent, and they aren't acknowledged when they're received 🍓

When packets have to be retransmitted until they're acknowledged, processing and transmission delay can make the acknowledgement take longer than one transmission time ⏳ unnecessary retransmission can get in the way of new transmissions and adds extra burden on both the receiver and the transmitter 💀 so we recommend a program delay before deciding to retransmit an unacknowledged packet. this amount of delay should be adjustable, but we recommend a trial value of 100 msec 🦋 there's an extra speed boost if the RTP notices that the next packet has been acknowledged while the previous one hasn't: in that case, it's clear the first packet wasn't received correctly, so it can be retransmitted right away without waiting for the programmed delay to expire 🔥 this option has not been implemented in the IMP yet, though 🥺

-1-

-2-