[ih] Internet Protocol Implementation Guide

[David Finnigan]

That's close. Let me explain with a scenario. Imagine 3 segments: 1, 2, 
and 3 all fit within a TCP host's receive window. All 3 have controls 
and text. For some reason, the host receives segment 2 first, then 3, 
then 1.

Let's say that segment 2 has an URG flag and pointer. Segment 3 has a 
FIN. And Segment 1 has a window update. All 3 have text too.

 From my understanding of reading the source of some of these TCP 
implementations, they will process these segments in order received, 
out-of-sequence. So the urgent pointer will be updated and the segment 
text queued from segment 2. Then the FIN flag is noted (but not acted 
upon immediately), and text queued from segment 3. And finally, the 
window update is noted and text queued from segment 1.

RFC 793 states that segments in their entirety should be queued and 
processed in sequence, but it looks like some implementors noticed that 
in practice, you can process some controls out of sequence.

I was wondering who was first to notice this possibility?


-David Finnigan


On 21 Aug 2025 8:21 am, Vint Cerf wrote:
> David, it was always believed that segments might have to be decrypted
> out of order if they were encrypted - that was an important design
> criterion for packet cryptography but maybe you are thinking of
> something else? We assumed the reassembly would take place within a
> buffer window so they could be placed in the right part of the buffer
> before assembly was completed and the result delivered to the next
> layer up.
> 
> v
> 
> On Thu, Aug 21, 2025 at 9:09 AM David Finnigan via Internet-history
> <internet-history at elists.isoc.org> wrote:
> 
>> On 20 Aug 2025 4:17 pm, Barbara Denny via Internet-history wrote:
>>> Quite some time ago I sent email out with links to the handbooks
>>> produced by the NIC at SRI. I don't remember if that email also
>>> included the Internet Protocol Implementation Guide.  Sending this
>>> message in case this document wasn't included.
>>> https://apps.dtic.mil/sti/tr/pdf/ADA153624.pdf
>>> The end of the document has an interesting snapshot of the status
>> of
>>> TCP/IP implantations as of June 8, 1982.
>>> barbara
>> 
>> While looking at the sources for some early TCP implementations, I
>> noticed that some of them will process most TCP controls out of
>> order
>> (except FIN), so long as the segment sequence fits within the
>> receive
>> window. Segment text is always kept in sequence to be delivered to
>> the
>> user in correct order, of course.
>> 
>> Who was the one to notice that this was possible, when RFC 793
>> states
>> that segments "are generally queued and processed in sequence number
>> 
>> order" ?