1 / 6

Congestion Safety Changes and Issues

This draft discusses the challenges of maintaining congestion safety in SIP communication over UDP, highlighting issues with response handling and proposing a new approach to ensure responses are sent safely. It addresses the need for end-to-end knowledge of link conditions to prevent congestion problems and proposes a mechanism for UAS to transmit responses safely. The draft includes rules for UAS to follow when responding to requests and outlines potential issues with the proposed approach.

adrianaj
Download Presentation

Congestion Safety Changes and Issues

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. Congestion SafetyChanges and Issues draft-ietf-sip-congestsafe-01

  2. Background • SIP can use UDP, and a proxy can switch from TCP/SCTP to UDP without the knowledge or consent of the originating UA • UAs consequently do not have knowledge of end-to-end MTU or link conditions • SIP messages (requests or responses) can be large enough and frequent enough to create congestion issues on some links

  3. Previous draft • Defined Require header for congestion safety insertable by UAs, ostensibly for sending large requests safely • Defined policy for transmitting requests in a relatively safe manner that includes proxies • Did not address transmitting responses, which has been added in current draft

  4. Why are Safe Responses hard? • Response routing must follow inverse of path taken by requests (the VIA path), no options. • Responses may be larger than requests, creating problems (ex. fragmentation) that didn’t affect the request.

  5. Response Handling in Draft • Hypothesis: if the request arrived ok, a response of equal or smaller size is no less likely to be ok. • Rule: A “safe” UAS responding to a request may not send a response that is larger than the request unless the request was marked congestion safe using Require mechanism • A “safe” UAS responds with 514 “Response Could Not Be Sent Safely” if rule not met

  6. Issues with new approach • Responses not “guaranteed” congestion-safe unless requests use safety mechanism • Better than what we have now? • Is it good enough?

More Related