Hacker News Reader

Comment by rdtsc | Hacker News Reader

SCTP is sometimes promoted as an alternative to solve that problem. You can have multiple stream per connection so if one blocks the other ones can keep going.

View on HN

Another alternative is minion[0]. The format is TCP on the wire which avoids the NAT problems that SCTP has, but it is able to deliver some really interesting features, including multiple message streams like SCTP.

[0] https://datatracker.ietf.org/doc/search/?name=minion&actived...

Or if SCTP firewall issues are the only thing holding you back you can use RFC 6951; SCTP over UDP.

http://tools.ietf.org/html/rfc6951

My thoughts exactly. Also, you can send some data reliably (e.g., a new character model) and other data unreliably on the the same SCTP association.

SCTP has always looked intriguing to me, but would most backbones and ISPs pass it natively?

It sounds like it would be a waste to tunnel it in UDP, which is the alternative...

WebRTC Data Channels are, in fact, SCTP tunnelled over UDP (or rather, over DTLS over UDP.) They work pretty well.

(I'm not sure how much of the redundancy is shaved off--does anyone know if WebRTC's tries to encapsulate "normative" SCTP, or whether it uses SCTP without checksum/port information?)

Yeah not sure either, good question.

There is also QUIC protocol also by Google, which is yet another crack at solving the problem. Wonder if those 2 groups sat down and discussed merging or re-using code.

The poor prospects for getting widespread SCTP support was one (though not the only) justification the SPDY people cited for doing some similar things at the application-protocol level: http://www.chromium.org/spdy/spdy-whitepaper

Yes they would. The real problem is your home router/gateway/modem will not - and you're normally behind a NAT, which in all likelyhood does not know anything about SCTP (SCTP also isn't very NAT friendly).

Sctp only breaks if the ISP or user has turned on NAT. A router wouldn't break it. NAT does bad things to IP (breaks the fundamental guarantees).

>Sctp only breaks if the ISP or user has turned on NAT.

This describes 95%+ of home users. NAT may do bad things to IP, but if you are an app developer that depends on no NAT, you're product is going to have a very limited market of people that can use it.

IPv6!

NAT isn't going away with IPv6.

IPv4 NAT is not, but you can sidestep it by using IPv6. Look at eg how XBox One is doing it.

Or are you predicting the rise of IPv6 NAT?

What is Xbox One doing?

They are tunneling IPv6 over Teredo if native IPv6 is unavailable. They provide their own relay servers for people who have NAT traversal incapable connectivity.

Teredo is a Microsoft-developed (but IETF-standadized) NAT-traversing IPv6-over-IPv4 tunneling method.

http://www.internetsociety.org/deploy360/blog/2013/10/micros...

http://www.ietf.org/proceedings/88/slides/slides-88-v6ops-0....

An ISP employee here. We did nothing particular to support SCTP, so I got curious whenever it works. Just ran a pair of socat's (sctp-listen:12345 and sctp:example.org:12345) and it worked perfectly.

In our setup, NAT's done on a GNU/Linux machines in a simplest possible way, almost like `iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth1 -j MASQUERADE` (we offer dynamic globally-routeable IPv4 addresses first, but when our pools are drained, we have no choice but do NAT for v4). So, it seems, almost every ISP who uses software routers (they're stable, performant and cheap) should be SCTP-friendly.

No idea about Ciscos and alikes, though. None we have does NAT, and given I'm not a Cisco guy I'm not going to reconfigure one just to test things.

Most cheap home routers are Linux-based, so the adoption plan seems trivial.

Linus should just make STCP NAT support the default with a comment "router manufacturers - please don't disable", so the next time router vendors update their kernels, it gets built into.

Then just wait for 3-4 years.

Look how long it's taking IPv6 support in consumer NAT boxes, and that's something that's hyped and all vendors are officialy drumming for it, and has been finished spec-wise since the 90s.

SCTP has had 14+ years - SCTP made standards track in 2000 (rfc2960) and was in use before that. Chicken and egg.

This is why NAT is bad. It's has introduced a systemic freeze in the Internet, breaking the inert router/smart host model that used to enable deployment of new protocols.

IPv6 is complicated matter. Even if kernel has ipv6 module/support built in, it's still a very tiny first step for router to support IPv6.

On the other hand, STCP NAT support is just one kernel config option away and no further configuration's needed. A complete no-brainer - just persuade those building routers' firmware to not tick it off.

Backbones and most ISPs are gonna route IP packets regardless of content. Until you hit a NAT or firewall and everything that's not UDP or TCP gets dropped.

Or just open multiple TCP streams (that means of course multiple TCP connections) and waste resources on additional TCP state tracking and additional recieve/send buffer allocations, etc.

Reply on news.ycombinator.com