RFC 2556 INFORMATIONAL STANDARDS · HISTORICAL

OSI connectionless transport services on top of UDP Applicability Statement for Historic Status

Explaining why an old and unused RFC should be retired.

On rfc-editor.org ↗
PUBLISHED
March 1999
AUTHORS
S. Bradner
STREAM
Legacy
DOI
10.17487/RFC2556

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                         S. Bradner
Request for Comments: 2556                            Harvard University
Category: Informational                                       March 1999


             OSI connectionless transport services on top
           of UDP Applicability Statement for Historic Status

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   RFC 1240, "OSI connectionless transport services on top of UDP", was
   published as a Proposed Standard in June 1991 but at this time there
   do not seem to be any implementations which follow RFC 1240.  In
   addition there is a growing concern over using UDP-based transport
   protocols in environments where congestion is a possibility.

1. Use of RFC 1240 Technology

   A message was sent to the IETF list in October 1998 seeking any
   information on the actual use of the technology described in RFC
   1240.  A number of responses were received, including from the
   International Organization for Standardization (ISO), the keeper of
   the OSI protocols.  None of these messages pointed to any current use
   for this technology.  Most of the messages which made any
   recommendation did recommend that RFC 1240 be moved to historic.

2. Responsiveness to Congestion

   Since 1991 there has been a great deal of experience with the
   complexities of dealing with congestion in the Internet.  Congestion
   control algorithms have been improved but there is still work
   underway to further understand the issues.  In this environment any
   UDP-based protocol is somewhat worrisome since quite frequently
   people who use UDP-based protocols invent their own reliability and
   congestion control functions which may not include the results of the
   current state of the art.  This leads to a dange r of congestion
   collapse with potentially quite serious consequences for the network
   in which it is run.  See RFC 896 for a discussion of congestion
   collapse.

   In the case of RFC 1240, the authors seemed to assume that if some
   level of reliability was needed in an RFC 1240 environment that the
   reliability algorithms and the congestion control algorithms which
   would then be required would reside in the OSI protocols running over
   the UDP transport.  It is far from clear that any perceived
   advantages of running over UDP would not be eclipsed by the
   difficulties experienced in trying to create a reasonable congestion
   control algorithm.  Implementers would likely find that running over
   TCP as RFC 2126 describes is the better choice.

3. Conclusion

   Due to the lack of use of the technology described in RFC 1240 and
   the issues surrounding congestion control in the Internet, RFC 1240
   should be reclassified as Historic and its implementation actively
   discouraged.

4. Security Considerations

   This type of non-protocol document does not directly effect the
   security of the Internet.

5. References

   RFC 896   Nagle, J., "Congestion control in IP/TCP internetworks",
             RFC 896, January 1984.

   RFC 1240  Shue, C., Haggerty, W. and K. Dobbins, "OSI connectionless
             transport services on top of UDP: Version 1.", RFC 1240
             June 1991.

   RFC 2126  Pouffary, Y. and A. Young, "ISO Transport Service on top of
             TCP (ITOT)", RFC 2126, March 1997.

6. Author's Address

   Scott Bradner
   Harvard University
   1350 Mass Ave, rm 876
   Cambridge, MA
   02138
   USA

   Phone: +1 617 495 3864
   EMail: sob@harvard.edu

7.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

AI ELI5

On this page
PROBLEMRFC 1240, which defined OSI connectionless transport services running over UDP, was published as a Proposed Standard but never implemented and faced concerns about UDP-based transports in congested networks.
MECHANISMThis applicability statement documents the technical and practical reasons for moving RFC 1240 to Historic status, arguing that the benefits of using UDP do not justify the complexity and congestion control risks.
WHY IT MATTERSRFC 1240 is moved to Historic status, discouraging new implementations and signaling that TCP-based OSI transport is the preferred alternative.

§1RFC 1240 and the Lack of Adoption

RFC 1240 defined how to run OSI (Open Systems Interconnection) connectionless transport services on top of UDP. Published in June 1991 as a Proposed Standard, it was intended to provide an alternative transport mechanism. However, no known implementations of RFC 1240 were ever developed or deployed. A survey of the IETF community in October 1998 found no evidence of current use, and responses from relevant organizations, including ISO itself, supported moving the RFC to Historic status.

A rule for how to send messages using an older system was written down, but nobody ever actually used it. After checking, the Internet community decided it was not needed.

§2Congestion Control Concerns

Since RFC 1240 was published, significant experience with Internet congestion control has accumulated. UDP-based transport protocols are problematic because implementers often create their own reliability and congestion control functions that may not incorporate modern understanding of congestion management. This creates a risk of congestion collapse. RFC 1240's architecture, which assumes reliability algorithms would reside in the higher-level OSI protocols, does not adequately address these modern concerns.

Fast delivery is tempting, but without proper care, it can actually slow down the whole network when everyone tries to send at once. The old rule did not worry enough about this problem.

§3Moving to Historic Status

Given the complete lack of deployment experience and the known risks of UDP-based transports in congested environments, RFC 1240 is reclassified as Historic. Implementers are encouraged to use TCP-based approaches instead, as RFC 2126 describes. This decision reflects the principle that standards should reflect actual or anticipated use and that transport choices must account for modern Internet realities.

The Internet community decided to officially say: this rule is not good anymore, and we encourage people to use a better method instead.

§4References