3 ms·

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 b

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.

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.