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

[gtaylor at tnetconsulting.net (Grant Taylor)]

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