From mboxrd@z Thu Jan 1 00:00:00 1970 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 7 Feb 2019 20:43:27 -0700 Subject: [COFF] [TUHS] OSI stack (Was: Posters) In-Reply-To: References: <20190206174913.E518318C07B@mercury.lcs.mit.edu> <0572e855-9aac-337f-4f1b-66dda3839e14@spamtrap.tnetconsulting.net> Message-ID: <741f24ad-9b26-4620-b51c-3c7d0839a57c@spamtrap.tnetconsulting.net> 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 > 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: