SIP Congestion Safety Open Issues

Background SIP over UDP uses retransmissions timers within each transaction with exponential backoffs to provide reliability and some level of congestion control. SIP may also run on reliable transport protocols such as TCP or SCTP and uses their retransmission mechanisms. Multiple SIP transactions may be multiplexed on a reliable transport “session”.

Problems The UDP retransmission timer is local to a single transaction. A node may be involved in a large number of concurrent transactions over UDP, each of which has a separate retransmission timer. There is no standard way to adapt node behavior across multiple transactions to changing network conditions with UDP. SIP messages may go over UDP between proxies, even if sent via TCP or SCTP from the originating UA.

Message Size Factor Messages larger than MTU fragment over UDP, and there is no inter-fragment rate limiting. This has huge congestion implications. RFC 3261 Solution: Send no messages via UDP larger than MTU, or 1300 bytes if you don’t know. Since intermediate proxies may revert to UDP, send no messages larger than 1300 bytes. Ever. S/MIME bodies, MESSAGE requests, and other factors frequently push message size over 1300 bytes. RFC 3261 solution? None. Or design network to never use UDP between proxies.

Problem Scenario UA-1 UA-2 UA-3 UA-4 UA-5 UA-6 UA-7 UA-8 UA-9 UA-A UA-B UA -C UA-D UA-E UA-F UA-G UA-H UA-I P1P2 UDP App1App2 TCP UA-1 has transaction with UA-A, UA-2 with UA-B, etc. Stateless proxies P1 and P2 use UDP App1 and App2 talk TCP over same physical link P1 P2 monopolizes link, getting 90% of bandwidth If link becomes congested, P1 and P2 don’t know and don’t react. UAs react only within a given transaction. App1 App2 starves.

Corrected Scenario UA-1 UA-2 UA-3 UA-4 UA-5 UA-6 UA-7 UA-8 UA-9 UA-A UA-B UA -C UA-D UA-E UA-F UA-G UA-H UA-I P1P2 Reused TCP or SCTP App1App2 TCP UA-1 has transaction with UA-A, UA-2 with UA-B, etc. Stateless proxies P1 and P2 use TCP, re-using session. App1 and App2 talk TCP over same physical link P1 P2 shares bandwidth equally with App1 App2. Both react if link becomes congested. UA-P links may start queuing, resulting in many retransmissions links, but that’s a different problem. App-1 App-2 is not impacted.

What’s the Draft Do? Defines congestion problem. Defines congestion-safe behavior: –strong preference for TCP/SCTP –No concurrent UDP transactions in same direction between any 2 nodes. Enforces 2xRTT (ping-pong) rate limiting. Not efficient, but safe. Defines Require mechanism whereby UAs may know that requests will be handled in a congestion-safe manner.

Could We Simplify? Thou shalt not use UDP except between a wireless UA and its edge proxy. –SIP provides no way to know whether next hop is UA or proxy. –Responsibility is delegated to network designer. Deprecate UDP from spec. –Huge backward compatibility issues.

Is it Safe to Be Unsafe? Draft says that congestion-safe proxies always apply new congestion control behavior. –Greatly reduces throughput over UDP links. Suggestion made that proxies apply new behavior only for requests that “Require” it. Should UAs be able to force unsafe behavior by proxies?

Require/Proxy Require? Draft defines only Require header field value Do we need a Proxy-Require header field value?

Strong Enough Medicine? Provides no end-to-end guidance, does not prevent queuing at proxies or retransmissions at UDP UAs. Would SIP nodes that play by the rules in this draft be sufficiently responsible members of network society? Do we need to do more? If so, what?