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=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,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 ce854070 for ; Wed, 6 Feb 2019 20:48:06 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 79DBA9B8A9; Thu, 7 Feb 2019 06:48:05 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 5296E9B8A5; Thu, 7 Feb 2019 06:47:31 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="key not found in DNS" (0-bit key; unprotected) header.d=kev009.com header.i=@kev009.com header.b="SbNmPUCi"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 4CAE49B8A1; Thu, 7 Feb 2019 06:47:28 +1000 (AEST) Received: from mail-it1-f176.google.com (mail-it1-f176.google.com [209.85.166.176]) by minnie.tuhs.org (Postfix) with ESMTPS id A36EF9B8A0 for ; Thu, 7 Feb 2019 06:47:27 +1000 (AEST) Received: by mail-it1-f176.google.com with SMTP id z20so9428389itc.3 for ; Wed, 06 Feb 2019 12:47:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZfCoY34C1CHt16hGjlllP0Q/aZ9mfEXLss6kzVEAYuo=; b=SbNmPUCiSpx5Jz7DVrMC/ILyULIdYWTc5mqOQkCz15k9OJ62bPTTzZP5HtDwVbXI+p bSnCrvrQFY5ZYiSPdoU2Xmejy5hHe2haDDudDuaAxIv7DTtqgUXI1pheiGfy4VspVmGn LaPjNQAUPcAO9pG8xmJFGgu0Gx2KUAwxJtXnI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZfCoY34C1CHt16hGjlllP0Q/aZ9mfEXLss6kzVEAYuo=; b=sgUqEqucbqiBAnnVUgVbf86PLC6xBr7U1M99ezlmYYs47F+KnJC5ARhgKadHJ/6O75 v6LQBc7Qc5+h8DcFITxRtO2zf9c+8lnFhhkYKLHroi5Fnp+nWsWOXf/wTfzVbnMJDMNR onL1BwQuTTC3tnixmdWj7fcRXuT/uDwcDGMvkVQA+Sphf97Tgt3+kKigmCnqz0PYwE92 YGHvtxgbptY1vlw85wYrSEoqbRs1nrUvWVViC1d7OR0cMOxtED0Eq/147sDE0OjvBftW pU8yqa2VQlzRy21kOhgh3qyzMqLDzl5/oFP+lYeLm3kQC38uk3k/DqAnnoqwDGKaHVFp mYQw== X-Gm-Message-State: AHQUAubjYG1UfwvjGVyP9UzMp+h5IdYjm3Zk0khJVZUaT3qUuvW81ofh rmIOZRftRMElsnFie1r08taHzYotNNmCt+aIh/tApQ== X-Google-Smtp-Source: AHgI3IYOQjjqV3+14WX/d//l993UOUW3TD1ok6vbY5uzgLcHyxEW/f8uO5rk3e6Mb9b+aNuvDkJyJXUNgJoY7jM2idY= X-Received: by 2002:a05:660c:d4:: with SMTP id q20mr3046334itk.21.1549486046227; Wed, 06 Feb 2019 12:47:26 -0800 (PST) MIME-Version: 1.0 References: <20190206174913.E518318C07B@mercury.lcs.mit.edu> In-Reply-To: <20190206174913.E518318C07B@mercury.lcs.mit.edu> From: Kevin Bowling Date: Wed, 6 Feb 2019 13:47:15 -0700 Message-ID: To: Noel Chiappa Content-Type: multipart/alternative; boundary="0000000000005ecc6905813fd5c0" 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: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000005ecc6905813fd5c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable At risk of inciting some inflammation I think TCP was a success because of BSD/UNIX rather than its own merits. Moving the stack into the kernel, therefore not requiring elaborate external communications controllers (like IBM's VTAM, predecessors, and other vendor networking approaches that existed since the '60s), and piggybacking on the success of UNIX and then "open systems" cemented victory. It has basically been made to work at scale, the same way gasoline engines have been made to work in automobiles. There were protocols that fit better in the era like DeltaT with a simpler state machine and connection handling. Then there was a mad dash of protocol development in the mid to late =E2=80=9880s that were measured by = various metrics to outperform TCP in practical and theoretical space. Some of these seemed quite nice like XTP and are still in use in niche defense applications. Positive, rather than negative acknowledgement has aged well as computers got more powerful (the sender can pretty well predict loss when it hasn't gotten an ACK back and opportunistically retransmit). But RF people do weird things that violate end to end principle on cable modems and radios to try and minimize transmissions. One thing I think that is missing in my contemporary modern software developers is a willingness to dig down and solve problems at the right level. People do clownish things like write overlay filesystems in garbage collected languages. Google's QUIC is a fine example of foolishness. I am mortified that is genuinely being considered for the HTTP 3 standard. But I guess we've entered the era where enough people have retired that the lower layers are approached with mysticism and deemed unable and unsuitable to change. So the layering will continue until eventually things topple over like the garbage pile in the movie Idiocracy. Since the discussion meandered to the distinction of path selection/routing.. for provider level networks, label switching to this day makes a lot more sense IMO.. figure out a path virtual circuit that can cut through each hop with a small flow table instead of trying to coagulate, propagate routes from a massive address space that has to fit in an expensive CAM and buffer and forward packets at each hop. Regards, Kevin On Wed, Feb 6, 2019 at 10:49 AM Noel Chiappa wrote: > > 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 we= re > > 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 proble= ms > > 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 hole= s > 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 > --0000000000005ecc6905813fd5c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At risk of inciting some inflammati= on I think TCP was a success because of BSD/UNIX rather than its own merits= .=C2=A0 Moving the stack into the kernel, therefore not requiring elaborate= external communications controllers (like IBM's VTAM, predecessors, an= d other vendor networking approaches that existed since the '60s), and = piggybacking on the success of UNIX and then "open systems" cemen= ted victory.=C2=A0 It has basically been made to work at scale, the same wa= y gasoline engines have been made to work in automobiles.

There were protocols that fit bette= r in the era like DeltaT with a simpler state machine and connection handli= ng.=C2=A0 Then there was a mad dash of protocol development in the mid to l= ate =E2=80=9880s that were measured by various metrics to outperform TCP in= practical and theoretical space.=C2=A0 Some of these seemed quite nice lik= e XTP and are still in use in niche defense applications.

Positive, rather than negative acknowledgement has age= d well as computers got more powerful (the sender can pretty well predict l= oss when it hasn't gotten an ACK back and opportunistically retransmit)= .=C2=A0 But RF people do weird things that violate end to end principle on = cable modems and radios to try and minimize transmissions.

One thing I think that is missing in my contempor= ary modern software developers is a willingness to dig down and solve probl= ems at the right level.=C2=A0 People do clownish things like write overlay = filesystems in garbage collected languages.=C2=A0 Google's QUIC is a fi= ne example of foolishness.=C2=A0 I am mortified that is genuinely being con= sidered for the HTTP 3 standard.=C2=A0 But I guess we've entered the er= a where enough people have retired that the lower layers are approached wit= h mysticism and deemed unable and unsuitable to change.=C2=A0 So the layeri= ng will continue until eventually things topple over like the garbage pile = in the movie Idiocracy.

Since the discussion meandered to the distinction of path selection/routing= .. for provider level networks, label switching to this day makes a lot=20 more sense IMO.. figure out a path virtual circuit that can cut through=20 each hop with a small flow table instead of trying to coagulate, propagate = routes from a massive address space that has to fit in an expensive CAM and= buffer and forward packets at each hop.

Regards,
Kevin

On Wed, Feb 6, 2019 at 10:49 AM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote= :
=C2=A0 =C2=A0 = > On Wed, Feb 06, 2019 at 10:16:24AM -0700, Warner Losh wrote:

=C2=A0 =C2=A0 > In many ways, it was a classic second system effect beca= use they were
=C2=A0 =C2=A0 > 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 contemporaneou= s; and
my impression was they were trying to design the next step in networking, b= ased
on _their own_ analysis of what was needed.

=C2=A0 =C2=A0 > without really, truly knowing the differences between ac= tual problems
=C2=A0 =C2=A0 > and mere annoyances and how to properly weight the sever= ity of the issue
=C2=A0 =C2=A0 > in coming up with their solutions.

This is I think true, but then again, TCP/IP fell into some of those holes<= br> 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= 9; fields
in the IP and TCP headers for things that never got really got
used/implemented (Type of Service, Urgent, etc).

`=C2=A0 =C2=A0 =C2=A0 =C2=A0 Noel
--0000000000005ecc6905813fd5c0--