Internet > General Internet

SCTP unfriendliness

(1/4) > >>

Weaver:
I am wondering whether or not some domestic CPE or firewalls, or some corporate firewalling policies might hate SCTP traffic and frustrate anyone trying to deploy apps that speak SCTP over the internet?

If desperate, an application developer could always as a last resort simply add a useless UDP header to the SCTP packets and disguise it that way, so that the kit in question won’t have a chance to object. That doesn’t help with crazy corporate or instiutional networks where no internet access is allowed, or maybe only http over TCP through some sort of proxy / gateway or proxy cache.

sevenlayermuddle:
@Weaver,

You’ve mentioned a few times you are a fan of SCTP.

I was distantly involved in SCTP from its beginning in the SIGTRAN working groups. So far as I recall, SCTP was designed to address specific shortfalls of TCP, such that it could provide a robust IP-based framework for carrying telecomms traffic over IP, providing similar reliability to the traditional dedicated TDM signalling links.

I don’t think it was ever intended to be “better than” TCP, rather just an alternative, that was better suited to telecomms applications.  Main differences, as far as I recall, were resilience in terms of multi homing, and failure detection by virtue of ‘heartbeat’ traffic.   It also claimed to address head of line blocking, I’m not sure that lived up to promise.    It certainly did facilitate migration of SS7 telecoms to IP protocols, but I don’t really see how any of that would be relevant to a typical domestic (or even business) dsl connection to public internet?

I have of course forgotten most of what I once knew, and what little I remember is far out of date.  So I’d be interested in understanding your enthusiasm for the protocol? :)

Weaver:
In my view everything about it is better, from the fix to the head-of-line-block problem, delivery of messages not bytes (hallelujah), multiple streams, a much better crc, and the biggest deal is support for multihomed/roaming machines designed in properly, particularly in today’s mobile world, where so very many machines are multihomed because they have 4G and LAN interfaces going simultaneously even if they never move to a completely different LAN. The feature list is long and it is not surprising that it had an obvious goal of being better than TCP in every respect.

One other not-so-obvious thing is that because SCTP has taken all the best recent advances in TCP that apply to transports in general you have all these features guaranteed in SCTP whereas if you are still using TCP you could easily encounter rubbish old servers that are lacking certain important things. This minimum feature guarantee thing is powerful and has been seen in a number of v2.0 technologies: IPv6 and AMD64 being examples that come to mind immediately.

I am concerned about whether or not crappy firewall setups or old evil networking kit or evil ISPs could cause a 1% or 0.1%-case nightmare for an app developer. Because of this I also wonder if it might be an idea for such a developer to use SCTP only over IPv6, if that makes sense in the particular scenario. If you have to test whether SCTP works, then like testing NAT, or firewall busting or analysing firewalls, the cost starts to get so high that you would wonder why on earth you are still thinking about SCTP at all. It might be that if you only use IPv6 then you can be more sure of not encountering any evil, thinking that at least because all the kit will be more modern, but that still does not mean that you cannot possibly have trouble, because there still remains the case of evil policy for firewalls. If you have to use IPv4 too, which is very likely for many applications other than specialist limited-scenario ones, then what do you do? Fall back to TCP anyway, or do (one-off) path testing and then selectively fall back, or what? More code, more cost, more testing and if you have to fall back to TCP then what does that say about your need to use SCTP in the first case? Switching to SCTP-over-UDP would be a great option in my view and possibly then you do not even bother with path testing when using IPv4.

sevenlayermuddle:
Thank you for that explanation of your enthusiasm.

My view is that  SCTP was designed to solve specific problems, providing a means of carrying SS7 trafic over IP, thus allowing SS7 to survive into the new world.  But I tend to think the problems that it solved are not problems that affect home networks, or even that affect most of the applications now using TCP/UDP. 

For that reason, I personally can’t see it replacing TCP/UDP, there’s not sufficient upside to justify it.   But time will tell. :)

Weaver:
You are right. There are a number of factors at work here aside from the superiority of SCTP which probably doesn’t matter since for most people TCP is considered good enough: availability in Windows and Apple platforms; the importance of roaming/multihomed-friendliness; lack of blocking factors; single-platform, controlled scenarios, where the app developer knows what kit they are talking to at the other end. Could also add spreading the word/awareness.

All the bad things about TCP which made it useless for SS7 never went away. Those critics of TCP who felt sufficiently strongly that they went off and designed something else were right then and they are still right now. But most of the time it either doesn’t matter or there are workarounds.

—
However, to return to the topic:

I would be interested if anyone knows how many systems hate protocols with less common IP proto values or anything else other than TCP and UDP, or uncommon ports, also even systems that only allow http and nothing else.

Navigation

[0] Message Index

[#] Next page