8 Feb
2019
8 Feb
'19
3:43 a.m.
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:
Okay.
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
On Thu, Feb 7, 2019 at 11:08 AM Grant Taylor via TUHS
<tuhs(a)minnie.tuhs.org> wrote:
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.
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. 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. 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.