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

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

[gtaylor]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3548 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20190207/7fc2c6a7/attachment.bin>

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

[akosela]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

On Thursday, February 7, 2019, Grant Taylor via TUHS <tuhs at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20190207/3e0800e1/attachment.html>

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

[crossd]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

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

> On Thursday, February 7, 2019, Grant Taylor via TUHS <tuhs at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20190207/2620a882/attachment.html>

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

[dave]

Sorry for the x-posting, but I'm not sure upon which list this topic 
belongs...  I think it's slowly drifting towards COFF, but Warren as usual 
will have the final say :-)

On Thu, 7 Feb 2019, Dan Cross wrote:

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

His birth date is not known, and I cannot find when he left us.  But yes, 
he was indeed one of the Greats.

-- Dave, the hysterical historian

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

[lm]

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

[COFF] OSI stack

[@ 2019-02-07 19:28 UTC (permalink / raw)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

On 7 Feb 2019 11:07 -0700, from coff at minnie.tuhs.org (Grant Taylor via COFF):
> 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.

While different, I think that the introduction of the more advanced
IPv6 address formats into DNS also qualifies. I don't recall off hand
if bit-string labels (which were used for reverse lookups) or the A6
RRtype (for forward lookups) was the more problematic one, but I do
recall that both had issues that made real-world adoption non-trivial
in the best of cases.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)

[COFF] OSI stack

[gtaylor]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

On 2/7/19 12:28 PM, Michael Kjörling wrote:
> While different, I think that the introduction of the more advanced 
> IPv6 address formats into DNS also qualifies. I don't recall off hand if 
> bit-string labels (which were used for reverse lookups) or the A6 RRtype 
> (for forward lookups) was the more problematic one, but I do recall that 
> both had issues that made real-world adoption non-trivial in the best 
> of cases.

Middle boxes that (mis)interpret DNS traffic are still a problem. 
Admittedly less of a problem.  I suspect even less after the DNS Flag 
Day we recently had.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20190207/92250663/attachment.bin>

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

[gtaylor]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4020 bytes --]

It looks like Kevin's response didn't make the COFF mailing list.  So 
I'm including it and my email that it's in response to below.

Kevin, are you subscribed to the COFF mailing list?

On 2/7/19 5:16 PM, Kevin Bowling wrote:
> On Thu, Feb 7, 2019 at 11:08 AM Grant Taylor via TUHS 
> <tuhs at minnie.tuhs.org> wrote:
>> Seeing as how this is diverging from TUHS, I'd encourage replies to the 
>> COFF copy that I'm CCing.
> 
> My thesis was that the specific vector of TCP becoming dominant is "UH"
> 
>> $ReadingList++
> 
> Pick up ISBN-13: 978-0201563511 if you work on transport protos.
> 
>> Would you care to elaborate?
> 
> Only briefly for this list -- certain common devices will intercept 
> TCP streams and cause what are called stretch ACKs from a host because 
> transmission is expensive in some vector -- shared collision domain 
> like the air or a coaxial bus, battery power to key up the radio etc. 
>  This means the sender has to accommodate that behavior and know how to 
> react if it is modeling the connection.

Intriguing.

It seems that the more answers that I get end up resulting in even more 
questions and things I want to learn about.

Thank you Kevin.

>> 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.
> 
> G and Facebook also admit it uses 200% more CPU to do the same 
> throughput.  All for basically avoiding HOL-blocking, which can be 
> worked around in most common scenarios, especially when you control 
> the most popular browser :facepalm:.  Both companies together could 
> pull networking in any direction they want.  I see QUIC as yet another 
> unfortunate direction.

Okay.

>> 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.
>>
>>
>> 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.
> 
> By provider networks I mean tier 1 and 2 and core infrastructure like 
> CDNs.  MPLS is good.  ATM got a couple things right and a lot of 
> things less right.

I think one thing that MPLS, ATM, FR do / did is to transparently carry 
other protocols without modification to their operation.  I think such 
transparency allows them to do things that would be considerably more 
difficult if the switching / routing logic of the transport network was 
trying to interpret network addressing and / or protocol information of 
the payloads they were carrying.

I don't know how flexible MPLS, et al, are without the support of other 
associated protocols.  How well can a MPLS cloud with redundant 
connections find an alternate path if a link goes down.  That's arguably 
something that IP is exceedingly capable of doing, even if it's not the 
most efficient at it.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20190207/2027b4b8/attachment.bin>