[ih] IENs

[vinton cerf]

who ever that DARPA official might have been, it was NOT me.

v


On Tue, Apr 15, 2025 at 4:50 PM Alexander McKenzie via Internet-history <
internet-history at elists.isoc.org> wrote:

>  Folks,
>
> IENs are available to everyone these days, but back at the time they were
> being written they were on a strictly-enforced limited distribution.  For
> example, a DARPA official told one PI at BBN that his contract would be
> cancelled if the IEN's he received leaked into the possession of another PI
> at BBN. Therefore it is not surprising that IEN's were rarely referenced by
> other documents.
>
> Cheers,
> Alex
>
> On Monday, April 14, 2025 at 07:22:39 PM EDT, Greg Skinner via
> Internet-history <internet-history at elists.isoc.org> wrote:
>
>
> On Apr 12, 2025, at 11:33 AM, Jack Haverty via Internet-history <
> internet-history at elists.isoc.org> wrote:
> >
> > The 1980s era of The Internet was explicitly a time of research and the
> "Internet Experiment".    We tried to reflect that in the documents of the
> day, such as RFC793.
> >
> > The general principle was that the "on the wire" formats and meanings
> were standardized, so that any implementation of TCP could communicate with
> any other implementation.  Everything else was at best Recommendations.
> >
> > However, there were a lot of unanswered questions, such as the best way
> to deal with network errors such as dropped, duplicated, or mangled
> datagrams - such as discussed in IEN69.
> >
> > To enable research into different techniques, the specific algorithms for
> TCP functions such as retransmission timers and strategies were explicitly
> *not* standardized.    That encouraged experimentation with different kinds
> of network environments and different ideas about how to cope with errors.
> It also permitted implementations of TCP with different goals.  An
> implementer might pursue algorithms which minimized the load on their
> computer system.  Or load on the network.  Or rapidity of implementation.
> Or suitability for the specific user environment involved.  Or ...
> >
> > No one in 1981 had any significant experience with real-world TCP
> networks and their behavior under heavy loads.  The ARPANET was the basic
> wide-area network in use as the substrate for The Internet, and the ARPANET
> provided only a reliable byte-stream service that made greatly simplified
> TCP's task.
> >
> > IEN 177 says that the RSRE algorithm is the "current best procedure" and
> "will be included in the next ... specification".  I remember talking with
> Jon and others about this.  My recollection is that such an algorithm might
> be included as a "best practice" recommendation, not as a mandatory part of
> the standard.  In 1981 we simply didn't know enough to nail down an
> algorithm and there were lots of other outstanding unresolved issues that
> might be related (such as Type Of Service, Policy Routing, etc.).
> >
> > In 1981, The Internet was still very much an Experiment, but being pulled
> forward by its adoption as a DoD Standard, and later to be rocketed forward
> by its adoption in non-military networking.  I think many of those research
> questions were never answered.  I recall we even at one point we even
> opined that The Internet would be fine as long as we kept enough capacity
> in the circuits and switches to avoid overloads, while the research
> continued, seeking the "right" answers.
> >
> > Jack Haverty
>
> OK, that seems reasonable.  I did a little more digging, and found that IEN
> 50 provides some “glue” by comparing some retransmission algorithms, using
> simulations and analytical techniques to arrive at some conclusions. [1]
> It seems unfortunate to me that some of these IENs couldn’t have been
> included as references in RFC 793.  But as far as supporting (higher packet
> loss) military networking went, some of these concerns (in theory) could
> have been addressed in MIL-STD-1778 [2].  Does anyone know why they
> weren’t? The US DoD sent people to those Internet Meetings from the late
> 1970s and early 1980s, so (in theory) they had enough information to
> incorporate any additional requirements into the military standard for TCP.
>
> --gregbo
>
> [1] https://www.rfc-editor.org/ien/scanned/ien50.pdf
> [2] http://everyspec.com/MIL-STD/MIL-STD-1700-1799/MIL-STD-1778_6676/
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>