Comment by Aloisius | Hacker News Reader

Comment by Aloisius | Hacker News Reader

Oh wonderful, it appears to use SPDY-like header compression. Why don't we just create a new compression algorithm and predefine common HTML tags and words to improve compression of the response body too! But we shouldn't base it on any known compression scheme and only use it for the case where the content length is less than 220,498 bytes but more than 8,494 bytes to optimize the behavior of today's more common MTU settings for PPPoE in Scandinavian countries minus of course the most common size of compressed headers today. It will be particularly optimized for the kind of responses Google sends back to minimize their own server load and common adwords will of course be included in the predefined list of compressed tokens.

/sarcasm

What happened to simple protocols? Seriously, per-hop flow control (which works best with which of the dozen version of TCPv4 or TCPv6 flow control?)? TCPv4-like framing with weird limits (16383 bytes)? Keepalives/Ping? Truly ridiculous specialized compression for headers which ignores the role of HTTP proxies? QoS?

Why not just implement the whole protocol over a raw IP connection and stop pretending like we're operating in layer 4+? I get that multiplexing is difficult without flow control, but good lord does this thing look overdesigned for what few benefits it offers over HTTP/1.1.

Well, we had a nice thing for a while, and now it's time to fuck that all up. The wheel turns.

Look on the bright side--if everyone decides the public Internet is too insecure, maybe we can convince them to keep using the old standards on darknets?

Recapitulating a comment from downthread, but, look at DNS for an example of how the IETF botches compression in its "simple" protocols. Not that compression isn't fraught (look at TLS), but I see its use as a sign of maturity.

"What happened to simple protocols?"

Answer: The Internet is still running on them, 30 years later.

Whenever I read something like "simplicity is hard", it makes me cringe. I hear that a lot, and I see evidence of gratuitous complexity everywhere I look these days. I'd hazard a guess the engineers behind SDPY would find simplicity (and reliability) boring.

Debugging binary protocols is either great job security for over eager engineers like the SPDY team or a great waste of our collective time. I'll let you all decide which.

I can't help thinking some of the pain could be resolved if we had a reliable datagram protocol between UDP and TCP. Delimiting a TCP stream to create a messaging protocol is already suboptimal and error prone, and it's the root cause of the head-of-line blocking problem experienced by HTTP ('fixed' in SPDY).

You mean like SCTP ? It's struggling to get traction.

Yes, because MS haven't implemented it.

It wouldn't get through any home firewalls either. Adoption would take decades...

Something like QUIC? I reckon a few of the authors of this draft is also involved in QUIC.

http://blog.chromium.org/2013/06/experimenting-with-quic.htm...

There can be no new layer 4 protocols due to NAT. You have to use either TCP or UDP.

So instead of doing things properly, we'll hack around it... Isn't that what we're all complaining about?

Let's do it right and then fix NAT

So we can move from IPv4 to IPv6 but not introduce a new transport because of NAT? Hmm...

The IPv6 transition is not going that much better than SCTP. So many people have v4-only home routers that they have no plans to ever upgrade.

Most people have a free router from their ISP, the ISP will just send out new ones

My ISPs modem has a built in NAT that can't be disabled, but it still passes all IPv4 packets through in DMZ mode, so there's hope.

Erm, reliable UDP?

You can get a startling amount of the way there with sequence numbers and a few other things--it's a fun exercise.

SCTP is more modern and still under active development. RUDP only has a draft RFC and hasn't been updated since 1999.

Oh, no no no, you misunderstand--spend an afternoon to implement a reliable communication layer over UDP yourself. I don't suggest another standard (or a defunct one): roll your own.

Reply on news.ycombinator.com