Re: [TUHS] OSI stack (Was: Posters)

Re: [TUHS] OSI stack (Was: Posters)

[Noel Chiappa]

    > 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

Re: [TUHS] OSI stack (Was: Posters)

[Paul Winalski]

On 2/6/19, Noel Chiappa <jnc@mercury.lcs.mit.edu> 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 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.

That's my recollection as well.  The OSI effort was dominated by the
European telcos, nearly all of which were government-run monopolies.
They were as much (if not more) interested in protecting their own
turf as in developing the next step in networking.  A lot of the
complexity came from the desire to be everything to everybody.  As is
often the case, the result was being nothing to nobody.

Phase V of DEC's networking product (DECnet) supported X.25 as an
alternative to DEC's proprietary transport/routing layer.  I had to
install this on one of our VAXen so we could test DECmail, our
forthcoming X.400 product.  I remember X.25 being excessively
complicated and a bear to set up compared to Phase IV DECnet (the
proprietary protocol stack).

-Paul W.

Re: [TUHS] OSI stack (Was: Posters)

[Kevin Bowling]

[-- Attachment #1: Type: text/plain, Size: 3472 bytes --]

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 ‘80s 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 <jnc@mercury.lcs.mit.edu>
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 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
>

[-- Attachment #2: Type: text/html, Size: 4134 bytes --]

Re: [TUHS] OSI stack (Was: Posters)

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 3344 bytes --]

Seeing as how this is diverging from TUHS, I'd encourage replies to the 
COFF copy that I'm CCing.

On 02/06/2019 01:47 PM, Kevin Bowling wrote:
> 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 ‘80s 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.

$ReadingList++

> 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.

Would you care to elaborate?

> 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.

I thought one of the reasons that QUIC was UDP based instead of it's own 
transport protocol was because history has shown that the possibility 
and openness of networking is not sufficient to encourage the adoption 
of newer technologies.  Specifically the long tail of history / legacy 
has hindered the introduction of a new transport protocol.  I thought I 
remembered hearing that Google wanted to do a new transport protocol, 
but they thought that too many things would block it thus slowing down 
it's deployment.  Conversely putting QUIC on top of UDP was a minor 
compromise that allowed the benefits to be adopted sooner.

Perhaps I'm misremembering.  I did a quick 45 second search and couldn't 
find any supporting evidence.

The only thing that comes to mind is IPsec's ESP(50) and AH(51) which—as 
I understand it—are filtered too frequently because they aren't ICMP(1), 
TCP(6), or UDP(17).  Too many firewalls interfere to the point that they 
are unreliable.

> 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.

I think label switching has it's advantages.  I think it also has some 
complications.

I feel like ATM, Frame Relay, and MPLS are all forms of label switching. 
  Conceptually they all operate based on a per-programed path.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4008 bytes --]

Re: [TUHS] OSI stack (Was: Posters)

[Andy Kosela]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

On Thursday, February 7, 2019, Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> Seeing as how this is diverging from TUHS, I'd encourage replies to the
> COFF copy that I'm CCing.
>
> On 02/06/2019 01:47 PM, Kevin Bowling wrote:
>
>> 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 ‘80s 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.
>>
>
> $ReadingList++


XTP was/is indeed very interesting.  It was adopted by US Navy for SAFENET
and created by Greg Chesson who was active in the early UNIX community.
Not sure if we have him here on this list though.

--Andy

[-- Attachment #2: Type: text/html, Size: 1210 bytes --]

Re: [TUHS] [COFF] OSI stack (Was: Posters)

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

On Thu, Feb 7, 2019 at 1:22 PM Andy Kosela <akosela@andykosela.com> wrote:

> On Thursday, February 7, 2019, Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
> wrote:
>
>> Seeing as how this is diverging from TUHS, I'd encourage replies to the
>> COFF copy that I'm CCing.
>>
>> On 02/06/2019 01:47 PM, Kevin Bowling wrote:
>>
>>> 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 ‘80s 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.
>>>
>>
>> $ReadingList++
>
>
> XTP was/is indeed very interesting.  It was adopted by US Navy for SAFENET
> and created by Greg Chesson who was active in the early UNIX community.
> Not sure if we have him here on this list though.
>

Sadly, Greg Chesson passed away a couple of years ago after battling cancer
for some time.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 1730 bytes --]

Re: [TUHS] OSI stack (Was: Posters)

[Larry McVoy]

On Thu, Feb 07, 2019 at 11:07:27AM -0700, Grant Taylor via TUHS wrote:
> On 02/06/2019 01:47 PM, Kevin Bowling wrote:
> >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 ???80s 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.
> 
> $ReadingList++

Greg Chesson was the guy behind XTP.  I worked for him at SGI, he was a
hoot (lost him to cancer a while back).  I think I've posted this before
but here he is not long before he died (he came up to bitch about kids
these days with their shiney frameworks and new fangled languages, what's
wrong with C?)

http://mcvoy.com/lm/xtp+excavator

He was an engineer to the core, he refused to take any info from me on how
to run the machine, just sat there and figured it out.

--lm