SIP WG V. Gurbani
Internet-Draft Lucent Technologies, Inc./Bell
Updates: 3261 (if approved) Laboratories
Expires: April 6, 2007 S. Lawrence
Pingtel Corp.
October 3, 2006
Handling Large User Datagram Protocol (UDP) Responses in the Session
Initiation Protocol (SIP)
draft-gurbani-sip-large-udp-response-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 6, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Session Initiation Protocol (SIP) mandates a maximum size for any
request transmitted over UDP. This maximum is set to the lesser of
1300 bytes or the path maximum transmission unit (MTU) size minus 200
bytes. If the size of the request exceeds this maximum, SIP requires
implementations to switch the downstream transport to be a congestion
Gurbani & Lawrence Expires April 6, 2007 [Page 1]
Internet-Draft Large UDP Responses in SIP October 2006
controlled transport. However, when sending a response, a SIP
implementation cannot choose the transport; it must use the transport
specified by the Via. This document discusses the problems large
responses can cause on UDP, and proposes an update to SIP to help
diagnose and avoid those problems.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 UAS Considerations . . . . . . . . . . . . . . . . . . . . 4
3.2 UAC Considerations . . . . . . . . . . . . . . . . . . . . 4
3.3 Proxy Considerations . . . . . . . . . . . . . . . . . . . 4
4. Alternatives Evaluated . . . . . . . . . . . . . . . . . . . . 5
4.1 Error response to force transport change . . . . . . . . . 5
4.1.1 UAS Considerations . . . . . . . . . . . . . . . . . . 5
4.1.2 UAC Considerations . . . . . . . . . . . . . . . . . . 5
4.1.3 Proxy Considerations . . . . . . . . . . . . . . . . . 5
4.2 Use message/sipfrag . . . . . . . . . . . . . . . . . . . 6
4.3 Request in the backwards direction . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1 Normative References . . . . . . . . . . . . . . . . . . . 7
8.2 Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 9
Gurbani & Lawrence Expires April 6, 2007 [Page 2]
Internet-Draft Large UDP Responses in SIP October 2006
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
2. Problem Statement
SIP has been defined to work over many transports, congestion
controlled and otherwise. RFC3261 [2] contains normative text on how
requests that are larger than a defined maximum cause a switch to
using a congestion controlled transport. This maximum is the path
MTU minus 200 bytes. If the path MTU is not known, SIP requires that
it be assumed to be no larger than 1500 bytes.
When a transport lacking congestion control (like UDP) is used in
SIP, a sending host will fragment the UDP packet into its respective
IP datagrams if the size of the UDP packet exceeds the path MTU.
Since reliability in the form of retransmitting lost IP fragments is
not built into UDP as it is in TCP, a missing (or late arrival) IP
fragment results in the entire UDP packet being discarded. Some SIP
implementations and network address translation (NAT) devices do not
handle fragmentation gracefully, dropped UDP datagrams can be quite
likely. Reliability over UDP is built into SIP by application-level
retransmissions, but under some conditions retransmissions do more
harm than good to the network as a whole [5].
RFC 3261 [2] instructs implementations to use a congestion controlled
transport whenever the size of a request to be sent downstream
approaches a maximum allowed datagram size. While this works for
requests, there is nothing equivalent in RFC3261 for responses.
There are legitimate cases in SIP where the size of the response far
exceeds a single datagram. Since SIP routes responses over the same
transport as its corresponding request, an intermediary that received
a request over UDP and sent it downstream over TCP is forced to send
a large response over UDP to its upstream neighbor. If the UDP
datagram is fragmented, the upstream system may not be able to
reassemble the UDP datagram to successfully receive the SIP message,
resulting in a request timeout.
Note that UDP fragmentation and reassembly works unless there is a
lossy link or there is a NAT between the communicating endpoints.
However, since in any deployment there is no deterministic way to
minimize the chance of traversal over a lossy link or through a NAT,
a general purpose solution to the large UDP response problem is an
attractive option. This document proposes some normative changes to
SIP to improve the diagnosis of these problems.
Gurbani & Lawrence Expires April 6, 2007 [Page 3]
Internet-Draft Large UDP Responses in SIP October 2006
3. Solution
There may be multiple solutions to the problem identified above.
Some alternatives the authors considered are discussed in Section 4
below. This section describes the one the authors consider most
promising.
There is nothing that can be done to ensure that a UDP-fragmented
response will be reliably received, so the objective of these
proposed changes is to diagnose the problem when it does occur. To
accomplish this, it is necessary to provide a response that is small
enough to traverse the UDP hop(s) that alerts the requestor (and any
other systems in the path) that a large response is being sent. The
proposal defines two new provisional response codes:
140 Large Request Transport Change: This response is sent by a proxy
whenever it is changing to a congestion-controlled transport
because the request size is over the maximum allowed as mandated
by RFC 3261 [2] section 18.1.1.
141 Sending Large Response: This response is sent by a UAS
immediately before sending any final response whose size exceeds
the default maximum of 1500 bytes if the response path includes
one or more UDP hops.
The changes described below are partially (depending on request type)
in conflict with [4]. This conflict could be resolved in more than
one way. The authors solicit discussion of this issue, including the
tradeoffs between the problems described in [6] and the problem of
loosing large responses on UDP paths.
3.1 UAS Considerations
A UAS that needs to send a response that is larger than the default
maximum SIP messsage size (1500 bytes) MUST inspect the chain of Via
headers in the request. If any of the Via header entries includes a
UDP hop, then the server MUST send a 141 Sending Large Response
provisional response. The 141 response MUST include a Warning header
identifying the UAS, and MUST NOT have any body.
3.2 UAC Considerations
A client that receives a 140 or 141 response to any request that
subsequently times out MAY automatically retry that request using a
congestion-controlled transport.
3.3 Proxy Considerations
When a proxy has receives a request whose topmost Via specifies UDP,
Gurbani & Lawrence Expires April 6, 2007 [Page 4]
Internet-Draft Large UDP Responses in SIP October 2006
and at least one forwarded copy of that request is sent on a
congestion controlled transport because it exceeds the default
maximum size of 1500 bytes, then the proxy MUST send exactly one 140
Large Response Transport Change provisional response to that request.
Note that timing of this 140 response is not required to have any
particular relationship to that of forwarding the request; it may be
sent before or after the request is forwarded.
4. Alternatives Evaluated
Three alternatives were considered during the evaluation of possible
solutions. These were:
4.1 Error response to force transport change
Introduce a new final response '489 - Use Congestion-controlled
Transport'. If a SIP element would otherwise send any final
response, but the size of that response exceeds the maximum SIP
datagram size and an examination of the Vias shows that the response
will traverse at least one UDP hop, then send an error response to
force a change of transports.
Since the 489 response would have no body, it is likely to be small
enough when it reaches the UDP hop to be small enough to not cause
fragmentation, and so is likely to reach the requestor.
4.1.1 UAS Considerations
A server that wants to send a response over UDP that is larger than
the high watermark MUST inspect the chain of Via headers in the
request. If any of the Via header entries includes a UDP hop, then
the server MUST respond with a 489 response. The body of the 489
MUST be empty.
4.1.2 UAC Considerations
A client that receives a 489 response to a request MAY retry that
request using a congestion-controlled transport.
4.1.3 Proxy Considerations
No different than Section 3.2 for the client transaction state
machine and Section 3.1 for the server transaction state machine.
The problem with this approach is that it may create failures that
would otherwise not have happened. It is possible for fragmented UDP
datagrams to be reassembled successfully, so even a very large
Gurbani & Lawrence Expires April 6, 2007 [Page 5]
Internet-Draft Large UDP Responses in SIP October 2006
success response might reach the requestor over a path including one
or more UDP hops. In addition, it may not be possible for the
requestor to force a transport change; the requestor or some proxy on
the path may be limited to UDP. Using this error would eliminate any
possiblility of such a configuration working.
4.2 Use message/sipfrag
An appealing alternative is to use a 489 response with a body
corresponding to the "message/sipfrag" MIME type [3]. The body can
include more diagnostic information, much the same as is done for hop
limit expiration [7].
This alternative was eschewed in favor of simplicity since it then
opens up the possibility of the response getting bigger and what to
prune.
4.3 Request in the backwards direction
A second alternative is to have the server that generates a response
use a 489, but then open up a new request in the direction of the
client. The client's URI can be obtained from the Contact header of
the original request. The new request can be sent over TCP and it
can contain information to allow the client to match the new request
with the one that generated the 489.
There are two issues with this approach. For one, it will not work
for requests that omit the Contact header. Additionally, the UAC may
not be directly accessible (i.e., it may be behind a NAT or a
firewall) requiring a GRUU.
5. Security Considerations
To put in.
6. IANA Considerations
To put in.
7. Acknowledgments
The alternative in Section 4.3 was proposed by Jonathan Rosenberg on
the SIP mailing list.
8. References
Gurbani & Lawrence Expires April 6, 2007 [Page 6]
Internet-Draft Large UDP Responses in SIP October 2006
8.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
November 2002.
[4] Sparks, R., "Actions Addressing Identified Issues with the
Session Initiation Protocol's (SIP) Non-INVITE Transaction",
RFC 4320, January 2006.
8.2 Informative References
[5] Daigle, Ed., L., "IAB Considerations for UNilateral Self-Address
Fixing (UNSAF) Across Network Address Translation", RFC 3424,
November 2002.
[6] Sparks, R., "Problems Identified Associated with the Session
Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4321,
January 2006.
[7] Lawrence, S., Hawrylyshen, A., and R. Sparks, "Diagnostic
Responses for Session Initiation Protocol Hop Limit Errors",
draft-ietf-sip-hop-limit-diagnostics (work in progress),
June 2006.
Authors' Addresses
Vijay K. Gurbani
Lucent Technologies, Inc./Bell Laboratories
2701 Lucent Lane
Room 9F-546
Lisle, IL 60532
USA
Phone: +1 630 224-0216
Email: vkg at bell hyphen labs dot com
Gurbani & Lawrence Expires April 6, 2007 [Page 7]
Internet-Draft Large UDP Responses in SIP October 2006
Scott Lawrence
Pingtel Corp.
400 West Cummings Park
Suite 2200
Woburn, MA 01801
USA
Phone: +1 781 938 5306
Email: slawrence@pingtel.com
Gurbani & Lawrence Expires April 6, 2007 [Page 8]
Internet-Draft Large UDP Responses in SIP October 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gurbani & Lawrence Expires April 6, 2007 [Page 9]