60 likes | 79 Views
Congestion Safety Changes 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
E N D
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?