[ih] history of protocol bugs

[Jack Haverty]

For protocol bugs, rather than coding errors or technology evolution, I 
can vaguely remember one such incident.  During the process of defining 
and testing TCP4, there was a state diagram in the protocol definition 
that had to be changed.   The original state diagram didn't properly 
handle all possible sequences of events involving lost, delayed, 
duplicated, or reordered datagrams.  So several additional states had to 
be added to the state diagram. This fixed a true "protocol bug" of the 
TCP state machine.

This was circa 1977-1978.  I think the problem occurred in the "opening" 
and/or "closing" handshakes.  It surfaced as we were implementing and 
trying out the first TCP4 implementations.   At the time, we were 
frequently rebooting or restarting various pieces of equipment including 
routers ("gateways" at that point) and host computers.   Many such 
devices didn't always restart "cold", but might have buffers still 
holding datagrams from previous testing.

So it was common for a TCP to send or receive a datagram from a previous 
test run -- i.e., a datagram "delayed in the Internet" for possibly 
minutes or even hours.   There was even one case where a computer 
(PDP-10 IIRC) had a hardware problem and was down for several days, but 
transmitted the datagrams from its output queue several days later.   
Magnetic core memory didn't lose its contents over power cycles so the 
machine just continued after the hardware was fixed.

Those long-delayed datagrams surfaced the issue with the state diagram.  
The "Initial Sequence Number" (ISN) issue also still existed and was 
addressed by requiring the ISN to be assigned by a random number 
generator.  That was a problem for many computers at the time, which had 
no way in the hardware to generate a random number.   I can't remember 
what I did on the PDP-11.....but I still have a listing of the 1970s code.

I recall Jon Postel drawing the TCP state diagram on a whiteboard and 
adding the several new states that we decided were needed to make the 
protocol able to withstand "long delay" datagrams.  All us implementers 
changed our code to add the new states and the problems (those ones at 
least) were solved.  Somewhat later Jon documented the protocol in the 
RFCs which were required to make TCP a "DoD Standard".

I'm not sure if any of this ever got written up, but it may have been in 
one of Jon's notes on the Internet meetings.

Jack Haverty
(implemented TCP for Unix on PDP-11/40)

On 11/10/23 06:04, Dave Crocker via Internet-history wrote:
> On 11/10/2023 4:50 AM, Craig Partridge via Internet-history wrote:
>> Which of these bugs (or kinds of bugs) do you want to track?
>
> RFC Errata are required to be deviations in the specification, from 
> what was intended by the authors.
>
> This draws a distinction from things that might be called 
> 'enhancements'.  A bug is a behavior that was not originally 
> intended.  An enhancement is a change in intention.
>
> So...
>
>> 1. 20 years ago, a software vendor shipped code that computed the wrong
>> checksum on a FIN-ACK if the FIN-ACK had to be retransmitted.
> bug
>
>
>> 2. In 1974, Ray Tomlinson
> ...
>>    He realized that
>> TCP needed a way to select initial sequence numbers that prevented old
>> segments from being confused with new segments.
> bug.
>
>
>> 3. Around 1990, people realized that the TCP sequence number space 
>> was too
>> small for gigabit links and a TCP option was developed to expand the
>> sequence space.
> enhancement.
>
>
> d/
>