Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Internet protocols are changing

blog.apnic.net

Post reply on HN
Print view View original

81–90 of 138 posts

Re: Internet protocols are changing

#81

Post by himom »

jandrese wrote: post #3

> When a protocol can’t evolve because deployments ‘freeze’ its extensibility points, we say it has ossified. TCP itself is a severe example of ossification; so many middleboxes do so many things to TCP — whether it’s blocking packets with TCP options that aren’t recognized, or ‘optimizing’ congestion control. > It’s necessary to prevent ossification, to ensure that protocols can evolve to meet the needs of the Inter…

There’s little real impetus to change widely-used protocols. Job security, product/support sales and developer “consumerism” novelty aren’t valid reasons, but often get pushed with spurious “reasons” to fulfill agendas, despite their cost.

The only demonstrable needs are bugfixes and significant advances because inventing and imposing complexity in all implementations or damaging backwards compatibility are insanely costly in terms of retooling, redeployment, customer interruptions, advertising, learning curve, interop bugs and attack surfaces.

Re: Internet protocols are changing

#82

Post by cjhanks »

jandrese wrote: post #3

> When a protocol can’t evolve because deployments ‘freeze’ its extensibility points, we say it has ossified. TCP itself is a severe example of ossification; so many middleboxes do so many things to TCP — whether it’s blocking packets with TCP options that aren’t recognized, or ‘optimizing’ congestion control. > It’s necessary to prevent ossification, to ensure that protocols can evolve to meet the needs of the Inter…

I significantly benefit from QUIC. My home network is exceptionally lossy... and exceptionally latent. ICMP pings range from 500ms (at best) to 10 seconds (at worst) with an average somewhere in the 1-2 second range. Additionally I am QOS-ed by some intermediary routers which appear to have a really bad (or busy) packet scheduler.

Often, Google sites serving via QUIC are the only sites I can load. I can load HTML5 YouTube videos despite not being able to open the linkedin.com homepage. Stability for loading HTTP over QUIC in my experience is very comparable to loading HTTP over OpenVPN (using UDP) with a larger buffer.

Re: Internet protocols are changing

#83

Post by 0xcde4c3db »

nfoz wrote: post #80
dragontamer wrote: post #8

Earlier quoted context omitted.

SCTP is a superior protocol, but it isn't implemented in many routers or firewalls. As long as Comcast / Verizon routers don't support it, no one will use it. It may be built on top of IP, but TCP / UDP levels are important for NAT and such. Too few people use DMZ and other features of routers / firewalls. Its way easier to just put up with TCP / UDP issues to stay compatible with most home setups.

Why do the routers involve themselves at the transport layer? Can't they just route IP packets and leave the transport alone? Firewalls -- whose firewalls are we talking about here? If a client (say, home user) tries to initiate an SCTP connection to a server somewhere, what step will fail?

I haven't tried it and am not terribly familiar with SCTP, but from skimming a few references I suspect it would fail when the NAT logic decides it's never heard of protocol number 132 and drops the incoming INIT_ACK on the floor.

Re: Internet protocols are changing

#84

Post by adrianmonk »

jandrese wrote: post #3

> When a protocol can’t evolve because deployments ‘freeze’ its extensibility points, we say it has ossified. TCP itself is a severe example of ossification; so many middleboxes do so many things to TCP — whether it’s blocking packets with TCP options that aren’t recognized, or ‘optimizing’ congestion control. > It’s necessary to prevent ossification, to ensure that protocols can evolve to meet the needs of the Inter…

To what extent are the TCP problems you can solve by tweaking manually with a proxy the same problems that QUIC solves automatically? If there's a big overlap, it may not be a real problem.

For example, you mention latency, but QUIC is supposed to remove unnecessary ordering constraints, which could eliminate round trips and help with latency.

Re: Internet protocols are changing

#85

Post by inimino »

norin wrote: post #77
jlgaddis wrote: post #56

Earlier quoted context omitted.

Nah, many of them can't -- won't -- block Google over this. A huge number of them are absolutely reliant on Google, for things like (org-wide) Google Mail, Google Docs, ChromeBook deployments, and so on -- not to mention basic Google search.

What about China or the EU? They can surely block Google?

China has, for many years. The EU is unlikely to.

Re: Internet protocols are changing

#86

Post by discoursism »

taavi013 wrote: post #68
ohazi wrote: post #52

Earlier quoted context omitted.

While everything you state here is correct, and is clearly of serious concern, my view is that the general public doesn't really have the capacity to fight both of these battles at once. Right now, I'm convinced we need Google's help to make it harder for governments and ISPs to censor and prioritize. After that, we'll deal with Google.

As of today Google with it's BBR + QUIC + Chrome combo and Facebook with their Zero protocol, combined with their extensive data center network can get much better end user experience than any other service provider regardless of any government. We can talk about network neutrality whatever we want - but these companies have built technological capabilities to have "little bit bigger share". So, probably after some t…

> As of today Google with it's BBR + QUIC + Chrome combo and Facebook with their Zero protocol, combined with their extensive data center network can get much better end user experience than any other service provider regardless of any government.

What is your preferred course here? Google has provided free as in freedom source code for all of the above, and in some cases pushed the code upstream. Granted, it will take small players longer to see the benefits of these techs, since they can't afford to integrate it themselves and must wait for vendors to include it. But small players usually have worse user experience regardless of the mechanism. Proposed standards are just one way that happens.

Re: Internet protocols are changing

#88

Post by rtpg »

ocdtrekkie wrote: post #34
jjrh wrote: post #15

Earlier quoted context omitted.

Not sure who "The powers that be" are, but anyone can propose and contribute to IETF standards. They are called "Request for Comment" for a reason.

Almost positively that answer is Google. Notice they are behind multiple of the new protocols here (HTTP/2 and QUIC), and are used as an example how bundling DOH with an existing major player can prevent blocking DNS. Google is effectively the actual determiner of Internet standards. As the article notes, Google implemented QUIC on their servers and their browsers, and therefore, 7% of Internet traffic is already QUI…

For sure the "we've implemented this in Chrome already" aspect is a huge aspect in the standards process.

I do think it's important to say that this isn't a sure-fire deal. We had stuff like NaCl (native code in the browser) that basically died off, and other options as well.

Inversely, SPDY is not what the standard is, and Google instead pulled stuff it learned into HTTP/2. This seems like a positive aspect to me.

It's important to be wary of things that Google won't bring up, but overall I feel like we're getting a lot of benefit from having an implementer "beta test" stuff in this way.

Re: Internet protocols are changing

#89

Post by xxpor »

tptacek wrote: post #50
xxpor wrote: post #31

Earlier quoted context omitted.

You can tunnel SCTP on top of UDP. Port 9899. https://www.ietf.org/proceedings/48/I-D/sigtran-sctptunnel-0...

This is an improvement --- it was dumb of SCTP to try to claim a top-level IP protocol for this --- but only marginally, since lots of firewalls won't pass traffic on random UDP ports either.

Very true. I'd of course run tests, but I would guess port 80 would work these days because of QUIC. Even port 53 is probably locked down to whitelisted hosts.
Post reply on HN