- Home
- Skype for Business
- Skype for Business Blog
- To UDP, or not to UDP, that is the question…
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Author: Russell Bennett
Publication date: May 2008
Product version: Office Communications Server 2007 R2
Generically, SIP can use (at least) 3 types of transport. Office Communications Server supports TCP and TLS, with the latter being the default (actually, TLS runs on TCP).
Various interactions with some partners and customers of late of have posed the question: "Why doesn’t OCS support SIP over UDP?" Their belief is that UDP is the ‘lowest common denominator’ SIP transport that is supported by "everyone" and that, by not supporting it, OCS is out of step with the mainstream of SIP implementation and interoperability.
Let’s evaluate that proposition on its merits.
Why doesn’t OCS support UDP?
There are three issues with UDP:
- It is not encrypted, so you can’t ensure end to end security of SIP messages. There is no shortage of opinions on the security, or the lack thereof, of SIP (e.g. Cert® Advisory, ). As a text based protocol that is human readable (if ‘readable’ is the right word…it is not exactly prose…) there are privacy/security issues of sending SIP ‘in clear’. Furthermore, UDP allows for easier spoofing of packets since connection state doesn’t need to be maintained (remember Slammer?....UDP). This is why OCS customers are strongly recommended to accept TLS over TCP as the default SIP transport within the OCS network.
- UDP has a fundamental flaw for large SIP messages: the size of the UDP datagram is limited to 1500 bytes, so a SIP message larger than that will be broken into two or more packets. The application layer (client or server) can receive the fragments out of order or a fragment could be lost (see 3 below). Since OCS SIP messages tend to contain various XML bodies, machine generated unique IDs (e.g. GRUUs), ICE candidate attributes, (etc.) they will normally span multiple packets.
- UDP is a "fire and forget" protocol: this is to say that the transport layer does not consider lost or delayed packets. The onus of tracking messages for which no response has been received (and the generation of new requests) is left to the application layer: this leaves the application (the client or the server) vulnerable to overload situations. In bad network conditions, the best case scenario is a call setup delay. The worst case scenario is that the SIP network can reach a tipping point where the session timers are tripping for every transaction because the network elements are busy generating, or responding to, "retries" – a so-called "retry storm".
A commercially deployable enterprise communications solution must, at the very least, be secure, reliable and scalable. UDP presents challenges in all of these areas and the SIP RFCs (see below) allow us to choose from alternative SIP transports. Within the OCS network we use TLS, and at the edge of the network we can interoperate over TCP.
Why do people object to TCP or TLS as a SIP transport?The fundamental objection to SIP over TCP or TLS is that it they are computationally expensive relative to UDP. There are several parameters at the transport, session and application layers that affect transaction performance:
- Stateful vs. Stateless
- Authentication vs. no Authentication
- Encryption vs. no Encryption
An IBM Research article "Evaluating SIP Proxy Server Performance" examined, among other things, the impact of the choice of SIP transport protocol on SIP transaction throughput. The authors found clear evidence that stateless UDP with no authentication (and therefore no encryption) has, by far, the highest throughput. However, this modality is completely incompatible with a reliable and secure commercial communications service. Stateful transaction processing with authentication yielded a 43% transaction degradation when using TCP compared with UDP. However, the authors were using an open source proxy server and brought to light various performance issues that were implementation specific.
An IEEE Article "SIP Security Issues: The SIP Authentication Procedure and its Processing Load" further examines the security and authentication overhead issue and found only a 5.5% overhead to TCP vs. UDP. Their summary includes the comment:
Another interesting finding is that the TCP processing introduces a small increase [in processing overhead] with respect to UDP and that the additional increase due to TLS is almost negligible.
Therefore, if you compare UDP to TCP and TLS in a commercially deployable solution, it is hard to defend the argument that the overhead of TCP and TLS outweigh the reliability and security advantages that they provide.
The debate regarding whether or not TCP is inefficient/expensive has been going on for many years. An IEEE Landmark Article "An Analysis of TCP Processing Overhead" published in June 1989 disproves the notion that TCP (by then a 15 year old protocol) is an inefficient protocol. The fact that it is still in use nearly 20 years later suggests that the authors were correct and that current anti-TCP sentiment is based upon "techno-urban legend", rather than scientific analysis.
Is UDP more standard than TCP or TLS?
There is a belief among certain constituencies that UDP is "more standard" than TCP or TLS.
From a historical perspective, the original SIP spec, RFC 2543 (published in March 1999), states:
User agents SHOULD implement both UDP and TCP transport. Proxy, registrar, and redirect servers MUST implement both UDP and TCP transport.
Note that equal priority was given to TCP and UDP. If you take a look at the current SIP spec, RFC 3261 (published in June 2002), you will see in section 18 the following statements related to SIP transport:
All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols.
Making TCP mandatory for the UA is a substantial change from RFC 2543. It has arisen out of the need to handle larger messages, which MUST use TCP, as discussed below. Thus, even if an element never sends large messages, it may receive one and needs to be able to handle them.
While it is true that OCS does not comply with RFC 3261 by not offering or accepting UDP, the assumption that all SIP messages will exceed the UDP datagram size limit provides an implied waiver on this requirement. Furthermore, TCP is the base transport for TLS, which we strongly recommend for security reasons; note that TLS does not run on UDP. Therefore, the conjunction of the security, fragmentation and reliability/scalability issues has lead us to the conclusion that UDP is not a useful transport for the transmission of SIP messages.
Is UDP the preferred SIP transport?
In order to verify the notion that SIP over UDP is supported by everyone, and yet TCP/TLS is supported by no-one, let’s examine the SIP offerings of the (overwhelming) majority market share vendors:
Based on this small, but statistically significant sample – there is a strong argument that TCP is actually the lowest common denominator SIP transport. Certainly, the notion that vendors do not support, and customers can not deploy, SIP over TCP is thoroughly debunked.
Conclusion
We have examined the myth that UDP is the best choice SIP transport:
- We have evaluated whether or not UDP is a good protocol for a commercially reliable, secure and scalable communications service
- We have examined the evidence that TCP, with stateful transaction processing and authentication, is significantly less performant than UDP
- We have determined whether there is any basis for a bias towards UDP in the SIP standards
- We have also examined the support of UDP, TCP and TLS in the majority of enterprise and service provider SIP deployments
As Adam and Jamie say on the Discovery Channel’s ‘Mythbusters’: I think we are ready to make a call on this myth….and it is definitely ‘busted’.
Lync Server Resources
- Lync Server 2010 documentation in the TechNet Library
- DrRez blog
- Lync Server and Communications Server resources
We Want to Hear from You
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.