1. Congestion Safety Changes 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?