1 / 11

SIP Congestion Safety

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.

keita
Download Presentation

SIP Congestion Safety

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SIP Congestion Safety Open Issues

  2. 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”.

  3. 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.

  4. 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.

  5. 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

  6. 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

  7. 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.

  8. 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.

  9. 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?

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

  11. 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?

More Related