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]