From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 1353d7cf for ; Wed, 6 Feb 2019 17:49:30 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 8EF889B8B7; Thu, 7 Feb 2019 03:49:29 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id C9D689B8A5; Thu, 7 Feb 2019 03:49:17 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 542809B8A1; Thu, 7 Feb 2019 03:49:15 +1000 (AEST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by minnie.tuhs.org (Postfix) with ESMTPS id E2DFC9B8A0 for ; Thu, 7 Feb 2019 03:49:14 +1000 (AEST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id E518318C07B; Wed, 6 Feb 2019 12:49:13 -0500 (EST) To: tuhs@tuhs.org Message-Id: <20190206174913.E518318C07B@mercury.lcs.mit.edu> Date: Wed, 6 Feb 2019 12:49:13 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Subject: Re: [TUHS] OSI stack (Was: Posters) X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: jnc@mercury.lcs.mit.edu Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" > On Wed, Feb 06, 2019 at 10:16:24AM -0700, Warner Losh wrote: > In many ways, it was a classic second system effect because they were > trying to fix everything they thought was wrong with TCP/IP at the time I'm not sure this part is accurate: the two efforts were contemporaneous; and my impression was they were trying to design the next step in networking, based on _their own_ analysis of what was needed. > without really, truly knowing the differences between actual problems > and mere annoyances and how to properly weight the severity of the issue > in coming up with their solutions. This is I think true, but then again, TCP/IP fell into some of those holes too: fragmentation for one (although the issue there was unforseen problems in doing it, not so much in it not being a real issue), all the 'unused' fields in the IP and TCP headers for things that never got really got used/implemented (Type of Service, Urgent, etc). ` Noel