The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
To: TUHS <tuhs@minnie.tuhs.org>, COFF <coff@minnie.tuhs.org>
Subject: Re: [TUHS] OSI stack (Was: Posters)
Date: Thu, 7 Feb 2019 11:07:27 -0700	[thread overview]
Message-ID: <0572e855-9aac-337f-4f1b-66dda3839e14@spamtrap.tnetconsulting.net> (raw)
In-Reply-To: <CAK7dMtBuLv+62LKknOKAYxCBwLBF2zBJ8TLTXAqnHGekGgAPFA@mail.gmail.com>

[-- 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 --]

  reply	other threads:[~2019-02-07 18:08 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-06 17:49 Noel Chiappa
2019-02-06 18:22 ` Paul Winalski
2019-02-06 20:47 ` Kevin Bowling
2019-02-07 18:07   ` Grant Taylor via TUHS [this message]
2019-02-07 18:22     ` Andy Kosela
2019-02-07 18:33       ` [TUHS] [COFF] " Dan Cross
2019-02-07 18:50     ` [TUHS] " Larry McVoy
  -- strict thread matches above, loose matches on Subject: below --
2019-02-07 19:04 Noel Chiappa
2019-02-07  1:03 Noel Chiappa
2019-02-07  0:45 Noel Chiappa
2019-02-07  0:02 Noel Chiappa
2019-02-07  0:11 ` Kevin Bowling
2019-02-06 23:18 Noel Chiappa
2019-02-06 23:40 ` Kevin Bowling
2019-02-06 23:52   ` Larry McVoy
2019-02-07  0:04     ` Kevin Bowling
2019-02-04 20:29 Noel Chiappa
2019-02-04 21:13 ` Bakul Shah
2019-02-04 21:34   ` Clem Cole
2019-02-05 18:01 ` Grant Taylor via TUHS
2019-02-03 18:49 Norman Wilson
2019-02-03 15:02 Noel Chiappa
2019-02-03 16:51 ` Grant Taylor via TUHS
     [not found] ` <CANCZdfq5PM9jFEi9=geC+CTnveXs5CprN7b+ku+s+FYzw1yQBw@mail.gmail.com>
2019-02-06 17:16   ` Warner Losh
2019-02-06 17:23     ` Larry McVoy
2019-02-06 23:37     ` George Michaelson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0572e855-9aac-337f-4f1b-66dda3839e14@spamtrap.tnetconsulting.net \
    --to=tuhs@minnie.tuhs.org \
    --cc=coff@minnie.tuhs.org \
    --cc=gtaylor@tnetconsulting.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).