idnits 2.17.1 draft-calhoun-diameter-reliable-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 81: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 85: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 88: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 94: '... MAY This word, or the adjecti...' RFC 2119 keyword, line 96: '...hich does not include this option MUST...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '10' is mentioned on line 115, but not defined == Missing Reference: '12' is mentioned on line 297, but not defined == Unused Reference: '1' is defined on line 404, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 406, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 407, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 409, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 411, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (ref. '1') (Obsoleted by RFC 3232) == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-00 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-05 -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Standards Track Sun Microsystems, Inc. 4 Title: draft-calhoun-diameter-reliable-00.txt Allan C. Rubens 5 Date: November 1998 Ascend Communications 7 DIAMETER 8 Reliable Transport Extensions 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 Many services that require DIAMETER need retransmission and timeout 32 faster than TCP can provide. 34 An example would be in a NAS environment where DIAMETER is used for 35 the authentication and authorization of users. The amount of time 36 that it takes for TCP to determine that a connection to a server is 37 broken is longer than the disonnect timeout of the PPP clients on 38 whose behalf the server is being contacted. 40 RADIUS has been able to handle this situation by operating over UDP. 41 However, RADIUS fails to define a standard retransmission and timeout 42 scheme, which has resulted in many different methods across 43 implementations. 45 This DIAMETER specification defines the extensions necessary for the 46 base protocol to operate over a non-reliable transport (e.g. UDP). 48 Table of Contents 50 1.0 Introduction 51 1.1 Definitions 52 2.0 Protocol Overview 53 2.1 Flow Control 54 2.2 Suggested implementation 55 2.3 Peer failure recovery 56 3.0 Extended Header Format 57 4.0 DIAMETER AVPs 58 4.1 Receive-Window 59 5.0 References 60 6.0 Acknowledgements 61 7.0 Author's Address 62 Appendix A: Acknowledgment Timeouts 63 A.1 Calculating Adaptive Acknowledgment Timeout 64 A.2 Flow Control: Adjusting for Timeout 65 Appendix B: Examples of sequence numbering 66 B.1 Lock-step tunnel establishment 67 B.2 Multiple packets acknowledged 68 B.3 Lost packet with retransmission 70 1.0 Introduction 72 The extensions defined in this specification are mandatory for all 73 DIAMETER extensions operating over a non-reliable transport (e.g. 74 UDP). 76 1.1 Definitions 78 In this document, several words are used to signify the requirements 79 of the specification. These words are often capitalized. 81 MUST This word, or the adjective "required", means that the 82 definition is an absolute requirement of the 83 specification. 85 MUST NOT This phrase means that the definition is an absolute 86 prohibition of the specification. 88 SHOULD This word, or the adjective "recommended", means that 89 there may exist valid reasons in particular circumstances 90 to ignore this item, but the full implications must be 91 understood and carefully weighed before choosing a 92 different course. 94 MAY This word, or the adjective "optional", means that this 95 item is one of an allowed set of alternatives. An 96 implementation which does not include this option MUST 97 be prepared to interoperate with another implementation 98 which does include the option. 100 2.0 Protocol Overview 102 This section provides a detailed overview of how reliable transport 103 can be optionally provided by DIAMETER. No negotiation mechanism for 104 determining if this optional capability is required by either peer of 105 a DIAMETER session is defined herein. The mechanism for deciding 106 this is beyond the scope of this document. 108 2.1 Flow Control 110 There are two different types of DIAMETER messages; A DIAMETER 111 message that only contains the header and no Attribute-Value Pairs 112 (AVPs) is known as a zero length body message (ZLB). ZLB messages are 113 used for explicitly acknowledging packets to the peer. Non-ZLB 114 DIAMETER messages are messages that contain AVPs and can be of any 115 type defined in [10]. 117 Two optional fields in the DIAMETER header that are important to the 118 operation of DIAMETER when it is not being run over TCP are Nr (Next 119 Received) Ns (Next Send). A single sequence number state is 120 maintained for all DIAMETER messages to a given peer. The sequence 121 number starts at 0. Each subsequent non-ZLB packet is sent with the 122 next increment of the sequence number. 124 The sequence number is thus a free running counter represented modulo 125 65536. For purposes of detecting duplication, a received sequence 126 value is considered less than or equal to the last received value if 127 its value lies in the range of the last value and its 32767 successor 128 values. For example, if the last received sequence number was 15, 129 then received packets with Ns values in the range ( 32783, ... 65535, 130 0, ... 15 ) would be considered duplicates and would be silently 131 discarded. A packet with sequence number 16 would be treated as the 132 next in-sequence packet and packets with other sequences numbers are 133 out-of-order. 135 It is an implementation decision as to whether DIAMETER Messages 136 received out-of-order are queued for later processing or silently 137 discarded. The former is recommended when possible. 139 In this document, the sequence number state for each peer is 140 represented for clarity of discussion by distinct pairs of state 141 variables, Sr and Ss. Sr represents the value of the next in-sequence 142 message expected to be received for a given session by a peer. Ss 143 represents the sequence number to be placed in the Ns field of the 144 next message sent to a given peer. Each state is initialized such 145 that the first message sent and the first message expected to be 146 received to/from each peer has an Ns value of 0. This corresponds to 147 initializing Ss and Sr to 0 for each peer. 149 As messages are sent to a given peer, Nr is set in these messages to 150 reflect one more than the Ns value of the highest (modulo 2^16) in- 151 order message received from that peer; if sent before any packet is 152 received Nr will be 0, indicating that the peer expects the next new 153 Ns value to be 0. 155 When a non-ZLB message is received with an Ns value that matches the 156 peer's current Sr value, Sr is incremented by 1 (modulo 2^16). It is 157 important to note that Sr is not modified if a message is received 158 with a value of Ns greater than the current Sr value. Retransmission 159 of lost packets will eventually provide the receiving peer with its 160 next expected message. 162 Every time a peer sends a non-ZLB message it increments its Ss value 163 for that peer by 1 (modulo 2^16). This increment takes place after 164 the current Ss value is copied to Ns in the message to be sent. New 165 outgoing messages normally include the current value of Sr for the 166 corresponding peer in their Nr field. A peer may not wish to send 167 the latest Sr value back to its peer due to congestion (i.e., its 168 receive buffer for the session is full). In this case it is 169 permissible for the peer to send back an Nr value containing the Ns 170 value of the first message in the window. It is preferable to return 171 an acknowledgment with this old Nr value rather than to withhold 172 acknowledgments entirely when the receive window is full. 174 Retransmitted messages should also include the current value of Sr in 175 their Nr field, but some implementations may choose not to update Nr 176 to avoid having to perform another hash in the Integrity-Check-Vector 177 AVP. Note that the hash would only have to be recomputed if the Nr 178 value had changed. This restriction does not apply to end-to-end 179 integrity since the Ns and Nr fields are mutable. When retransmitting 180 a message the identifier in the protocol header MUST NOT be changed. 182 When transmitting packets, a DIAMETER peer must obey the receive 183 window size offerred by its peer. The default window size is 7. A 184 DIAMETER peer MUST NOT send new packets when its peer's window is 185 closed (the number of packets unacknowledged is equal to the 186 advertised, or assumed, window size). Previously transmitted packets 187 may be retransmitted while the peer's window is closed. A peer 188 communicating via UDP can specify the window size it is providing to 189 its peer by specifying this value in the Device-Reboot-Ind message. 191 A ZLB message is used to communicate Nr and Ns fields. The Nr and the 192 Ns fields are filled in as above, but the sequence number state, Ss, 193 is not modified. Thus a ZLB message sent after a non-ZLB message will 194 contain the new Ss value while a non-ZLB message sent after a ZLB 195 message will contain the same value of Ns as the ZLB message did. 197 Upon receipt of an in-order non-ZLB message, the receiving peer must 198 increment its Sr value and may acknowledge the message by sending 199 back the updated value of Sr in the Nr field of the next outgoing 200 message. This updated Sr value can be piggybacked in the Nr field of 201 any outgoing messages that the peer may happen to send back. 203 If a peer does not have a message queued to transmit at the time a 204 non-ZLB message is received then it should delay a short time before 205 sending a ZLB message containing the latest values of Sr and Ss, as 206 described above. This short delay is to allow for the possible 207 arrival of a message to be transmitted back to its peer, thus 208 avoiding the need to issue a ZLB. The suggested value for this time 209 delay is 1/4 the receiving peer's value of Round-Trip-Time (RTT - see 210 Appendix A), if it computes RTT, or a maximum of 1/2 of its fixed 211 acknowledgment timeout interval otherwise. This timeout should 212 provide a reasonable opportunity for the receiving peer to obtain a 213 payload message destined for its peer, upon which the ACK of the 214 received message can be piggybacked. Note that if a peer's window is 215 full, it MAY advertise an older Nr value if it is not ready to accept 216 new messages. 218 This delay value should be treated as a suggested maximum; an 219 implementation could make this delay quite small without adversely 220 affecting the protocol. The default time delay is 2 seconds. To 221 provide for better throughput, the receiving peer should skip this 222 delay entirely and send a ZLB message immediately in the case where 223 its receive window is filled and it has no queued data to send for 224 this connection or it can't send queued data because the transmit 225 window is closed. 227 See Appendix B for some examples of how sequence numbers progress. 229 2.2 Suggested implementation 231 A suggested implementation of this delay is as follows: Upon 232 receiving a non-ZLB message, the receiver starts a timer that will 233 expire in the recommended time interval. A variable, Lr (Last Nr 234 value sent), is used by the transmitter to store the last value sent 235 in the Nr field of a transmitted payload message for this connection. 236 Upon expiration of this timer, Sr is compared to Lr and, if they are 237 not equal, a ZLB ACK is issued. If they are equal, then no ACK's are 238 outstanding and no action needs to be taken. 240 This timer should not be reinitialized if a new message is received 241 while it is active since such messages will be acknowledged when the 242 timer expires. This ensures that periodic ACK's are issued with a 243 maximum period equal to the recommended delay time interval. This 244 interval should be short enough to not cause false acknowledgement 245 timeouts at the transmitter when payload messages are being sent in 246 one direction only. Since such ACK's are being sent on what would 247 otherwise be an idle data path, their affect on performance should be 248 small, of not negligible. 250 In order for a DIAMETER implementation to be able to retransmit 251 messages, it MUST queue transmitted messages until the messages are 252 acknowledged. It must also maintain a retransmission timer that 253 determines when to assume that either a sent message did not arrive 254 at the peer or the acknowledgment sent by the peer was lost. See 255 Appendix A for a recommended retransmit timer implementation. There 256 are two recommended methods for implementing the retransmission 257 procedure. One method is for the sender to resend the entire window 258 of unacknowledged messages when the retransmit timeout expires. This 259 is the simplest method, but is inefficient when a receiver is not 260 rotating the window due to congestion. The alternative method is to 261 only resend the first message in the window (the first unacknowledged 262 message) until an acknowledgment is received. This acknowledgment 263 will indicate to the receiver the next, if any, message in the 264 current window that needs to be retransmitted. A particular 265 implementation may use either or both methods if desired. 267 When a DIAMETER node has retransmitted a message to a given peer the 268 maximum number of times (the recommended value is 3), it may send the 269 request to an alternate DIAMETER server. This procedure may continue 270 until either all of the servers have been tried, or the node 271 selectively issues a failure to the requestor. 273 2.3 Peer failure recovery 275 A DIAMETER message with the Command-Code AVP set to Device-Reboot-Ind 276 and the Ns and Nr values set to zero (0) indicates that the peer has 277 rebooted. This message MUST be recognized and supported by a 278 DIAMETER implementation. When this event occurs, the Ss and Sr values 279 must be reset and the retransmission queue MUST be cleared. Since the 280 protocol requires that all new messages include a random identifier 281 in the protocol header, a Device-Reboot-Ind that is received with the 282 same identifier as the last processed Device-Reboot-Ind is considered 283 a retransmission and SHOULD NOT change the peer's state to inactive. 285 Messages other than the Device-Reboot-Ind MUST NOT be sent to the 286 peer until both the acknowledgement for the transmitted Device- 287 Reboot-Ind AND the peer's Device-Reboot-Ind have been received. When 288 both of these have been received, the peer is considered to be in the 289 active state. 291 3.0 Extended Header Format 293 The DIAMETER Base Protocol [12] assumes that the underlying transport 294 is reliable (e.g. TCP). This section defines the optional fields in 295 the DIAMETER header that allow DIAMETER to provide reliability. 297 See [12] for a full description of the header fields not introduced 298 in this document. 300 A summary of the DIAMETER data format is shown below. The fields are 301 transmitted from left to right. 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | RADIUS PCC |Flags|A|W| Ver | Packet Length | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Identifier | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Next Send (Ns) | Next Received (Nr) | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | AVPs ... 313 +-+-+-+-+-+-+-+-+-+-+-+-+- 315 PKT Flags 317 The Packet Flags field is five bits, and is used in order to 318 identify any options. This field MUST be initialized to zero. The 319 following flags may be set: 321 The 'W' bit (Window-Present) is set when the Next Send (Ns) and 322 Next Received (Nr) fields are present in the header. This 323 SHOULD be set unless the underlying layer provides reliability 324 (i.e. TCP). 326 The 'A' bit is set to indicate that the packet is an 327 acknowledgement only and does not contain a Command-Code AVP 328 following the header. Note that the Security AVPs MUST still be 329 present within an acknowledgment message. 331 Next Send 333 This field is present when the Window-Present bit is set in the 334 header flags. The Next Send (Ns) is copied from the send sequence 335 number state variable, Ss, at the time the message is transmitted. 336 Ss is incremented after copying if the message is not a ZLB ACK. 338 Next Received 340 This field is present when the Window-Present bit is set in the 341 header flags. Nr is copied from the receive sequence number state 342 variable, Sr, and indicates the sequence number, Ns, +1 of the 343 highest (modulo 2^16) in-sequence message received. See section 344 2.0 for more information. 346 4.0 DIAMETER AVPs 348 This section defines a mandatory AVP which MUST be supported by all 349 DIAMETER implementations supporting this extension. 351 The following AVP is defined in this document: 353 Attribute Name Attribute Code 354 ----------------------------------- 355 Receive-Window 277 357 4.1 Receive-Window 359 Description 361 This AVP is used by a peer to inform its peer of its local receive 362 window size. The size indicated is the number of packets that it 363 is willing to accept before the window is full. 365 A sending peer MUST stop sending new DIAMETER messages when this 366 many messages are outstanding (sent but not yet acknowledged). 368 If a peer does not issue this attribute, a receive window size of 369 7 is assumed by its peer. 371 This attribute is only valid in the Device-Reboot-Ind message. 373 AVP Format 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | AVP Code | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | AVP Length | Reserved |P|T|V|E|H|M| 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Integer32 | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 AVP Code 386 277 Receive-Window 388 AVP Length 390 The length of this attribute MUST be 12. 392 AVP Flags 394 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 395 upon the security model used. The 'V', 'T' and the 'P' bits 396 MUST NOT be set. 398 Integer32 400 This field contains the receive window size. 402 5.0 References 404 [1] Reynolds, Postel, "Assigned Numbers", RFC 1700, 405 October 1994. 406 [2] Postel, "User Datagram Protocol", RFC 768, August 1980. 407 [3] Calhoun, Zorn, Pan, "DIAMETER Framework", Internet- 408 Draft, draft-calhoun-diameter-framework-00.txt, May 1998 409 [4] Calhoun, Rubens, "DIAMETER Base Protocol", Internet-Draft, 410 draft-calhoun-diameter-05.txt, May 1998. 411 [5] K. Hamzeh, T. Kolar, M. Littlewood, G. Singh Pall, J. Taarud, 412 A. J. Valencia, W. Verthein, W.M. Townsley, B. Palter, 413 A. Rubens "Layer Two Tunneling Protocol (L2TP)", 415 6.0 Acknowledgements 417 The Authors would like to acknowledge the following people for their 418 contribution in the development of the DIAMETER protocol: 420 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 421 Nancy Greene, Peter Heitman, Ryan Moats, Victor Muslin, Kenneth 422 Peirce, Sumit Vakil, John R. Vollbrecht, Jeff Weisberg and Glen Zorn 424 The authors would also like to thank the authors of the L2TP spec 425 since most of the windowing text in this draft was shamefully copied 426 from that spec. 428 7.0 Author's Address 430 Questions about this memo can be directed to: 432 Pat R. Calhoun 433 Technology Development 434 Sun Microsystems, Inc. 435 15 Network Circle 436 Menlo Park, California, 94025 437 USA 439 Phone: 1-650-786-7733 440 Fax: 1-650-786-6445 441 E-mail: pcalhoun@eng.sun.com 443 Allan C. Rubens 444 Ascend Communications 445 1678 Broadway 446 Ann Arbor, MI 48105-1812 447 USA 449 Phone: 1-734-761-6025 450 E-Mail: acr@del.com 452 Appendix A: Acknowledgment Timeouts 454 DIAMETER uses sliding windows and timeouts to provide flow-control 455 across the underlying medium and to perform efficient data buffering 456 to keep two DIAMETER peers' receive window full without causing 457 receive buffer overflow. DIAMETER requires that a timeout be used to 458 recover from dropped packets. 460 When the timeout for a peer expires, the previously transmitted 461 message with Ns value equal to the highest in-sequence value of Nr 462 received from the peer is retransmitted. The receiving peer does not 463 advance its value for the receive sequence number state, Sr, until it 464 receives a message with Ns equal to its current value of Sr. 466 This rule assures that all subsequent acknowledgements to this peer 467 will contain an Nr value equal to the Ns value of the first missing 468 message until a message with the missing Ns value is received. 470 The exact implementation of the acknowledgment timeout is vendor- 471 specific. It is suggested that an adaptive timeout be implemented 472 with backoff for flow control. The timeout mechanism proposed here 473 has the following properties: 475 Independent timeouts for each peer. A device will have to 476 maintain and calculate timeouts for every active peer. 478 An administrator-adjustable maximum timeout, MaxTimeOut, unique to 479 each device. 481 An adaptive timeout mechanism that compensates for changing 482 throughput. To reduce packet processing overhead, vendors may 483 choose not to recompute the adaptive timeout for every received 484 acknowledgment. The result of this overhead reduction is that the 485 timeout will not respond as quickly to rapid network changes. 487 Timer backoff on timeout to reduce congestion. The backed-off 488 timer value is limited by the configurable maximum timeout value. 489 Timer backoff is done every time an acknowledgment timeout occurs. 491 In general, this mechanism has the desirable behavior of quickly 492 backing off upon a timeout and of slowly decreasing the timeout value 493 as packets are delivered without errors. 495 A.1 Calculating Adaptive Acknowledgment Timeout 497 We must decide how much time to allow for acknowledgments to return. 498 If the timeout is set too high, we may wait an unnecessarily long 499 time for dropped packets. If the timeout is too short, we may time 500 out just before the acknowledgment arrives. The acknowledgment 501 timeout should also be reasonable and responsive to changing network 502 conditions. 504 The suggested adaptive algorithm detailed below is based on the TCP 505 1989 implementation and is explained in Richard Steven's book TCP/IP 506 Illustrated, Volume 1 (page 300). 'n' means this iteration of the 507 calculation, and 'n-1' refers to values from the last calculation. 509 DIFF[n] = SAMPLE[n] - RTT[n-1] 510 DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) 511 RTT[n] = RTT[n-1] + (alpha * DIFF[n]) 512 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 514 DIFF represents the error between the last estimated round-trip 515 time and the measured time. DIFF is calculated on each iteration. 517 DEV is the estimated mean deviation. This approximates the 518 standard deviation. DEV is calculated on each iteration and 519 stored for use in the next iteration. Initially, it is set to 0. 521 RTT is the estimated round-trip time of an average packet. RTT is 522 calculated on each iteration and stored for use in the next 523 iteration. Initially, it is set to PPD. 525 ATO is the adaptive timeout for the next transmitted packet. ATO 526 is calculated on each iteration. Its value is limited, by the MIN 527 function, to be a maximum of the configured MaxTimeOut value. 529 Alpha is the gain for the round trip estimate error and is 530 typically 1/8 (0.125). 532 Beta is the gain for the deviation and is typically 1/4 (0.250). 534 Chi is the gain for the timeout and is typically set to 4. 536 To eliminate division operations for fractional gain elements, the 537 entire set of equations can be scaled. With the suggested gain 538 constants, they should be scaled by 8 to eliminate all division. To 539 simplify calculations, all gain values are kept to powers of two so 540 that shift operations can be used in place of multiplication or 541 division. The above calculations are carried out each time an 542 acknowledgment is received for a packet that was not retransmitted 543 (no timeout occured). 545 A.2 Flow Control: Adjusting for Timeout 546 This section describes how the calculation of ATO is modified in the 547 case where a timeout does occur. When a timeout occurs, the timeout 548 value should be adjusted rapidly upward. To compensate for shifting 549 internetwork time delays, a strategy must be employed to increase the 550 timeout when it expires. A simple formula called Karn's Algorithm is 551 used in TCP implementations and may be used in implementing the 552 backoff timers for the DIAMETER peers. Notice that in addition to 553 increasing the timeout, we also shrink the size of the window as 554 described in the next section. 556 Karn's timer backoff algorithm, as used in TCP, is: 558 NewTIMEOUT = delta * TIMEOUT 560 Adapted to our timeout calculations, for an interval in which a 561 timeout occurs, the new timeout interval ATO is calculated as: 563 RTT[n] = delta * RTT[n-1] 564 DEV[n] = DEV[n-1] 565 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 567 In this modified calculation of ATO, only the two values that 568 contribute to ATO and that are stored for the next iteration are 569 calculated. RTT is scaled by delta, and DEV is unmodified. DIFF is 570 not carried forward and is not used in this scenario. A value of 2 571 for Delta, the timeout gain factor for RTT, is suggested. 573 Appendix B: Examples of sequence numbering 575 This appendix uses several common scenarios to illustrate how 576 sequence number state progresses and is interpreted. 578 B.1 Lock-step session establishment 580 In this example, a DIAMETER host establishes communication with a 581 peer, with the exchange involving each side alternating in the 582 sending of messages. This example is contrived, in that the final 583 acknowledgement typically would be included in the Device-Watchdog- 584 Ind message. 586 DIAMETER Host A DIAMETER Host B 587 -> Device-Reboot-Ind 588 Nr: 0, Ns: 0 590 (ZLB) <- 591 Nr: 1, Ns: 0 593 -> Device-Watchdog-Ind 594 Nr: 0, Ns: 1 596 (delay) 598 (ZLB) <- 599 Nr: 2, Ns: 0 601 B.2 Multiple packets acknowledged 603 This example shows a flow of packets from DIAMETER Host B to Host A, 604 with Host A having no traffic of its own. Host A is waiting 1/4 of 605 its timeout interval, and then acknowledging all packets seen since 606 the last interval. 608 DIAMETER Host A DIAMETER Host B 609 (previous packet flow precedes this) 611 -> (ZLB) 612 Nr: 7000, Ns: 1000 613 (non-ZLB) <- 614 Nr: 1000, Ns: 7000 615 (non-ZLB) <- 616 Nr: 1000, Ns: 7001 617 (non-ZLB) <- 618 Nr: 1000, Ns: 7002 620 (Host A's timer indicates it should acknowledge pending 621 traffic) 623 -> (ZLB) 624 Nr: 7003, Ns: 1000 626 B.3 Lost packet with retransmission 628 Host A attempts to communicate with Host B. The Device-Reboot-Ind 629 sent from B to A is lost and must be retransmitted by Host B. 631 DIAMETER Host A DIAMETER Host B 632 -> Device-Reboot-Ind 633 Nr: 0, Ns: 0 635 (packet lost) Device-Reboot-Ind <- 636 Nr: 1, Ns: 0 638 (pause; Host A's timer started first, so fires first) 639 -> Device-Reboot-Ind 640 Nr: 0, Ns: 0 642 (Host B realizes it has already seen this packet) 643 (Host B might use this as a cue to retransmit, as in this 644 example) 646 Device-Reboot-Ind <- 647 Nr: 1, Ns: 0 648 -> Device-Watchdog-Ind 649 Nr: 1, Ns: 1 651 (delay) 653 (ZLB) <- 654 Nr: 2, Ns: 1