RFC 1151

Version 2 of the Reliable Data Protocol (RDP) 🎀

Okay bestie, the title block gives us all the tea ✨. This is RFC 1151, written by Craig Partridge (BBN Systems and Technologies) and Robert Hinden (BBN Communications Corp.) in April 1990 💖. It updates RFC 908, which is the original RDP spec, and it's experimental 🧪. Nothing is listed as obsoleted here.

Status of this Memo 📝

This RFC suggests a bunch of updates to the RDP spec in RFC-908, based on what the authors learned from actually using the protocol. This revised version is experimental 🧪.

Distribution of this memo is unlimited 🌍.

Introduction 💅

So in 1986 and 1987 there were experiments that turned up some ambiguities and problems in the RDP spec 👀. The authors really wanted to rewrite the whole RDP spec to fix everything, but there wasn't much demand for RDP implementations, so they never had the time to justify it 😭. This document is the list of changes they think should be made to RDP version 1 🫶.

You'll need to already know RFC-908 for this one, bestie 📖.

Changes To The Protocol Header 🎀

There are three changes to the protocol header: the checksum algorithm changed, the port size went up, and the version number got bumped 🆙. The new header format is in Figure 1 ✨.

Here's the big discovery from testing. The cost of computing the RDP checksum was surprisingly all over the place 🙈. It depended a lot more on the host's data representation than anyone expected. Optimized checksum implementations on two comparable hardware setups had performance that differed by a factor of five 💀. Since checksum speed is a huge factor in how well the protocol performs, this caused a noticeable difference in throughput 📉.

Such a wide gap between comparable machines was not it, so the checksum got changed 🔥. RDP now uses the 16-bit TCP checksum, which is specified on page 16 of RFC-793 💜.

The 8-bit port size is probably too small to support a big range of applications 🙅‍♀️. So the port size is now 16-bits 🌈. Port numbers less than 1024 are reserved for well-defined applications, and allocable ports start at port number 1024 🧚.

Finally, since the checksum and port size changed, the version number went up to 2 👑.

                   0             0 0   1         1
                   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                  +-+-+-+-+-+-+---+---------------+
                  |S|A|E|R|N| |Ver|    Header     |
                0 |Y|C|A|S|U|0|No.|    Length     |
                  |N|K|K|T|L| |   |               |
                  +-+-+-+-+-+-+---+---------------+
                1 |         Source Port           |
                  +---------------+---------------+
                2 |       Destination Port        |
                  +---------------+---------------+
                3 |          Data  Length         |
                  +---------------+---------------+
                4 |                               |
                  +---    Sequence Number      ---+
                5 |                               |
                  +---------------+---------------+
                6 |                               |
                  +--- Acknowledgement Number  ---+
                7 |                               |
                  +---------------+---------------+
                8 |           Checksum            |
                  +---------------+---------------+
                9 |     Variable Header Area      |
                  .                               .
                  .                               .
                  |                               |
                  +---------------+---------------+

                         RDP Header Format
                             Figure 1

Minor Errors and Ambiguities 🔍

Some ambiguities and minor errors were found in RFC-908 😬. They get fixed in this section, so let's go 🏃‍♀️.

The state variable SND.UNA is treated inconsistently in the pseudo-code on pages 21-29 🤯. On page 12, SND.UNA is defined as "the sequence number of the oldest unacknowledged segment" ✅. On page 21 it's correctly set to the initial sequence number when the connection opens ✅. But on page 28, when an acknowledgement comes in, SND.UNA gets set to SEG.ACK, which is the sequence number being acknowledged, instead of SEG.ACK+1 ❌. A similar mix-up happens on page 26 🙃. The proper fix is to always set SND.UNA to SEG.ACK+1 💖.

The pseudo-code on page 25 for the SYN-SENT state is wrong 🚫. The first few lines throw away every packet with the ACK bit set, but the later lines test the ACK bit. So the ACK bit test should go after all the other tests 🧩. Also, if the ACK bit is set, a RST segment gets sent to reset the remote peer, but the local peer is left half-open 😱. There's a similar problem in the SYN-RCVD state. The local peer should deallocate the connection record and close 🔒.

On page 24, the pseudo-code says that if non-data packets come in while in the CLOSED state, a RST segment with SEG.ACK set to RCV.CUR should be sent 🤔. But RCV.CUR isn't defined in the CLOSED state 💀. So SEG.ACK should be set to SEG.SEG instead ✨.

There's some inconsistency about handling a RST packet in the CLOSE-WAIT state 🌀. On page 24, the pseudo-code shows a RST causing the connection state to become CLOSED. But the text on page 13 and the state diagram on page 10 suggest the connection state should stay in CLOSE-WAIT 🙄. The implementation should stay in CLOSE-WAIT 🫶.

On page 29, the pseudo-code for the OPEN state suggests that if a data packet arrives in sequence, the acknowledgement packet should not contain EACKs. That's misleading 🙈. Implementations may include EACKs in the acknowledgement 🦋.

On page 18, you can read the right edge as either inside or outside the window 🤷‍♀️. That leads to a one-segment difference in window size. The proper reading is that the right edge is outside the window 🚪. In other words, the right edge is the first sequence number that can't be sent or received, and the total window size is 2*X, where X is the maximum number of outstanding segments 📏.

One last problem: RDP's flow control doesn't let the receiver close the sender's window 😤. So if the receiver acknowledges segments as soon as they arrive, the sender can easily send more data than the receiver is ready to buffer 💥. A fix for this, suggested by members of the End-2-End Research Group, is to only acknowledge a segment after it's been delivered to the application 🎯. This hasn't been tested yet though 🧪.

Security Considerations 🔐

Yikes, security issues are not addressed in this memo 💀. Don't look to this doc for any security guidance, because there isn't any 😭.

Authors' Addresses 📮

Craig Partridge 🦋 Bolt Beranek and Newman Inc. 50 Moulton Street Cambridge, MA 02138

Phone: (617) 873-2459

EMail: craig@BBN.COM

Robert Hinden 🌸 Bolt Beranek and Newman Inc. 50 Moulton Street Cambridge, MA 02238

Phone: (617) 873-3757

Email: HINDEN@BBN.COM