draft-ietf-sip-congestsafe-01.txt   draft-ietf-sip-congestsafe-02.txt 
SIP -- Session Initiation Protocol D. Willis SIP -- Session Initiation Protocol D. Willis
Working Group B. Campbell Working Group B. Campbell
Internet-Draft dynamicsoft Inc. Internet-Draft dynamicsoft Inc.
Expires: August 13, 2003 Feb 12, 2003 Expires: April 12, 2004 October 13, 2003
Session Initiation Protocol Extension to Assure Congestion Safety Session Initiation Protocol Extension to Assure Congestion Safety
draft-ietf-sip-congestsafe-01 draft-ietf-sip-congestsafe-02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as groups may also distribute working documents as Internet-Drafts.
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 13, 2003. This Internet-Draft will expire on April 12, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
The Session Initiation Protocol allows the use of UDP for transport The Session Initiation Protocol allows the use of UDP for transport
of SIP messages. The use of UDP inherently risks network congestion of SIP messages. The use of UDP inherently risks network congestion
problems, as UDP itself does not define congestion prevention, problems, as UDP itself does not define congestion prevention,
avoidance, detection, or correction mechanisms. This problem is avoidance, detection, or correction mechanisms. This problem is
aggravated by large SIP messages which fragment at the UDP level. aggravated by large SIP messages which fragment at the UDP level.
Transport protocols in SIP are also negotiated on a per-hop basis, at Transport protocols in SIP are also negotiated on a per-hop basis, at
the SIP level, so SIP proxies may convert from TCP to UDP and so the SIP level, so SIP proxies may convert from TCP to UDP and so
forth. This document defines what it means for SIP nodes to be forth. This document defines by which a SIP User Agent may require
congestion safe and specifies an extension by which a SIP User Agent that its requests are not sent over UDP or other transports having
may require that its requests are treated in a congestion safe congestion-related characteristics similar to those of UDP.
manner.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definition of Congestion Safety for SIP . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Assuring Transitive Congestion Safety with Proxy-Require . . . 4 3. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . 4
5. Responsible use of SIP over UDP . . . . . . . . . . . . . . . 4 4. Assuring Transitive Congestion-Managed Transport with
5.1 Requirements For Use of SIP Over UDP . . . . . . . . . . . . . 6 Require and Proxy-Require . . . . . . . . . . . . . . . . . 5
5.2 Pacing SIP Requests Over UDP . . . . . . . . . . . . . . . . . 6
5.3 Proxy Rejects Request That Would Require UDP Fragmentation . 7
5.4 Server Rejects Request Because Response Could Not Be Sent
Safely . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Syntax of Extensions and Changes to SIP Specifications . . . . 9 5. New Behaviors at SIP Nodes . . . . . . . . . . . . . . . . . 5
5.1 Behavior at the UAC . . . . . . . . . . . . . . . . . . . . 5
5.1.1 Sending a Request . . . . . . . . . . . . . . . . . . . . . 5
5.1.2 Receiving a 514 Response to a Request . . . . . . . . . . . 6
5.1.3 Receiving a 515 Response to a Request . . . . . . . . . . . 6
5.1.4 Receiving a 516 Response to a Request . . . . . . . . . . . 6
5.2 Behavior at the Proxy . . . . . . . . . . . . . . . . . . . 6
5.2.1 Proxy Rejects Request Requiring Congestion Management
When Route with Congestion Management Not Available . . . . 7
5.2.2 Proxy Rejects Request Not Requiring Congestion
Management When Forwarding That Request Would Induce
Fragmentation . . . . . . . . . . . . . . . . . . . . . . . 7
5.2.3 Forwarding of Responses . . . . . . . . . . . . . . . . . . 7
5.3 Behavior at the UAS . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
Normative References . . . . . . . . . . . . . . . . . . . . . 11 Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . 11
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Background 2. Background
The Session Initiation Protocol RFC 3261 [4] provides application The Session Initiation Protocol [4] provides application support over
support over multiple transport protocols, including UDP and TCP. multiple transport protocols, including UDP and TCP. Extensions to
Transport negotiation is not "end to end" with SIP. Instead, each support SCTP are under consideration, and other transport protocols
SIP hop individually determines which transport to use. For example, may be proposed for future use. Transport negotiation is not "end to
a User Agent (UA) may use TCP to talk to a proxy, that proxy my use end" with SIP. Instead, each SIP hop individually determines which
UDP to talk to another proxy, and that second proxy may use SCTP to transport to use towards the next hop. For example, a User Agent
talk to a destination UA. Client (UAC) may use TCP to talk to a proxy, that proxy my use UDP to
talk to another proxy, and that second proxy may use SCTP to talk to
a destination User Agent Server (UAS).
UDP has inherent issues with congestion management. The protocol has UDP has inherent issues with congestion management or reliability.
not explicit mechanisms for avoiding, detecting, or adapting to The protocol has no explicit mechanisms for avoiding, detecting, or
network congestion. SIP attempts to deal with this in two ways: adapting to network congestion. SIP attempts to deal with this in two
ways:
1. Retransmission timers with exponential back offs. 1. Retransmission timers with exponential back offs.
2. Attempting to limit the size of transmissions over UDP to reduce 2. Attempting to limit the size of transmissions over UDP to reduce
the effects of fragmentation. the effects of fragmentation.
This would appear to be an incomplete solution. One solution might
be to deprecate UDP entirely for SIP. However, there is a large
installed base using UDP, and there are legitimately places where UDP
appears to be quite useful such as tiny mobile phones and in
extremely high-volume proxies connecting over dedicated networks.
As an alternative, this draft:
1. Defines what it means for a SIP node to be "congestion-safe".
2. Defines a mechanism whereby a congestion-safe UA may require that
any proxy processing its requests be congestion safe.
3. Defines a mechanism whereby a proxy may reject a request that it
would be forced to fragment, and in so doing inform the
originating UA of relevant sizing parameters.
4. Defines a mechanism whereby a server may reject requests that
would result in responses that might not be transmitted
congestion-safely if the request itself was not received in a
congestion-safe manner.
3. Definition of Congestion Safety for SIP
A SIP node can be considered "congestion safe" if it never emits a
request or response in a manner not known to be congestion safe.
Requests may be considered congestion-safe if any one of the
following criteria is met:
1. The transport toward the next SIP hop is TCP, SCTP, or other
transport providing congestion control and the next hop is known
to be either a UA or a congestion-safe proxy.
2. The transport toward the next hop is UDP, the next hop is known
to be a UA or congestion-safe proxy, and the network between the
two is known to support congestion management at a lower layer.
Note that this is an uncomoon case in typical Internet
applications.
3. If the only available transport toward the next hop is UDP and
the next hop is known to be a UA or congestion-safe proxy, the
request MAY be transmitted over UDP or rejected by local policy.
If the request is transmitted over UDP, the procedures described
under the heading "Responsible use of SIP over UDP" in this
document MUST be followed.
Responses may be considered congestion-safe if any one of the
following criteria is met:
1. The request was congestion-safe, as defined above.
2. The response is no larger than the request.
The preceding uses the phrase "the next hop is known to be either a
UA or a congestion-safe proxy." Such knowledge may be derived either
through administrative configuration or through use of the
Proxy-Require mechanism defined herein under the heading "Assuring
Transitive Congestion Safety with Proxy-Require".
4. Assuring Transitive Congestion Safety with Proxy-Require
SIP provides a mechanism whereby a user agent making a request can be
assured that any proxy servicing that request support a specific
extension or set of behavior. To do so, the user agent includes a
"Proxy-Require" header field with a value indicating a tag for the
specific extension or behavior required. There is an IANA
registration process for these tags. As per [4], proxies not
recognizing a specific tag or unwilling to support the associated
behavior reject a request referencing that tag with a 420 response,
which has the semantic "Unsupported".
We herein define a tag value of "congestion-safe". A proxy
forwarding a request containing a Proxy-Require with this tag value
MUST manifest the property of congestion-safety as defined by this
document.
5. Responsible use of SIP over UDP
The fundamental problem with UDP is that it provides no feedback The fundamental problem with UDP is that it provides no feedback
mechanism to allow a sender to pace its transmissions against the mechanism to allow a sender to pace its transmissions against the
real performance of the network. While this tends to have no real performance of the network. While this tends to have no
significant effect on extremely low-volume sender-receiver pairs, the significant effect on extremely low-volume sender-receiver pairs, the
impact of high-volume relationships on the network can be severe. impact of high-volume relationships on the network can be severe.
Consider the following scenario, wherein the traffic between multiple Consider the following scenario, wherein the traffic between multiple
UAs is funnelled through a single proxy-proxy relationship. UAs is funnelled through a single proxy-proxy relationship.
Example of large-fan out/fan-in likely to encounter congestion: Example of large-fan out/fan-in likely to encounter congestion:
skipping to change at page 5, line 31 skipping to change at page 4, line 14
Figure 1 Figure 1
In this scenario, any requests from UA(1..9) to UA(10..18) traverse In this scenario, any requests from UA(1..9) to UA(10..18) traverse
the proxy-proxy link P1&lt-->P2. Assuming current SIP practices, if the proxy-proxy link P1&lt-->P2. Assuming current SIP practices, if
this link is UDP and every UA emits a request simultaneously, each this link is UDP and every UA emits a request simultaneously, each
proxy will insert nine (one for each UA) requests, resulting in proxy will insert nine (one for each UA) requests, resulting in
eighteen simultaneous requests on the P1&lt-->P2 link. Each request eighteen simultaneous requests on the P1&lt-->P2 link. Each request
may require retransmissions, and large requests may require may require retransmissions, and large requests may require
fragmentation to fit the link MTU -- at the worst case, producing fragmentation to fit the link MTU -- at the worst case, producing
more than one hundred packets per request, or approximately 2,000 more than one hundred packets per request, or approximately 2,000
simultaneously expressed packets in this scenario. If the capacity simultaneously expressed packets in this scenario. If the capacity of
of link P1&lt-->P2 is inadequate to deliver these messages within the link P1&lt-->P2 is inadequate to deliver these messages within the
SIP retransmission window, the originating UAs (or the proxies, if SIP retransmission window, the originating UAs (or the proxies, if
acting in transaction-stateful mode) generate retransmissions, acting in transaction-stateful mode) generate retransmissions,
further compounding the problem into a "retransmission storm". further compounding the problem into a "retransmission storm".
Real-world scenarios may scale far more seriously. It is not Real-world scenarios may scale far more seriously. It is not
unreasonable to assume that there may be tens of thousands of UAs on unreasonable to assume that there may be tens of thousands of UAs on
each side of the network. each side of the network.
Clearly the best thing to do is to use a more sophisticated transport
protocol (TCP, SCTP, etc.) between P1 and P2, and between each UA and
its associated proxy. If this is not feasible, it may be necessary
to fall back to UDP.
It should be noted that the fundamental problem not just between UAs It should be noted that the fundamental problem not just between UAs
and proxies, but whenever there is a high fan-out or fan-in ratio. and proxies, but whenever there is a high fan-out or fan-in ratio. If
If in the above example, each UA were behind a "residential proxy", in the above example, each UA were behind a "residential proxy", the
the problem would occur in similar fashion. problem would occur in similar fashion.
One might propose that SIP ALWAYS use a congestion-controlled 3. Scope of Work
transport to talk to proxies, and only fall back to UDP when the next
hop is a UA. The primary problem with this approach is that in
general, a SIP node does not and cannot know whether the next node is
a UA or a proxy -- it is this ability to "insert" proxies into a
sequence that provides much of the flexibility of SIP. A secondary
problem is that even if the next hop is a UA, some UAs are
sufficienty high volume, and some links sufficiently narrow, that
congestion might still result from the incautious use of UDP.
5.1 Requirements For Use of SIP Over UDP One solution might be to deprecate UDP entirely for SIP. However,
there is a large installed base using UDP, and there are legitimately
places where UDP appears to be quite useful such as tiny mobile
phones and in extremely high-volume proxies connecting over dedicated
networks.
The previously described problems with the general use of SIP over As an alternative, this draft defines mechanisms whereby:
UDP lead to the following two requirements for the use of UDP as a 1. a UAC may require that any proxy processing its requests transmit
transport protocol for SIP: those requests over a transport protocol providing congestion
1. Large messages MUST NOT be transmitted over UDP. The SIP management.
specification provides basic guidance for UAs. Congestion-safe 2. a UAC may inform a UAS receiving its requests that those requests
proxies MUST follow the procedures described below under the were transmitted over a route supporting congestion management,
heading "Proxy Rejects Request That Would Require UDP and require that that UAS respond in similar fashion.
Fragmentation." UAs MAY also make use of the MTU feedback 3. A proxy may reject requests that require congestion-managed
techniques in that section. transport when that proxy finds that the only route it has to the
2. Nodes sending requests over UDP MUST pace those requests as next hop is over transport that does not support congestion
described under the heading "Pacing SIP requests over UDP." management.
4. A proxy may reject requests that would be fragmented, even for
requests that do not indicate a requirement for
congestion-managed transport.
5. A UAS may reject requests that would result in responses that
require congestion-managed transport if the originating request
did not require congestion-managed transport.
Response messages SHOULD be constrained to be smaller than the MTUs Note that SIP has no fundamental mechanism whereby a proxy may reject
established for requests by the preceding mechanisms, and systems a response. This precludes requiring congestion management for
implementors should remain aware that SIP provides limited support responses being processed by a proxy except as provided by the
for managing response sizes. Further experience may indicate a need original request. If, due to an issue of network topology change or
for further control over response handling. similar event between the processing of the request and the
processing of the response by a proxy the only path available to the
proxy is not congestion managed, the proxy has no choice but to send
the response over that path. It's not perfect, but seems to be all we
can do at this time.
5.2 Pacing SIP Requests Over UDP 4. Assuring Transitive Congestion-Managed Transport with Require and
Proxy-Require
One simple way to describe the congestion problem is that UDP lets us SIP provides mechanisms whereby a user agent making a request can be
send packets without knowing whether those packets are arriving. The assured that any proxy servicing or UAS responding to that request
simplest approach to dealing with this at the application level is to support a specific extension or set of behavior.
send a request, then wait for some sort of response indicating that
the request was received before sending anything else. This produces
an effect described by some as "ping-ponging" -- traffic bounces back
and forth between two nodes like a ping-pong ball or tennis ball in a
match. Since there's only one ball in play between any two players
at any given time, most of the potential for congestion cascades is
eliminated.
This pacing or serialization approach has the side-effect of To be assured that a proxy servicing the request meets the
significantly reducing the maximum throughput, as transmission occurs requirements, the UAC includes a "Proxy-Require" header field with a
in only one direction at a time and there is at least a 2xRTT delay value indicating a tag for the specific extension or behavior
between transmissions. More sophisticated algorithms such as those required. As per [4], proxies not recognizing a specific tag or
in TCP and SCTP have been developed to address this, and it would be unwilling to support the associated behavior reject a request
inappropriate to duplicate that work here. Consequently, if greater referencing that tag with a 420 response, which has the semantic "Bad
efficiency is required than that provided by this simple approach, Extension".
implementors should use TCP, SCTP, or another such protocol. But if
one absolutely must use UDP, this approach works, and is reasonably
efficient in the most likely application of "edge proxy" to UA and
other proxies with large fan-outs to individual low-volume nodes.
SIP has two sorts of request transactions: "invite" and "non-invite" To be assured that a UAS responding to a request meets the
tranactions. Invite transaction use a three way sequence of requirements, the UAC includes a "Require" header field with a value
"request, response, acknowledgement" and may include a "provisional indicating a tag for the specific extension or behavior required. As
response" between the request and response steps. Non-invite per [4], UASs not recognizing a specific tag or unwilling to support
transactions use a two-way "request, response" sequence, and may also the associated behavior reject a request referencing that tag with a
have a provisional response although that behavior has been 420 response, which has the semantic "Bad Extension".
deprecated.
Congestion-safe use of SIP over UDP requires waiting for some sort of We herein define a an option-tag value of "congestion-managed".
response to a request (or a timeout, which has backoff properties) There is an IANA registration process for these tags defined in [4],
before sending another request to that same destination. A and the "IANA Considerations" of this document fulfills the
congestion-safe SIP node (UA or proxy) MUST NOT send a request to a requirements of the IANA registration process.
given next-hop if there is an existing request to that destination
which has not received some sort of response. The existing
transaction MUST either receive a response (final or provisional) or
time-out before a new request can be made to that next-hop.
This effectively requires congestion-safe proxies to act in a 5. New Behaviors at SIP Nodes
transaction-stateful manner on a per-next-hop destination basis, at
least to the extent of tracking whether some sort of request is
pending to each next-hop and correlating provisional and final
responses to that request.
Some may argue that this puts an excessive burden onto the SIP node, 5.1 Behavior at the UAC
and that implementations that are "congestion-safe" per this
specification will have reduced performance when used with UDP over a
shared or public network. We counter that congestion-safe transport
protocols are readily available, and that network users which insist
on using unsafe transports (such as UDP) MUST be responsible for
assuring that they do not impede the function of other users of the
network, even at the expense of reducing their own efficiency. It is
simply irresponsible to "blast away" at the network without regard
for congestion or its impact on other users of the network.
5.3 Proxy Rejects Request That Would Require UDP Fragmentation 5.1.1 Sending a Request
A proxy may be faced with a request to deliver a large message using A UAC exercising this extension adds a Require header field and a
UDP as a transport. Fragmentation of such messages is problematic in Proxy-Require header field value including the option tag
several ways. Loss of any fragment requires time-out and "congestion-managed" to each request.
retransmission of the message. The fragments are commonly
transmitted out the interface at local interface (usually LAN) rates,
without awareness of intervening network conditions. For these
reason, we believe it in general a bad practice to send large
requests over UDP.
While the actual MTU of a link may not be known, common practice For any request that exercises this extension (i.e., contains the
seems to indicate that the local interface MTU is likely to be a "congestion-managed" option tags), the UAC MUST transmit the request
reasonable approximation. Where the actual path MTU is known, that using a protocol that supports congestion maangement.
value should be used instead.
When a congestion-safe SIP proxy processing a request determines that Any UA supporting this extension SHOULD exercise this extension on
the next hop is reached via UDP, and that the request is larger than all initial requests.
the effective MTU toward that hop and would consequently be
fragmented, the proxy MUST reject that request with a 513 response.
The base SIP specification provides minimal guidance on dealing with 5.1.2 Receiving a 514 Response to a Request
oversized requests. There is an error response code, 513, with the
semantic "request too large" that seems applicable. However, SIP
provides no guidance on how to indicate what size might be allowed.
We define here two extension header fields that may be used in a 513
response to indicate by the rejecting proxy the size of message
allowed by that proxy. The extension header field "Proxy-Max-Size"
may be used to indicate the largest allowable request to the
originating UA. The extension header field "Proxy-Seen-Size" may be
used to indicate the size of the rejected request as calculated by
the rejecting proxy. In both cases, the size value used indicates
the SIP message size, which does not include IP or transport protocol
overhead.
A congestion-safe SIP proxy which rejects a request based on size A 514 response (semantic "No available route with congestion
SHOULD include a "Proxy-Max-Size" header field with a value management) indicates that an intermediate proxy found that its only
indicating the largest size message allowed by this proxy on this vailable routes toward the required next hop did not support
link. If a Proxy-Max-Size header field is sent, the proxy MUST also congestion management. A UA receiving a 514 response has the options
include a "Proxy-Seen-Size" header indicating the size of the request of giving up, trying the request without the "Proxy-Require:
as seen at this proxy. congestion-management" (which will likely return a 516) or trying a
different set of proxies, presumably through using a different
pre-loaded Route header field.
A UA receiving a 513 response has the options of giving up, trying a 5.1.3 Receiving a 515 Response to a Request
smaller request, or trying a different set of proxies. Should it
choose to try a smaller request, it may estimate the size of the
largest message that can be sent by taking the original request size,
subtracting it from the value of the Proxy-Seen-Size header field,
and subtracting that result from the value of the Proxy-max-Size
header field. Note that a UA SHOULD NOT repeatedly downsize and
retry a request. This technique is not an adequate replacement for
TCP's Path MTU Discovery. Any request that has been rejected more
than once with a 513 SHOULD either be abandoned or re-issued over
congestion-safe channels.
5.4 Server Rejects Request Because Response Could Not Be Sent Safely A 515 response (semantic "Response requires congestion management")
indicates that the response generated by the UAS responding to the
request is larger than the UAS' understanding of path MTU and that
the UAS does not know that the route indicated by the VIA headers is
over congestion-managed transport. A UAC receiving a 515 to a
request may either retry the request in a congestion-managed manner
(adding the "congestion-managed" option tag to Require and
Proxy-Require)) or abandon the request.
A server receiving a SIP request generates a resposne to that 5.1.4 Receiving a 516 Response to a Request
request. Delivery of this response may raise issues of
congestion-safety. Because SIP requires that responses traverse
exactly the reverse of the route taken by the request (recorded in
the Via: header fields values), the server has no options about
routing the response. If the request was delivered in a
congestion-safe manner, it can be safely assumed that the response
will also be returned in a congestion-safe manner, as it must
traverse exactly this recorded route. However, if the request was
NOT received in a congestion-safe manner, the server cannot negotiate
a congestion-safe path for the response, as the response must follow
the path of the request.
If the size of the generated response is less than the size of the A 516 response (semantic "Proxying of request would induce
received request, it may be reasonably assumed that since the request fragmentation") indicates that a proxy forwarding the request
arrived intact, a response of equal or smaller size is likely to detected that the request was larger than the next hop link MTU from
traverse the reverse of that path succesfully. However, no such that proxy and that the transport protocol toward that next hop does
assumptions can be made about responses that are larger than the not support congestion management. A UAS receiving a 516 response may
corresponding request. retry the request with a "Proxy-Require: congestion-management" added
(which will probably return a 514), retry the request using an
alternate route, or abandon the request.
When a congestion-safe server generates a response to a request that 5.2 Behavior at the Proxy
is larger than the request and that request was not received over a
congestion-safe channel, it cannot be assumed that the response can
be safely transmitted. An unsafe response cannot be transmitted by a
congestion-safe server. Instead the server MUST reject the request
and return an error response using response code 514, which has the
semantic of "Response Could Not Be Sent Safely".
A UA receiving a 514 response to a request may either retry the A proxy forwarding a request containing a Proxy-Require with this tag
request in a congestion-safe manner or abandon the request. value MUST trasmit that request using a transport protocol (such as
TCP) supporting congestion-management. All proxies SHOULD attempt to
reduce fragmentation following the procedure described below.
6. Syntax of Extensions and Changes to SIP Specifications 5.2.1 Proxy Rejects Request Requiring Congestion Management When Route
with Congestion Management Not Available
The syntax for the Proxy-Max-Size header field is: When a SIP proxy processing a request marked with a Proxy-Require
header field containing the value "congestion-managed" determines
that the next hop is reachable only via a transport proocol not
supporting congestion management (such as UDP) the proxy MUST reject
that request with a 514 response.
Proxy-Max-Size = "Proxy-Max-Size" HCOLON 1*DIGIT 5.2.2 Proxy Rejects Request Not Requiring Congestion Management When
Forwarding That Request Would Induce Fragmentation
The syntax for the Proxy-Seen-Size header field is: When a SIP proxy supporting this extension and processing a request
not marked with a Proxy-Require header field containing the value
"congestion-managed" determines that the next hop is reachable only
via a transport protocol not supporting congestion management (such
as UDP) and the size of the request is larger than the MTU of the
interface towards that next hop, the proxy MUST reject that request
with a 516 response.
Proxy-Seen-Size = "Proxy-Seen-Size" HCOLON 1*DIGIT 5.2.3 Forwarding of Responses
7. IANA Considerations When any proxy supporting this extension forwards a request or
response and there is a choice of transport protocols toward the next
hop, the proxy SHOULD choose a transport protocol supporting
congestion management if one is available.
This document defines the SIP extension header fields When a proxy supporting this extension forwards a response containing
"Proxy-Max-Size" and "Proxy-Seen-Size" ", which IANA will add to the a Proxy-Require header field with the option-tag "congestion-managed"
registry of SIP header fields defined in [4]. as a value and the relevant Via header field value allows for a
choice of transport protocols, the proxy MUST select a transport
supporting congestion management if such a transport is available.
This document also defines the SIP option tag "congestion-safe" which SIP provides no mechanism whereby a proxy may reject a response.
Consequently, proxies may receive responses that require
fragmentation over a transport not supporting congestion management.
One example of a situation where this might be expected to occur is
as follows: A UAC not supporting this extension makes a request via
UDP. This request transits the proxy in question without inducing
fragmentation. The responding UAS generates a response that is larger
than the request. When the proxy prepares to send the request, it
finds that the increase in size now requires fragmentation.
Discarding the response would result in a timeout and retransmission
of the request and response, thereby doing more harm than good. There
seems to be nothing that the proxy can do to correct the situation,
so it MUST forward the response as specified in [4].
5.3 Behavior at the UAS
A user agent server server (UAS) receiving a SIP request generates a
response to that request. Delivery of this response may raise issues
of congestion management. Because SIP requires that responses
traverse exactly the reverse of the route taken by the request
(recorded in the Via: header field values), the server has no options
about routing the response. If the request was delivered in a
congestion-managed manner, it is likely that the response will also
be returned in a congestion-managed manner, as it must traverse
exactly this recorded route. However, if the request was NOT received
in a congestion-managed manner, the server cannot negotiate a
congestion-managed path for the response, as the response must follow
the path of the request.
When a UAS supporting this extension responds to a request over a
route supporting congestion management (as indicated by the presence
of the congestion-managed option tag in the request), the UAS MUST
include the congestion-managed option tag in a "Proxy-Require" header
field in the response. Furthermore, it MUST transmit that response
using a protocol supporting congestion management. If it is unable to
transmit the response using a protocol supporting congestion
management, it MUST reject the request and return an error response
using response code 515, which has the semantic of "Response requires
congestion management."
When a UAS supporting this extension generates a response to a
request that is larger than the UAS' understanding of path MTU and
that request was not received over a congestion-managed route (as
indicated by the presence of a "Require: congestion-managed"), it
cannot be assumed that the response can be safely transmitted. As the
UAS cannot respond safely, it SHOULD reject the request and return an
error response using response code 515, which has the semantic of
"Response requires congestion management". Note that this does not
absolutely preclude fragmentation of the response, as the request may
be fragmented by intervening routers. However, this sort of
fragmentation is outside of the UAS' capacity to detect or control.
6. IANA Considerations
This document defines the SIP option tag "congestion-managed" which
IANA will add to the registry of SIP option tags defined in [4]. IANA will add to the registry of SIP option tags defined in [4].
This document also defines the SIP response code 514, with the This document defines the SIP response code 514, with the semantic
semantic "Response Cannot Be Sent Safely" which IANA will add to the "No congestion-managed route available" which IANA will add to the
registry of SIP response codes defined in [4] in the section for 5xx registry of SIP response codes defined in [4] in the section for 5xx
clase response codes. clase response codes.
The following is the registration for the Proxy-Max-Size header This document defines the SIP response code 515, with the semantic
field: "Response requires congestion management" which IANA will add to the
registry of SIP response codes defined in [4] in the section for 5xx
clase response codes.
This document defines the SIP response code 516, with the semantic
"Proxying of request would induce fragmentation" which IANA will add
to the registry of SIP response codes defined in [4] in the section
for 5xx clase response codes.
The following is the registration for the congestion-managed option
tag:
RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of
this specification.] this specification.]
Header Field Name: Proxy-Max-Size Option Tag: congestion-managed
Compact Form: none
The following is the registration for the Proxy-Seen-Size header The following is the registration for the SIP response code 514:
field:
RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of
this specification.] this specification.]
Header Field Name: Proxy-Seen-Size Response Code: 514 No available route with congestion management
Compact Form: none
The following is the registration for the congestion-safe option tag: The following is the registration for the SIP response code 515:
RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of
this specification.] this specification.]
Option Tag: congestion-safe Response Code: 515 Response requires congestion management
The following is the registration for the SIP response code 514: The following is the registration for the SIP response code 516:
RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of
this specification.] this specification.]
Response Code: 514 Response Cannot Be Sent Safely Response Code: 516 Proxying of request would induce fragmentation
8. Acknowledgements 7. Acknowledgements
Robert Sparks and Jonathan Rosenberg argued with us vociferously over This document is a product of the SIP Working Group and contains
this topic and contributed substantial insight. input from many contributors in that group. The named authors of this
document claim no personal contribution to the content excecpt as
provided in their capacity as participants in the working group.
Rather, they have attempted to act only in an editorial fashion,
documenting the consensus of the working group as it emerged.
Somebody had to do the typing.
Normative References Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC [3] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/