Network Working Group F. Tommasi Internet Draft S. Molendini Document: draft-tommasi-rsvp-bund-00.txt University of Lecce Expiration date: September 2000 March 2000 Limiting Bundling Delays in RSVP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document discusses problems related to a fair use of Bundle messages in RSVP. Bundle messages are defined in [Berger2000]. A new Urgent flag in the MESSAGE_ID object is defined, and rules are given to set the Bundling timer Td. Conventions used in this document 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 RFC2119. F.Tommasi / S.Molendini Expires September 2000 [Page 1] draft-tommasi-rsvp-bund-00.txt March 2000 Contents 1. INTRODUCTION.....................................................2 2. URGENT FLAG......................................................3 3. HOW TO SET THE BUNDLING TIMER TD.................................4 4. RULES ABOUT MESSAGES BUFFERING...................................4 5. POLICY CONSIDERATIONS............................................5 6. SECURITY CONSIDERATIONS..........................................5 7. ACKNOWLEDGEMENT ..................................................5 8. REFERENCES.......................................................5 8. AUTHORS' ADDRESSES ...............................................5 1. Introduction In order to limit the overhead due to the transmission and processing of single RSVP messages, messages are grouped in larger Bundle messages. Thus, Bundle Messages are RSVP messages that contain lists of other messages. See [Berger2000] about their format and usage. If one follows the current RSVP specifications, it is hard to create Bundle messages. Messages are sent when they are created, as soon as they can be transmitted. By introducing a small delay it is possible to achieve a noticeable improvement of the protocol performances. A router can assign a maximum latency Td to each destination and then proceed to buffering messages to that destination until Td expires. It will then pack all the queued messages into the Bundle message to be sent to that destination. F.Tommasi / S.Molendini Expires September 2000 [Page 2] draft-tommasi-rsvp-bund-00.txt March 2000 A small delay is rarely critical for messages such as Ack, PathErr, ResvErr, ResvConf, refresh Path and Resv messages. All these kind of messages can be delayed for a certain amount of time without consequences. The same cannot be said for trigger messages, which imply an immediate modification of the RSVP state. If a delay is introduced for these messages, it adds up to the total delay of the RSVP response. This can be acceptable for some applications but not for all (e.g. distributed computing), as some applications may require a small set-up time. An application must therefore be allowed to require an immediate delivery of RSVP trigger messages it labels as urgent using a flag for this purpose. For the same reasons, it is sometime very important to transmit PathTear and ResvTear messages without delays. Failure in doing so could result in wasting critical resources. A new Urgent flag in the MESSAGE_ID object of the message is therefore defined: when set, a node must transmit the message without any delay. A related issue is how to determine Td, which is the time the RSVP process will wait for the arrival of newly formed RSVP messages before bundling them in a single message for delivery. Td is also the worst case delay allowed for a message. One way to fully exploit bundling is to increase the Td value. However increasing the value of Td increases the delay of RSVP messages, reducing the end-to-end QoS. On the other hand reduction of Td value would decrease the end-to-end delay thus decreasing the overhead reduction obtained by bundling. Moreover, unaware implementations could use large Td values, completely damaging the end-to-end QoS provision. 2. Urgent flag A new Urgent flag is defined in the Flags field of the MESSAGE_ID object: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message_Identificator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ F.Tommasi / S.Molendini Expires September 2000 [Page 3] draft-tommasi-rsvp-bund-00.txt March 2000 Flag 0x04: Urgent. It MUST NOT be set in messages different from Resv, Path, ResvTear and PathTear messages. If set, a message MUST be forwarded through the output interface without being buffered for bundling. This flag should be set by applications. A router MUST set Urgent flag in all Resv, Path, ResvTear, PathTear messages created as a consequence of processing a received Urgent message. If a regular [RFC2205] RSVP message (without a MESSAGE_ID object) is received, it will be processed as an Urgent message. 3. How to set the Bundling timer Td Each node determines the Td value. It is computed from a local estimate of the Round Trip Time (RTT) between the node and its RSVP neighbour: Td is set to 50% of RTT/2. In this way the total delay a non-Urgent message can suffer travelling between two hosts is, in the worst case, 1.5 times the time without any delay, plus a small message processing delay. An RSVP process is free to select the etimation method (e.g. an ICMP echo request/reply could be choosen) Sometime the RTT value cannot be determined, or it is too long: in all cases a 100 msec maximum value for Td is introduced. When a new message is created, the RSVP process computes (when possible) the address of the next RSVP node. If this is a new one, a new neighbour is identified and the related Td value is determined. So, the Td value MUST NOT be greater than the 50% of RTT/2 (if it can be determined) and it MUST NOT be greater than 100 msec. 4. Rules about messages buffering Let suppose that the Bundling buffer is empty. The first message sets the Td timer and the following messages are buffered until one of these events occurs: 1) A message marked as Urgent is created; 2) The Td timer expires; 3) Pending messages are enough to build a large packet. At this point the messages are sent as a Bundle message, the buffer is emptied and Td timer is reset. Point 1) states that pending messages are sent immediately when an Urgent message must be transmitted. Point 2) limits the maximum delay a message can tolerate. Point 3) simply states that messages can be sent when the Bundle Message has reached the limit posed by the MTU and further messages cannot fit in it. F.Tommasi / S.Molendini Expires September 2000 [Page 4] draft-tommasi-rsvp-bund-00.txt March 2000 5. Policy considerations There is not a real policy problem using the Urgent flag, because only RSVP control messages are affected by the delay introduced by the bundling. So, applications can freely decide to use the Urgent flag. However, the number of Urgent messages should not be so large to make bundling useless. Remember that the total end-to-end delay is about the 1.5 the RTT between the two hosts. Then, only applications that have a serious end-to-end-delay problem should set the Urgent flag. In order to avoid improper usage of Urgent messages, routers can decide to clear the Urgent flag in some incoming messages, bundling them as regular RSVP messages. Also, routers can decide always to clear the Urgent flag in all incoming messages. 6. Security Considerations No new security issues are raised in this document. 7. Acknowledgement This work benefit from the discussions held within the RSVP WG during the 46th IETF meeting in Washington. Thanks to Lou Berger and Bob Braden for specific feedback on the document. 8. References [Berger2000] Berger, L., Gan, D., Swallow, G., _Pan, P., Molendini, S., Tommasi, F. "RSVP Refresh Overhead Reduction Extensions_, Internet Draft, draft-ietf-rsvp-refresh-reduct-02.txt, January 2000 [RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997. 8. Authors' Addresses Franco Tommasi University of Lecce, Fac. Ingegneria Via Monteroni 73100 Lecce, ITALY tommasi@ilenic.unile.it Simone Molendini University of Lecce, Fac. Ingegneria Via Monteroni 73100 Lecce, ITALY molendini@ultra5.unile.it F.Tommasi / S.Molendini Expires September 2000 [Page 5]