5 ms·

Notice these classic technologies. They’re SIMPLE. That got lost in later development up the stack.

by dpweb 5y ago

naikrovek 5y ago
I don't think I would describe TCP/IP as "simple". there are parts of the spec that contradict each other! it's impossible to implement fully.
- netr0ute 5y ago
  The layer system used by TCP/IP (layer 2 -> 3 -> 4) makes it "simpler" because everything can be compartmentalized without worrying because it was designed to be that way. The real problem comes when you use TCP/UDP for higher level protocols and that's where the real difficulty is.
  - tptacek 5y ago
    There's really no such system. In TCP/IP, we refer to "layer 3" and "layer 4" protocols, in reference to OSI, but TCP/IP isn't an OSI protocol, the lines between L2 and L3 are blurred by things like ARP and DHCP (or completely eliminated in overlay networks and multicast), and none of the rest of the layers are even informally specified for TCP/IP. If all you're saying is that TCP/IP has, among its many goals, a separation of concerns, sure. But most major systems designs have separations of concerns.
    - omegalulw 5y ago
      The fundamental problem is that once your break/compartmentalize into layers it's harder apply global optimizations at local layers. You are trading off ease of implementation and compositionality for performance. You have to bubble up optimizations up the stack. This is partly why QUIC is based on UDP instead TCP. You don't have all the information needed at the TCP layer to do the kind of optimizations that QUIC does.
      - throwawaaarrgh 5y ago
        This lack of "global optimization" I think is something that should be solved by a new protocol stack. (If it could be done without replacing the whole stack i'd be in favor of it, but I have no idea how) Say you have a backend tcp http REST app that takes requests to modify a widget. To receive the request, the payload will pass over a series of networks and protocols, all with potentially different restrictions and modifications, until it gets to a load balancer, and then maybe a service mesh router, to a network service listening on the node of some container orchestrator, and finally read by the backend app. All of the layers will have been replaced numerous times, and possibly the actual data payload modified. But the only thing your backend app knows is the final state. And then, somewhere along the way, there is an error. It could have happened anywhere along the chain, for who knows why. But you and the app server won't know when or where or why the error happened because none of the information about the changing layers (or network operations along the way) is carried along. If the entire stack were not actually a stack, but instead a kind of commit log of transactions and instructions, we could see every single step in a transaction (ideally verified by cryptographic checksum). This would make it faster to diagnose problems and allow automation to work around known issues - in addition to making it harder for attackers to mess with traffic. In the simplest examples it would look like a stack, but for more complex paths it would look like a log. We could also potentially use this method to do away with service meshes.
        zdragnar 5y ago
        Sounds a bit to me like that would necessitate describing your internal network to every outside server or client it trades requests with, unless your routers become much more sophisticated. I cannot imagine that would ever be acceptable for most companies.
- l33t2328 5y ago
  Can you elaborate?
eatonphil 5y ago
Ethernet and IP are simple. But TCP is super complex to me with all the state management and buffers and sliding windows. It works well but I find it terribly daunting to dig into (I've tried a few times, and still aim to succeed sometime).
- renox 5y ago
  Ethernet was simple, with VLAN.. it isn't so simple anymore..
  - eatonphil 5y ago
    I mean ethernet, the protocol. It just wraps packets with some headers and a checksum. Are you saying it gets more complex than that? (I haven't dug into ethernet much more deeply than I describe).
billforsternz 5y ago
Yes. I found it was quite possible to code up TCP/IP from scratch for my own tiny (arguably toy) bare metal environment here https://github.com/billforsternz/bmz https://github.com/billforsternz/bmz

Notice these classic technologies. They’re SIMPLE. That got lost in later development up the stack.

by dpweb 5y ago

Notice these classic technologies. They’re SIMPLE. That got lost in later development up the stack.

I don't think I would describe TCP/IP as "simple". there are parts of the spec that contradict each other! it's impossible to implement fully.

netr0ute 5y ago
The layer system used by TCP/IP (layer 2 -> 3 -> 4) makes it "simpler" because everything can be compartmentalized without worrying because it was designed to be that way. The real problem comes when you use TCP/UDP for higher level protocols and that's where the real difficulty is.
- tptacek 5y ago
  There's really no such system. In TCP/IP, we refer to "layer 3" and "layer 4" protocols, in reference to OSI, but TCP/IP isn't an OSI protocol, the lines between L2 and L3 are blurred by things like ARP and DHCP (or completely eliminated in overlay networks and multicast), and none of the rest of the layers are even informally specified for TCP/IP. If all you're saying is that TCP/IP has, among its many goals, a separation of concerns, sure. But most major systems designs have separations of concerns.
  - omegalulw 5y ago
    The fundamental problem is that once your break/compartmentalize into layers it's harder apply global optimizations at local layers. You are trading off ease of implementation and compositionality for performance. You have to bubble up optimizations up the stack. This is partly why QUIC is based on UDP instead TCP. You don't have all the information needed at the TCP layer to do the kind of optimizations that QUIC does.
    - throwawaaarrgh 5y ago
      This lack of "global optimization" I think is something that should be solved by a new protocol stack. (If it could be done without replacing the whole stack i'd be in favor of it, but I have no idea how) Say you have a backend tcp http REST app that takes requests to modify a widget. To receive the request, the payload will pass over a series of networks and protocols, all with potentially different restrictions and modifications, until it gets to a load balancer, and then maybe a service mesh router, to a network service listening on the node of some container orchestrator, and finally read by the backend app. All of the layers will have been replaced numerous times, and possibly the actual data payload modified. But the only thing your backend app knows is the final state. And then, somewhere along the way, there is an error. It could have happened anywhere along the chain, for who knows why. But you and the app server won't know when or where or why the error happened because none of the information about the changing layers (or network operations along the way) is carried along. If the entire stack were not actually a stack, but instead a kind of commit log of transactions and instructions, we could see every single step in a transaction (ideally verified by cryptographic checksum). This would make it faster to diagnose problems and allow automation to work around known issues - in addition to making it harder for attackers to mess with traffic. In the simplest examples it would look like a stack, but for more complex paths it would look like a log. We could also potentially use this method to do away with service meshes.
      - zdragnar 5y ago
        Sounds a bit to me like that would necessitate describing your internal network to every outside server or client it trades requests with, unless your routers become much more sophisticated. I cannot imagine that would ever be acceptable for most companies.
l33t2328 5y ago
Can you elaborate?

eatonphil 5y ago

Ethernet and IP are simple. But TCP is super complex to me with all the state management and buffers and sliding windows. It works well but I find it terribly daunting to dig into (I've tried a few times, and still aim to succeed sometime).

renox 5y ago
Ethernet was simple, with VLAN.. it isn't so simple anymore..
- eatonphil 5y ago
  I mean ethernet, the protocol. It just wraps packets with some headers and a checksum. Are you saying it gets more complex than that? (I haven't dug into ethernet much more deeply than I describe).

billforsternz 5y ago

Yes. I found it was quite possible to code up TCP/IP from scratch for my own tiny (arguably toy) bare metal environment here https://github.com/billforsternz/bmz https://github.com/billforsternz/bmz