idnits 2.17.1 draft-ietf-tsvwg-tcp-eifel-alg-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** The abstract seems to contain references ([WS95], [RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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) == Unused Reference: 'RFC1122' is defined on line 402, but no explicit reference was found in the text == Unused Reference: 'RFC793' is defined on line 450, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) -- Possible downref: Non-RFC (?) normative reference: ref. 'BA01a' -- Possible downref: Non-RFC (?) normative reference: ref. 'BA01b' ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 2582 (Obsoleted by RFC 3782) -- Possible downref: Non-RFC (?) normative reference: ref. 'Gu01' -- Possible downref: Non-RFC (?) normative reference: ref. 'GL01' -- Possible downref: Non-RFC (?) normative reference: ref. 'KP87' -- Possible downref: Non-RFC (?) normative reference: ref. 'LK00' -- Possible downref: Non-RFC (?) normative reference: ref. 'LM01' -- Possible downref: Non-RFC (?) normative reference: ref. 'LG01' ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. 'WS95' Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Reiner Ludwig 3 INTERNET-DRAFT Ericsson Research 4 Expires: May 2002 November, 2001 6 The Eifel Algorithm for TCP 7 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute 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 cite them other than as "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/lid-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Abstract 31 A solution to eliminate the retransmission ambiguity in TCP, is to 32 mark ACKs with a special retransmit-marker. The marker would need to 33 be present in those ACKs, and only those ACKs, that the TCP receiver 34 sends in response to retransmits; both genuine and spurious 35 retransmits. Based on such a retransmit-marker, the Eifel algorithm 36 allows the TCP sender to detect a posteriori that a fast retransmit 37 or a timeout was spurious. Three alternative retransmit-markers are 38 defined in this document, and the Eifel algorithm may be based on 39 either one of them: the TCP RXT flag, the TCP Timestamps option, and 40 the TCP SACK option. The Eifel algorithm provides a basis for future 41 TCP enhancements such as response schemes that may change a TCP 42 sender's protocol state to improve end-to-end performance. 44 Terminology 46 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 47 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 48 document, are to be interpreted as described in [RFC2119]. 50 We use the term 'new ACK' to refer to an ACK that acknowledges 51 outstanding data. We use the term 'duplicate' ACK as defined in 52 [WS95]. Furthermore, we refer to the first-time transmission of a 53 data segment as the 'original transmit', and 'HighData' is the 54 highest sequence number transmitted at a given point. 56 1. Introduction 58 The retransmission ambiguity problem [KP87] is the TCP sender's 59 inability to distinguish whether the first new ACK that arrives after 60 a retransmit was sent in response to the original transmit or the 61 retransmit. A solution to eliminate the retransmission ambiguity is 62 to mark ACKs with a special "retransmit-marker". The marker would 63 need to be present in those ACKs, and only those ACKs, that the TCP 64 receiver sends in response to retransmits; both genuine and spurious 65 retransmits. 67 Based on such a retransmit-marker, the Eifel algorithm allows the TCP 68 sender to detect a posteriori that a fast retransmit or a timeout was 69 spurious. This added capability of the TCP sender is useful in 70 environments where TCP's loss recovery and congestion control 71 algorithms may often get falsely triggered. Packet reordering, packet 72 duplication, or a sudden delay increase in the data or the ACK path 73 that results in a spurious timeout can cause this. For example, such 74 sudden delay increases can often occur in wide-area wireless access 75 networks due to handovers, resource preemption, or because the mobile 76 transmitter traverses through a radio coverage hole (e.g., see 77 [Gu01]). 79 Based on the Eifel algorithm, the TCP sender may then choose to 80 implement dedicated response schemes. One goal of such a scheme would 81 be to alleviate the consequences of a falsely triggered loss recovery 82 phase. For example, an important feature of the scheme proposed in 83 [LG01] is that it avoids the spurious go-back-N retransmits that 84 typically occur after a spurious timeout. Another goal would be to 85 "upgrade" the congestion control parameters, the congestion window 86 and slow start threshold [RFC2581]. This is to compensate for the 87 unnecessary reduction of their values when the loss recovery was 88 falsely triggered. Yet, another goal would be to adapt other protocol 89 parameters, e.g., the duplicate acknowledgement threshold [RFC2581], 90 and the RTT estimators [RFC2988]. This is to reduce the risk of 91 falsely triggering TCP's loss recovery again in the future. However, 92 such response schemes are outside the scope of this document. They 93 are addressed in different documents (e.g., see [LG01] and [BA01a]). 95 A key feature of the Eifel algorithm is that it already detects upon 96 the first new ACK that arrives during a loss recovery phase that a 97 fast retransmit or a timeout was spurious. This is crucial to be able 98 to avoid the mentioned spurious go-back-N retransmits. Another 99 feature is that the Eifel algorithm is fairly robust against ACK 100 losses. Especially, the loss of the single ACK carrying the 101 retransmit-marker does not affect the functioning of the Eifel 102 algorithm. 104 2. Spurious Retransmits 106 The following events falsely trigger a TCP sender's loss recovery and 107 congestion control algorithms. This causes a so-called spurious 108 retransmit, and an unnecessary reduction of the TCP sender's 109 congestion window. 111 - Spurious timeouts 113 - Packet reordering 115 - Packet duplication 117 A spurious timeout is a timeout that would not have occurred had the 118 sender "waited longer". It may be caused by increased delay that 119 suddenly occurs in the data or the ACK path. This in turn might cause 120 an ACK to arrive too late, i.e., only after the TCP sender's 121 retransmission timer has expired. This would then trigger a spurious 122 retransmit. Note that the mentioned ACK could either be a new ACK 123 that would acknowledge the oldest outstanding segment, or it could be 124 the third duplicate ACK that would have triggered a fast retransmit 125 of the oldest outstanding segment [RFC2581]. Note: In the latter case 126 the sender should suppress the fast retransmit that the third 127 duplicate ACK would usually trigger. In general, a TCP sender should 128 ignore all duplicate ACKs that arrive after a timeout [GL01]. 130 Packet reordering in the network may occur because IP [RFC791] is a 131 connection-less protocol. Thus, IP does not guarantee an in-order 132 delivery of packets. This results in a spurious fast retransmit if 133 three or more data segments arrive out-of-order at the TCP receiver, 134 and at least three of the resulting duplicate ACKs arrive at the TCP 135 sender. This is because a TCP receiver generates a duplicate ACK for 136 each segment that arrives out-of-order, and three consecutive 137 duplicate ACKs trigger the TCP sender's fast retransmit algorithm. 139 Packet duplication in the network may also occur because IP is 140 connection-less. That is, the receiving IP does not (cannot) remove 141 duplicate packets. A TCP receiver in turn also generates a duplicate 142 ACK for each duplicate segment. As with packet reordering, this 143 results in a spurious fast retransmit if duplication of data segments 144 or ACKs results in three or more duplicate ACKs to arrive at the TCP 145 sender. 147 The negative impact on TCP performance caused by packet reordering 148 and packet duplication is commonly the same: a single spurious 149 retransmit (the fast retransmit), and the unnecessary halving of the 150 TCP sender's congestion window as a result of the subsequent fast 151 recovery phase [RFC2581]. 153 The negative impact on TCP performance caused by a spurious timeout 154 is more severe. First, the timeout event itself causes a single 155 spurious retransmit, and unnecessarily forces the TCP sender into 156 slow start [RFC2581]. Then, as the connection progresses, a chain 157 reaction gets triggered that further decreases TCP's performance. 158 Since the timeout was spurious, at least some ACKs for original 159 transmits will typically arrive at the TCP sender before the ACK for 160 the retransmit arrives. (This is unless severe packet reordering 161 coincided with the spurious timeout in such a way that the ACK for 162 the retransmit is the first new ACK to arrive at the TCP sender.) 163 Those ACKs for original transmits will then trigger an implicit go- 164 back-N loss recovery at the TCP sender. Assuming that none of the 165 outstanding segments and none of the corresponding ACKs were lost, 166 all outstanding segments will get retransmitted unnecessarily. 167 Moreover, this will then typically cause a spurious fast retransmit. 168 This is because the spurious go-back-N retransmits will arrive as 169 duplicates at the TCP receiver, which in turn triggers a series of 170 duplicate ACKs. Note that this last spurious fast retransmit could be 171 avoided with the careful variant of 'bug fix' [RFC2582]. 173 More detailed explanations including TCP trace plots that visualize 174 the effects of packet reordering and spurious timeouts can be found 175 in [LK00]. 177 3. The Eifel Algorithm 179 3.1 The Idea 181 As mentioned before, a solution to eliminate the retransmission 182 ambiguity in TCP, is to mark ACKs with a special retransmit-marker. 183 The marker would need to be present in those ACKs, and only those 184 ACKs, that the TCP receiver sends in response to retransmits; both 185 genuine and spurious retransmits. Based on such a retransmit-marker, 186 the Eifel algorithm allows the TCP sender to detect a posteriori that 187 a fast retransmit or a timeout was spurious. 189 [Note: The Eifel algorithm as defined here is a pure detection 190 mechanism. The original proposal of the Eifel algorithm [LK00] 191 included the TCP sender's response to a detected spurious 192 retransmit, and a marking scheme that allows a TCP sender to 193 distinguish an ACK for an original transmit from that of a 194 retransmit. Such response and marking schemes are addressed in 195 different documents [RFC2883], [BA01a], [BA01b], [LM01], 196 [LG01].] 198 The key idea of the Eifel algorithm is to let the TCP sender take the 199 absence of a retransmit-marker in the first new ACK that arrives 200 after a retransmit as sufficient evidence that the loss recovery 201 phase was falsely triggered. Being able to make this decision upon 202 the first new ACK is crucial for response schemes such as [LG01] to 203 avoid the spurious go-back-N retransmits that typically occur after a 204 spurious timeout. 206 However, making this decision upon the first new ACK is not 207 absolutely reliable. A counter-example can be constructed where this 208 approach fails: 210 In case the original transmit was in fact dropped in the 211 network, a new ACK that arrives after a retransmit would also 212 not carry a retransmit-marker if (1) the retransmit arrived at 213 the TCP receiver in sequence, i.e., if it had jumped ahead of 214 all data segments that were outstanding when the retransmit was 215 sent, and if (2) the ACK for the retransmit carrying the 216 retransmit-marker got lost. In that case the mentioned new ACK 217 would correspond to one of the data segments that were 218 outstanding when the retransmit was sent. Note: This example 219 holds independent of whether the loss recovery phase was 220 triggered by the arrival of the third duplicate ACK or by a 221 timeout. Note also: in case the SACK option is used as the 222 retransmit-marker (see Section 3.2 and 3.4), condition (2) is 223 not required. 225 Nevertheless, this counter-example is regarded as being a rather 226 pathological case. In addition, it seems to be the only conceivable 227 counter-example. Therefore, it is regarded as sufficiently safe to 228 take the absence of a retransmit-marker in the first new ACK that 229 arrives after a retransmit as the signal that the TCP sender falsely 230 entered the loss recovery phase. 232 This approach makes the Eifel algorithm fairly robust against ACK 233 losses. This is because a number of ACKs that do not carry the 234 retransmit-marker are commonly in flight during a falsely triggered 235 loss recovery phase. The arrival of at least one of those ACKs would 236 be sufficient for the Eifel algorithm to make a decision. Also, the 237 loss of the single ACK carrying the retransmit-marker does not affect 238 the functioning of the Eifel algorithm. 240 Three alternative retransmit-markers are defined in this document, 241 and the Eifel algorithm may be based on either one of them: 243 (1) the TCP RXT flag [LM01], 244 (2) the TCP Timestamps option [RFC1323], and 246 (3) the TCP SACK option [RFC2018]. 248 The exact use of those markers is specified in the following 249 subsections. The RXT flag is the most efficient retransmit-marker 250 since it does not enlarge TCP segments or ACKs by an option. Unlike 251 for the RXT flag and the Timestamps option, the SACK option has the 252 drawback that it can only detect whether a fast retransmit was 253 spurious. It cannot be used to detect spurious timeouts as explained 254 in Section 3.4. 256 Note: The DSACK option [RFC2883] is not an appropriate retransmit- 257 marker that would allow to eliminate the retransmission ambiguity. 258 The reason is that the first new ACK that arrives after a retransmit 259 will commonly not carry a DSACK option. That is, the DACK option 260 commonly arrives one or more ACKs later than the first new ACK for a 261 retransmit. This is independent of whether the retransmit was genuine 262 or spurious. 264 Given that both the TCP sender and receiver support the RXT flag, or 265 the Timestamps option, or the SACK option, a TCP sender MAY implement 266 the Eifel algorithm as defined in the following subsections. 268 3.2 The Algorithm 270 The following steps MUST be taken by the TCP sender when the third 271 duplicate ACK arrives or a timeout occurs, i.e., when a loss recovery 272 phase starts: 274 (1) Set a "SpuriousRecovery" variable to 'false'. If this 275 variable is true at step (7) below, the loss recovery 276 phase had been falsely triggered. 278 (2) Set a "RecoveryPoint" variable to HighData. When the TCP 279 sender receives the first new ACK for this data octet the 280 loss recovery phase is terminated. 282 (3-TS) This step only applies when the Timestamps option is used 283 as the retransmit-marker: Set a "RetransmitTS" variable 284 to the value of the Timestamp Value field of the 285 Timestamps option included in the first retransmit. A TCP 286 sender MUST ensure that RetransmitTS does not get 287 overwritten as the loss recovery phase progresses, e.g., 288 in case of a second timeout and subsequent second 289 retransmit of the same octet. 291 The following steps MUST be taken by the TCP sender when the first 292 new ACK arrives after the loss recovery phase started: 294 (4) If the ACK's sequence number is greater than the value of 295 RecoveryPoint , proceed to step (7) below. This condition 296 ensures that only those ACKs are considered that 297 correspond to segments that were outstanding at the time 298 the retransmit was sent. 300 (5-SACK) This step only applies when the SACK option is used as 301 the retransmit-marker: If the ACK's sequence number is 302 equal to the value of RecoveryPoint, proceed to step (7) 303 below. This step is motivated in Section 3.4. 305 (6-RXT) This step only applies when the RXT flag is used as the 306 retransmit-marker: If the ACK does not have the RXT flag 307 set (binary 1), set SpuriousRecovery to 'true' and 308 proceed to step (7) below. 310 (6-TS) This step only applies when the Timestamps option is used 311 as the retransmit-marker: If the value of the Timestamp 312 Echo Reply field of the ACK's Timestamps option is 313 smaller than RetransmitTS, set SpuriousRecovery to 'true' 314 and proceed to step (7) below. This step is commented in 315 Section 3.3. 317 (6-SACK) This step only applies when the SACK option is used as 318 the retransmit-marker, and only if the loss recovery 319 phase had been triggered by the arrival of the third 320 duplicate ACK: If the ACK does not carry a SACK option, 321 set SpuriousRecovery to 'true' and proceed to step (7) 322 below. This step is motivated in Section 3.4. 324 (7) Done. No further processing. 326 3.3 Comments to the Timestamp-based Detection 328 The comparison operator "smaller than" in step (6-TS) is 329 conservative. In theory, when the "timestamp clock" is slow or the 330 network is fast, RetransmitTS could at most be equal to the timestamp 331 echoed by an ACK sent in response to an original transmit. In that 332 case, it is assumed that the loss recovery was not falsely triggered. 334 3.4 Comments to the SACK-based Detection 336 The SACK option is not a retransmit-marker in the sense that it is 337 present only in those ACKs that the TCP receiver sends in response to 338 retransmits (see Section 3.1). This is why the SACK option cannot be 339 used to detect that a timeout was spurious. For this, we only need to 340 consider the case where an entire flight of segments was lost versus 341 the case of a spurious timeout. Assuming that packet reordering did 342 not concur, the first new ACK arriving after the retransmit would not 343 carry a SACK option in either case. Thus, the retransmission 344 ambiguity problem would still exist. 346 Nevertheless, the SACK option can be used to detect that a fast 347 retransmit was spurious. Let's assume a SACK-enabled TCP receiver. If 348 only a single segment was in fact lost, then the first new ACK that 349 arrives after the fast retransmit will not carry a SACK option, and 350 will acknowledge RecoveryPoint. If multiple segments were in fact 351 lost, then the first new ACK that arrives after the fast retransmit 352 will carry a SACK option, and will acknowledge below RecoveryPoint, 353 i.e., the ACK will be partial. Thus, partial ACKs that do not carry a 354 SACK option are impossible independent of how many segments were 355 lost. Conversely, the first new ACK after the fast retransmit that is 356 a partial ACK and that does not carry a SACK option, signals that the 357 loss recovery phase was falsely triggered. This motivates steps (5- 358 SACK) and (6-SACK) in Section 3.2. 360 Note: The SACK option cannot be used to detect that a fast retransmit 361 was spurious when the entire flight of segments jumps ahead of the 362 first segment (the oldest outstanding segment) of that flight. This 363 is because the resulting new ACK would not carry a SACK option but 364 would acknowledge RecoveryPoint. Thus, step (5-SACK) in Section 3.2 365 would become effective. 367 4. Security Considerations 369 There do not seem to be any security considerations associated with 370 the Eifel algorithm itself. This is because the Eifel algorithm is 371 only a detection scheme that is not tied to any specific action that 372 might alter existing protocol state at the TCP sender or receiver. 373 That is, no value of a state variable other than one introduced by 374 the algorithm itself (SpuriousRecovery, RecoverPoint, and 375 RetransmitTS) is changed. 377 However, security considerations might exist for response schemes 378 that use the Eifel algorithm as a basis. In particular, it needs to 379 be considered that the TCP receiver might by lying about the 380 retransmit-marker. 382 Acknowledgments 384 Many thanks to Keith Sklower, Randy Katz, Michael Meyer, Stephan 385 Baucke, Sally Floyd, Vern Paxson, Mark Allman, Ethan Blanton, and 386 Andrei Gurtov for very useful discussions that contributed to this 387 work. 389 References 391 [RFC2581] M. Allman, V. Paxson, W. Stevens, TCP Congestion Control, 392 RFC 2581, April 1999. 394 [BA01a] E. Blanton, M. Allman, Adjusting the Duplicate ACK 395 Threshold to Avoid Spurious Retransmits, work in progress, 396 July 2001. 398 [BA01b] E. Blanton, M. Allman, Using TCP DSACKs and SCTP Duplicate 399 TSNs to Detect Spurious Retransmissions, work in progress, 400 August 2001. 402 [RFC1122] R. Braden, Requirements for Internet Hosts - Communication 403 Layers, RFC 1122, October 1989. 405 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 406 Requirement Levels, RFC 2119, March 1997. 408 [RFC1323] V. Jacobson, R. Braden, D. Borman, TCP Extensions for High 409 Performance, RFC 1323, May 1992. 411 [RFC2018] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, TCP Selective 412 Acknowledgement Options, RFC 2018, October 1996. 414 [RFC2582] S. Floyd, T. Henderson, The NewReno Modification to TCP's 415 Fast Recovery Algorithm, RFC 2582, April 1999. 417 [RFC2883] S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky, A. Romanow, 418 An Extension to the Selective Acknowledgement (SACK) Option 419 for TCP, RFC 2883, July 2000. 421 [Gu01] A. Gurtov, Effect of Delays on TCP Performance, In 422 Proceedings of IFIP Personal Wireless Communications, 423 August 2001. 425 [GL01] A. Gurtov, R. Ludwig, Making TCP Robust Against Delay 426 Spikes, work in progress, November 2001. 428 [KP87] P. Karn, C. Partridge, Improving Round-Trip Time Estimates 429 in Reliable Transport Protocols, In Proceedings of ACM 430 SIGCOMM 87. 432 [LK00] R. Ludwig, R. H. Katz, The Eifel Algorithm: Making TCP 433 Robust Against Spurious Retransmissions, ACM Computer 434 Communication Review, Vol. 30, No. 1, January 2000, 435 available at http://www.acm.org/sigcomm/ccr/archive/2000/ 436 jan00/ccr-200001-ludwig.html (easier studied when 437 viewed/printed in color). 439 [LM01] R. Ludwig, M. Meyer, The TCP Retransmit (RXT) Flag, work in 440 progress, November 2001. 442 [LG01] R. Ludwig, A. Gurtov, Responding to Spurious Timeouts in 443 TCP, work in progress, November 2001. 445 [RFC2988] V. Paxson, M. Allman, Computing TCP's Retransmission Timer, 446 RFC 2988, November 2000. 448 [RFC791] J. Postel, Internet Protocol, RFC 791, September 1981. 450 [RFC793] J. Postel, Transmission Control Protocol, RFC793, September 451 1981. 453 [WS95] G. R. Wright, W. R. Stevens, TCP/IP Illustrated, Volume 2 454 (The Implementation), Addison Wesley, January 1995. 456 Author's Address 458 Reiner Ludwig 459 Ericsson Research (EED) 460 Ericsson Allee 1 461 52134 Herzogenrath, Germany 462 Phone: +49 2407 575 719 463 Fax: +49 2407 575 400 464 Email: Reiner.Ludwig@Ericsson.com 466 This Internet-Draft expires in May 2002.