Aug 4, 2010

Diameter over SCTP

I want to discuss today one of the issues we had elaborated on in the Diameter technical group ( )

This is the trend towards Diameter SCTP
We see more and more Diameter running over SCTP in some major operators, really everywhere – APAC, EU and US.
This is still a very small percentage of Diameter (which in itself is still in early adoption days) but this is certainly a trend.
This creates some new issues:
- Vendors support for SCTP is limited – so connectivity problem is an issues
- Connectivity between Diameter SCTP/Diameter TCP requires mediation (Diameter SCTP to Diameter TCP gateways)
- Testing is problematic – many in between entites (routers/switches/load balancer…) have problems with SCTP and it takes time to understand this is not a problem related directly to your product, so you only test your product you test all the transport layer in between (something that works with no problem with TCP)
- Need for through testing – the product beaves completely different with none TCP layer 3 stack

I really don’t know what the future hold, will Diameter over SCTP trend increase and it will become the common path ?
I personally don’t think so, there were many initiative to improve TCP over the years (e.g WTCP) and although they had great advantages over TCP they never won, so I’m afraid SCTP will follow the same route. But still there is Diameter over SCTP trend on the rise. Well we’ll need to wait and see.


  1. SCTP. Doesn't it has more overhead as the name implies?
    With the added overhead and delays why should one go for that?
    What are the disadvantages of restricting with TCP rather UDP?

  2. If I am not mistaken, SCTP actually reduces overhead. You see, while TCP enforces both reliability (have all my packages arrived?) and integrity (were any of my packages corrupted?), SCTP allows you to enforce these policies separately.
    Applications where dropped packets are legitimate, but data corruption is a problem, TCP creates unneeded overhead in retransmission.