4 ms·

Good luck getting everybody to upgrade their kernel to support your new transport protocol. Realistically, UDP and TCP are what we have. We may wish they were m

by necubi 12y ago

Good luck getting everybody to upgrade their kernel to support your new transport protocol. Realistically, UDP and TCP are what we have. We may wish they were more suited to modern use cases, but realistically we must build on those foundations. If that means violating "layering" for performance, so be it.

testrun 12y ago
I think he/she is not talking about the transport protocol (TCP/UDP), but the higher up layers (5 - 7) cramming functionality from the lower layers. Might be reading it the wrong way.
- detaro 12y ago
  They only try to cram functionality from lower levels into higher ones because establishing new lower ones is nearly impossible. SCTP (or variants of it) would implement a lot that is now build on higher levels, but there is a reason it's only used in private networks.
  - Chlorus 12y ago
    No kidding, take a look at the presentation[0] for multipath TCP - and that was a relatively 'simple' transport layer modification. Look at slide #30 for a glimpse into the madness caused by crappy middleboxes. [0]http://multipath-tcp.org/data/MultipathTCP-netsys.pdf http://multipath-tcp.org/data/MultipathTCP-netsys.pdf
    - xorcist 12y ago
      The alternative is to layer something over HTTP. That's may be even worse. There are no simple ways to upgrade global infrastructure.
serge2k 12y ago
Maybe instead of the "good luck" attitude we should start pushing an "upgrade or suffer" attitude. Seems far more reasonable than letting things stagnate for years. It's what chrome is doing with sha1 certs. Give a timeframe, if you don't get your upgrade in then too bad.
- billyhoffman 12y ago
  > Maybe instead of the "good luck" attitude we should start pushing an "upgrade or suffer" attitude. "Upgrade or suffer" rarely works in practice. Rendering (or rather the lack of rendering) malformed XHTML is a great example of this
- mobiplayer 12y ago
  Google can push that because there's a huge user base with Chrome and you don't want your shiny ecommerce site to be marked as not safe by Chrome, do you? On the other hand, the packets moved through the wires to send this comment to HN and the ones moved to send this comment to your computer are easily managed by dozens of different people and a handful of different companies with different agendas, budgets, needs and even skills. Cisco definitely manufactured and sold most of the devices out there, but they surely don't manage them or decide when they're upgraded. It gets worse, because actually there's not only Cisco out there. I'm not saying it can't be done, but just look at the slow IPv6 adoption, despite the efforts of all the big players (Google, Cisco, Juniper, Microsoft, Linux, ... !) supporting it in a timely manner, it's still not there.
  - gsnedders 12y ago
    Also remember that everything Google has ever pushed through has been above UDP/TCP, because it's far easier to push through changes on top of that than not. There's a reason why QUIC is being developed on top of UDP instead of as a transport layer in its own right.

by necubi 12y ago

testrun 12y ago

I think he/she is not talking about the transport protocol (TCP/UDP), but the higher up layers (5 - 7) cramming functionality from the lower layers. Might be reading it the wrong way.

detaro 12y ago
They only try to cram functionality from lower levels into higher ones because establishing new lower ones is nearly impossible. SCTP (or variants of it) would implement a lot that is now build on higher levels, but there is a reason it's only used in private networks.
- Chlorus 12y ago
  No kidding, take a look at the presentation[0] for multipath TCP - and that was a relatively 'simple' transport layer modification. Look at slide #30 for a glimpse into the madness caused by crappy middleboxes. [0]http://multipath-tcp.org/data/MultipathTCP-netsys.pdf http://multipath-tcp.org/data/MultipathTCP-netsys.pdf
  - xorcist 12y ago
    The alternative is to layer something over HTTP. That's may be even worse. There are no simple ways to upgrade global infrastructure.

serge2k 12y ago

Maybe instead of the "good luck" attitude we should start pushing an "upgrade or suffer" attitude. Seems far more reasonable than letting things stagnate for years. It's what chrome is doing with sha1 certs. Give a timeframe, if you don't get your upgrade in then too bad.

billyhoffman 12y ago
> Maybe instead of the "good luck" attitude we should start pushing an "upgrade or suffer" attitude. "Upgrade or suffer" rarely works in practice. Rendering (or rather the lack of rendering) malformed XHTML is a great example of this
mobiplayer 12y ago
Google can push that because there's a huge user base with Chrome and you don't want your shiny ecommerce site to be marked as not safe by Chrome, do you? On the other hand, the packets moved through the wires to send this comment to HN and the ones moved to send this comment to your computer are easily managed by dozens of different people and a handful of different companies with different agendas, budgets, needs and even skills. Cisco definitely manufactured and sold most of the devices out there, but they surely don't manage them or decide when they're upgraded. It gets worse, because actually there's not only Cisco out there. I'm not saying it can't be done, but just look at the slow IPv6 adoption, despite the efforts of all the big players (Google, Cisco, Juniper, Microsoft, Linux, ... !) supporting it in a timely manner, it's still not there.
- gsnedders 12y ago
  Also remember that everything Google has ever pushed through has been above UDP/TCP, because it's far easier to push through changes on top of that than not. There's a reason why QUIC is being developed on top of UDP instead of as a transport layer in its own right.