Hacker News Reader

Comment by RUBwkVjwLsDKgPw | Hacker News Reader

As someone who works in the application layer, the recommendation to have a fast failover to tcp from udp seems silly. Shouldn't the recommendation be to keep packet sizes below 1280?

View on HN

Oh, whatever happened to SCTP?

The reality that to much stuff in networks (mostly firewalls, NAT and other middleboxes like that) only understands the basics (TCP, UDP, random bits of ICMP) and drops SCTP. You can do SCTP over UDP, or use it in networks you can control and fix, but not reliably as-is over random internet connections. So we now have HTTP2 and other protocols now reinvent parallel streams instead of swapping to SCTP, but that's how it is.

SCTP is alive and vell in very niche applications. SIGTRAN [1] for example is an adaptation of middle layers of SS7 network stack that runs on top of SCTP/IP.

[1] https://en.wikipedia.org/wiki/SIGTRAN

> the recommendation to have a fast failover to tcp from udp seems silly

it does, in some ways. I imagine if you're using UDP you have a specific application in mind that may not be performant over TCP... otherwise why not just use TCP by default?

Well there are often times where you may need to send more data than fits in a 1280 packet, so what do you do then? Ans: cut over to TCP.

Send more than one packet?

But then you need to design a system to make sure all the packets arrive, including sending missing packets, and that they're processed in the correct order. Or you could use a time-tested off the shelf system to handle this complication: TCP.

Reply on news.ycombinator.com