110 likes | 188 Views
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.
E N D
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-A App1 App2 UA-2 UA-B UA-3 UA -C TCP UA-4 UA-D P1 UDP P2 UA-5 UA-E UA-6 UA-F UA-1 has transaction with UA-A, UA-2 with UA-B, etc.Stateless proxies P1 and P2 use UDPApp1 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. UA-7 UA-G UA-8 UA-H UA-9 UA-I
Corrected Scenario UA-1 UA-A App1 App2 UA-2 UA-B UA-3 UA -C TCP UA-4 UA-D P1 Reused TCP or SCTP P2 UA-5 UA-E UA-6 UA-F 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. UA-7 UA-G UA-8 UA-H UA-9 UA-I
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?