Congestion SafetyChanges and Issues

draft-ietf-sip-congestsafe-01

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

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

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.

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

Issues with new approach

• Responses not “guaranteed” congestion-safe unless requests use safety mechanism

• Better than what we have now?

• Is it good enough?