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

8 Feb 2019

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

 &lt;tuhs(a)minnie.tuhs.org&gt; 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