Live data from Hacker News

Internet protocols are changing

blog.apnic.net

111–120 of 138 posts

Re: Internet protocols are changing

#111
post #80

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?

> Why do the routers involve themselves at the transport layer? Can't they just route IP packets and leave the transport alone?

Because they have to do NAT, at least on IPv4.

> 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?

Because the connection tracking that's needed to even recognize whether a packets belongs to an outbound or an inbound connection needs to understand the protocol.

Re: Internet protocols are changing

#113
post #75
post #54

Earlier quoted context omitted.

Do these specific changes from Google impact negatively the community? Otherwise, IMHO good ideas, are good ideas regardless where they come from.

Yes, generally they're some combination of overly complicated technically, difficult to use without layers and layers of heavy dependencies, are poorly thought out, or solve Google-specific use cases.

Well, the complexity is a problem, but I don't really see that as Google's fault. The only chance to evolve the network is by building on stuff that works despite all the hostile middle boxes, and that necessarily requires quite a bit of complexity, unfortunately. In the long term, it seems to me like QUIC is a better idea than everyone individually having to work around idiocies all over the internet, as that is not exactly a zero-complexity game either.

Re: Internet protocols are changing

#114
post #110
post #97

Earlier quoted context omitted.

I would also like to see SRV record support in HTTP/2 but IIRC Mozilla did some telemetry tests and found out that a significant amount of DNS requests for SRV records failed for no reason (or probably for reasons mentioned in this submission). Unfortunately I can't find a source link for that claim right now.

I know of two rather large users of SRV records already: Minecraft servers and (the big one) Microsoft Office 365. I’m less than convinced that resolution of SRV records is that broken.

Do you mean accessing Office 365 via browser uses SRV records or something different?

Re: Internet protocols are changing

#115
post #95

Earlier quoted context omitted.

Why was that dumb of SCTP? What should it have done instead?

Used a UDP port. Making new IP protocols is literally what UDP is for.

Other than getting through broken routers, what's the advantage of building a protocol on top of UDP rather than IP?

("Getting through broken routers" is certainly a significant advantage; I'm just asking if that's the only good reason to not build directly on IP.)

Re: Internet protocols are changing

#116
post #110

Earlier quoted context omitted.

I know of two rather large users of SRV records already: Minecraft servers and (the big one) Microsoft Office 365. I’m less than convinced that resolution of SRV records is that broken.

Do you mean accessing Office 365 via browser uses SRV records or something different?

o365 general services (lync skype, outlook, ... / exchange autodiscover) uses SRV a fair bit.

365 is not just the browser suite

Re: Internet protocols are changing

#117

Earlier quoted context omitted.

Used a UDP port. Making new IP protocols is literally what UDP is for.

Other than getting through broken routers, what's the advantage of building a protocol on top of UDP rather than IP? ("Getting through broken routers" is certainly a significant advantage; I'm just asking if that's the only good reason to not build directly on IP.)

The only "advantage" to declaring an IP protocol is that you might save 8 bytes and a trivial checksum. Mostly, though, declaring an IP protocol is a vanity decision.

Re: Internet protocols are changing

#118

Earlier quoted context omitted.

Other than getting through broken routers, what's the advantage of building a protocol on top of UDP rather than IP? ("Getting through broken routers" is certainly a significant advantage; I'm just asking if that's the only good reason to not build directly on IP.)

The only "advantage" to declaring an IP protocol is that you might save 8 bytes and a trivial checksum. Mostly, though, declaring an IP protocol is a vanity decision.

I'm wondering the reverse: what's the advantage to building on UDP, other than passing routers that for some reason are inclined to pass UDP but reject IP protocols they don't know? You said that this was "what UDP was for", and I was hoping for some more detail there on why UDP helps. As you said, it's just 8 bytes and a trivial checksum.

Re: Internet protocols are changing

#119

Earlier quoted context omitted.

The only "advantage" to declaring an IP protocol is that you might save 8 bytes and a trivial checksum. Mostly, though, declaring an IP protocol is a vanity decision.

I'm wondering the reverse: what's the advantage to building on UDP, other than passing routers that for some reason are inclined to pass UDP but reject IP protocols they don't know? You said that this was "what UDP was for", and I was hoping for some more detail there on why UDP helps. As you said, it's just 8 bytes and a trivial checksum.

The advantage to building on UDP is that it gets through (some) middleboxes; that's what the 4 bytes of port numbers buys you. That, and the fact that UDP is designed to be the TCP/IP escape hatch for things like SCTP that don't want TCP's stream and congestion control semantics.

Re: Internet protocols are changing

#120
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…

Do not think it is Google fault they run so much of the Internet and also have most browser and mobile phone share.

Google using the standards process to release new things is exactly what we should want and see. You make it like it is some nefarious behavior. Geeze.

Google has offered things for standards which were changed by the standards group and Google adopted the change.

Google could just keep it all closed if they want. Honestly wonder if they will not in the future with posts like yours. Why do it?

Post reply on HN