Hacker News new | past | comments | ask | show | jobs | submit login

> 8.4.6. “It has layering violations”

> Seriously, that's your argument? Layers are not holy untouchable pillars of a global religion

If layers aren't 'untouchable pillars', then why have we not fixed the ones we have? IPSec, IP, TCP and TLS are all a jumbled rotten mess. Poor layering has resulted in a lot of warts like inefficient or underleveraged handshakes and the lack of things like mobility, multi-homing, authentication, reliable datagrams and stream multiplexing. What is really being said here is yes, the layers we have (TCP, NAT) really are untouchable pillars.

Cramming workarounds in to a higher, application-specific, layers doesn't benefit the wider Internet.




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.


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.


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.


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.


> 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


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.


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.


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


The alternative is to layer something over HTTP. That's may be even worse. There are no simple ways to upgrade global infrastructure.


otoh - http on sctp on ipv6 with ipsec hasn't really moved the internet forward.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: