[ih] Internet Protocol Implementation Guide

[Vint Cerf]

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" ?
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> -
> Unsubscribe:
> https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice