41–50 of 64 posts
Earlier quoted context omitted.
> On the backbone nothing uses TCP, not even IP. It's all BGP or other proprietary formats. BGP is not a protocol for moving data - it's a way to find the path to deliver IP packets. Nor is it proprietary :/
Sure, but I'm pretty sure the fiber cables under the oceans are not running vanilla IP/TCP/UDP.
These kind of articles are made by ignoramuses that don't understand that TCP is an edge protocol and those profit from ossification because it allows the backbone to evolve without everyone re-implementing everything over and over again at the edges! Over-engineering and technical debt is a bi-product of: “It is difficult to get a man to understand something, when his salary depends upon his not understanding it!” -…
.... BGP runs over TCP.
> TCP and HTTP/1.1 are the final protocols for the human race in this universe
Right, QUIC is only used by all things Google.
Let's start with the fact that TCP obviously has problems. People who wrote the protocol did not expect for it to live that long. At the time the life expectancy of any standard was pretty short. But... before you get too caught up with bashing... if I were you I would spend just a tiny bit trying to really understand why we are in this situation. It might be because it is "just enough" to build upon. You are free to…
Earlier quoted context omitted.
> On the backbone nothing uses TCP, not even IP. It's all BGP or other proprietary formats. BGP is not a protocol for moving data - it's a way to find the path to deliver IP packets. Nor is it proprietary :/
Sure, but I'm pretty sure the fiber cables under the oceans are not running vanilla IP/TCP/UDP.
Standardized protocols are important to a network which must rely on multiple router vendors.
Earlier quoted context omitted.
> On the backbone nothing uses TCP, not even IP. It's all BGP or other proprietary formats. BGP is not a protocol for moving data - it's a way to find the path to deliver IP packets. Nor is it proprietary :/
Sure, but I'm pretty sure the fiber cables under the oceans are not running vanilla IP/TCP/UDP.
You could easily say that your home network “doesn’t run vanilla IP/TCP/UDP” since it’s actually running 1000BASE-T, or Ethernet.
What you do is take your IP packets and shove them into ethernet frames when you send them across your local network. Your modem will pull the IP packets out from the ethernet frame, and send them out to the internet inside something else like PPP or a different ethernet network. We call this vanilla IP/TCP/UDP, running on top of ethernet.
Submarine fiber optic cables are the same. It’s still vanilla IP/TCP/UDP.
Earlier quoted context omitted.
That, again, is static view. Game-theory view is that any organization that would like to push this would have to spend enormous amount of resources to reinvent almost anything that has anything to do with TCP. Remember, it is implemented in hardware in many different types of devices, stacks, applications, it permeates almost anything. The application I am working on right now which has lived for over a decade and w…
It sounds like you are evaluating the idea that protocol X will replace TCP, but I don’t think anyone is making that argument. Protocol X would be used alongside TCP, and you wouldn’t be able to use protocol X in all networks. This is already the world we live in.
Earlier quoted context omitted.
> On the backbone nothing uses TCP, not even IP. It's all BGP or other proprietary formats. BGP is not a protocol for moving data - it's a way to find the path to deliver IP packets. Nor is it proprietary :/
Sure, but I'm pretty sure the fiber cables under the oceans are not running vanilla IP/TCP/UDP.
"Replacing" IP is a bit more likely: large backbones typically run MPLS, which encapsulates IP and provides for a simpler label-based switching process that can be more efficient than IP. But IP isn't replaced: it's merely wrapped in something more efficient in this case. It's like a company sending mail from one office to another over its internal post instead of routing every individual letter through the public mail system.
The point of having different layers of the network stack is so that each layer has its own responsibilities that are largely separated from the other layers. As long as IP A wants to send IP B something over TCP those cables will be carrying IP and TCP over whatever protocol they run underneath.
TCP pretty obviously doesn’t suck as it’s pretty much powered the internet for the last 30ish (maybe more) years. I’m sure it isn’t perfect for every purpose and maybe I can be improved but enough with the click bait.
Complaining about the article’s title is no substitute for replying to the article’s content. Writing a provocative title is how you get people to read your article. If you have an opinion to share, you shouldn’t try to disguise it as a drab technical report. The article makes sound points and the title makes sense. Compare “TCP Sucks” (easy to read—communicates, concisely, that this is an opinion piece, and what the…
(Also, if you're designing a communications system, don't give it the same name as another communications system.)
TCP has its limitations, of course. It was designed to work over a wide range of connections, including dial-up, and it does. It's suboptimal for broadband server to client connections where big server farms from a small number of vendors dominate. Hence QUIC and HTTP/2/3. Still, those don't provide a huge improvement in performance.[1] Even Google merely claims "on average, QUIC reduces Google search latency by 8% and 3.5% for desktop and mobile users respectively, and reduces video rebuffer time by 18% for desktop and 15.3% for mobile users." That's marginal. An ad blocker probably has more effect.
The author is worried about the overhead of the three-way handshake, but the overhead of setting up TLS is far worse.
[1] https://conferences.sigcomm.org/imc/2017/papers/imc17-final3...
Earlier quoted context omitted.
Complaining about the article’s title is no substitute for replying to the article’s content. Writing a provocative title is how you get people to read your article. If you have an opinion to share, you shouldn’t try to disguise it as a drab technical report. The article makes sound points and the title makes sense. Compare “TCP Sucks” (easy to read—communicates, concisely, that this is an opinion piece, and what the…
The author says "TCP sucks", and is promoting his own protocol. Iridium. Which he hasn't even designed yet . That's a bit much. We don't get to criticize his approach. (Also, if you're designing a communications system, don't give it the same name as another communications system.) TCP has its limitations, of course. It was designed to work over a wide range of connections, including dial-up, and it does. It's subopt…
Well that won't be confusing at all:
* https://en.wikipedia.org/wiki/Iridium_satellite_constellatio...