idnits 2.17.1 draft-ietf-tcpm-rtorestart-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2014) is 3577 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'SEG 1' is mentioned on line 163, but not defined == Missing Reference: 'SEG 2' is mentioned on line 164, but not defined == Missing Reference: 'SEG 3' is mentioned on line 169, but not defined ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions (tcpm) P. Hurtig 3 Internet-Draft A. Brunstrom 4 Intended status: Experimental Karlstad University 5 Expires: January 5, 2015 A. Petlund 6 Simula Research Laboratory AS 7 M. Welzl 8 University of Oslo 9 July 4, 2014 11 TCP and SCTP RTO Restart 12 draft-ietf-tcpm-rtorestart-03 14 Abstract 16 This document describes a modified algorithm for managing the TCP and 17 SCTP retransmission timers that provides faster loss recovery when 18 there is a small amount of outstanding data for a connection. The 19 modification, RTO Restart (RTOR), allows the transport to restart its 20 retransmission timer more aggressively in situations where fast 21 retransmit cannot be used. This enables faster loss detection and 22 recovery for connections that are short-lived or application-limited. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 5, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 1. Introduction 58 TCP uses two mechanisms to detect segment loss. First, if a segment 59 is not acknowledged within a certain amount of time, a retransmission 60 timeout (RTO) occurs, and the segment is retransmitted [RFC6298]. 61 While the RTO is based on measured round-trip times (RTTs) between 62 the sender and receiver, it also has a conservative lower bound of 1 63 second to ensure that delayed segments are not mistaken as lost. 64 Second, when a sender receives dupACKs, the fast retransmit algorithm 65 infers segment loss and triggers a retransmission [RFC5681]. 66 Duplicate acknowledgments are generated by a receiver when out-of- 67 order segments arrive. As both segment loss and segment reordering 68 cause out-of-order arrival, fast retransmit waits for three dupACKs 69 before considering the segment as lost. In some situations, however, 70 the number of outstanding segments is not enough to trigger three 71 dupACKs, and the sender must rely on lengthy RTOs for loss recovery. 73 The number of outstanding segments can be small for several reasons: 75 (1) The connection is limited by the congestion control when the 76 path has a low total capacity (bandwidth-delay product) or the 77 connection's share of the capacity is small. It is also limited 78 by the congestion control in the first few RTTs of a connection 79 or after an RTO when the available capacity is probed using 80 slow-start. 82 (2) The connection is limited by the receiver's available buffer 83 space. 85 (3) The connection is limited by the application if the available 86 capacity of the path is not fully utilized (e.g. interactive 87 applications), or at the end of a transfer. 89 While the reasons listed above are valid for any flow, the third 90 reason is most common for applications that transmit short flows, or 91 use a bursty transmission pattern. A typical example of applications 92 that produce short flows are web-based applications. [RJ10] shows 93 that 70% of all web objects, found at the top 500 sites, are too 94 small for fast retransmit to work. [FDT13] shows that about 77% of 95 all retransmissions sent by a major web service are sent after RTO 96 expiry. Applications with bursty transmission patterns often send 97 data in response to actions, or as a reaction to real life events. 98 Typical examples of such applications are stock trading systems, 99 remote computer operations, online games, and web-based applications 100 using persistent connections. What is special about this class of 101 applications is that they often are time-dependant, and extra latency 102 can reduce the application service level [P09]. 104 The RTO Restart (RTOR) mechanism described in this document makes the 105 RTO slightly more aggressive when the number of outstanding segments 106 is too small for fast retransmit to work, in an attempt to enable 107 faster loss recovery for all segments while being robust to 108 reordering. While RTOR still conforms to the requirement in 109 [RFC6298] that segments must not be retransmitted earlier than RTO 110 seconds after their original transmission, it could increase the risk 111 of spurious timeout. Spurious timeouts typically degrade the 112 performance of flows with multiple bursts of data, as a burst 113 following a spurious timeout might not fit within the reduced 114 congestion window (cwnd). 116 While this document focuses on TCP, the described changes are also 117 valid for the Stream Control Transmission Protocol (SCTP) [RFC4960] 118 which has similar loss recovery and congestion control algorithms. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 This document introduces the following variable: 128 RTO Restart threshold (rrthresh): RTOR is enabled whenever the number 129 of outstaning segments is below this threshold. 131 3. RTO Restart Overview 133 The RTO management algorithm described in [RFC6298] recommends that 134 the retransmission timer is restarted when an acknowledgment (ACK) 135 that acknowledges new data is received and there is still outstanding 136 data. The restart is conducted to guarantee that unacknowledged 137 segments will be retransmitted after approximately RTO seconds. 138 However, by restarting the timer on each incoming ACK, 139 retransmissions are not typically triggered RTO seconds after their 140 previous transmission but rather RTO seconds after the last ACK 141 arrived. The duration of this extra delay depends on several factors 142 but is in most cases approximately one RTT. Hence, in most 143 situations, the time before a retransmission is triggered is equal to 144 "RTO + RTT". 146 The extra delay can be significant, especially for applications that 147 use a lower RTOmin than the standard of 1 second and/or in 148 environments with high RTTs, e.g. mobile networks. The restart 149 approach is illustrated in Figure 1 where a TCP sender transmits 150 three segments to a receiver. The arrival of the first and second 151 segment triggers a delayed ACK (delACK) [RFC1122], which restarts the 152 RTO timer at the sender. RTO restart is performed approximately one 153 RTT after the transmission of the third segment. Thus, if the third 154 segment is lost, as indicated in Figure 1, the effective loss 155 detection time is "RTO + RTT" seconds. In some situations, the 156 effective loss detection time becomes even longer. Consider a 157 scenario where only two segments are outstanding. If the second 158 segment is lost, the time to expire the delACK timer will also be 159 included in the effective loss detection time. 161 Sender Receiver 162 ... 163 DATA [SEG 1] ----------------------> (ack delayed) 164 DATA [SEG 2] ----------------------> (send ack) 165 DATA [SEG 3] ----X /-------- ACK 166 (restart RTO) <----------/ 167 ... 168 (RTO expiry) 169 DATA [SEG 3] ----------------------> 171 Figure 1: RTO restart example 173 During normal TCP bulk transfer the current RTO restart approach is 174 not a problem. Actually, as long as enough segments arrive at a 175 receiver to enable fast retransmit, RTO-based loss recovery should be 176 avoided. RTOs should only be used as a last resort, as they 177 drastically lower the congestion window compared to fast retransmit. 178 The current approach can therefore be beneficial -- it is described 179 in [EL04] to act as a "safety margin" that compensates for some of 180 the problems that the authors have identified with the standard RTO 181 calculation. Notably, the authors of [EL04] also state that "this 182 safety margin does not exist for highly interactive applications 183 where often only a single packet is in flight." 185 Although fast retransmit is preferrable there are situations where 186 timeouts are appropriate, or the only choice. For example, if the 187 network is severely congested and no segments arrive RTO-based 188 recovery should be used. In this situation, the time to recover from 189 the loss(es) will not be the performance bottleneck. However, for 190 connections that do not utilize enough capacity to enable fast 191 retransmit, RTO-based loss detection is the only choice and the time 192 required for this can become a serious performance bottleneck. 194 4. RTOR Algorithm 196 To enable faster loss recovery for connections that are unable to use 197 fast retransmit, RTOR can be used. By resetting the timer to "RTO - 198 T_earliest", where T_earliest is the time elapsed since the earliest 199 outstanding segment was transmitted, retransmissions will always 200 occur after exactly RTO seconds. This approach makes the RTO more 201 aggressive than the standardized approach in [RFC6298] but still 202 conforms to the requirement in [RFC6298] that segments must not be 203 retransmitted earlier than RTO seconds after their original 204 transmission. 206 This document specifies an OPTIONAL sender-only modification to TCP 207 and SCTP which updates step 5.3 in Section 5 of [RFC6298] (and a 208 similar update in Section 6.3.2 of [RFC4960] for SCTP). A sender 209 that implements this method MUST follow the algorithm below: 211 When an ACK is received that acknowledges new data, or when a new 212 data segment has been sent: 214 (1) Set T_earliest = 0. 216 (2) If the following two conditions hold: 218 (a) The number of outstanding segments is less than a RTOR 219 threshold (rrthresh). The rrthresh SHOULD be set to 220 four. 222 (b) There is no unsent data ready for transmission. 224 set T_earliest to the time elapsed since the earliest 225 outstanding segment was sent. 227 (3) Restart the retransmission timer so that it will expire after 228 "RTO - T_earliest" seconds (for the current value of RTO). 230 This update needs TCP implementations to track the time elapsed since 231 the transmission of the earliest outstanding segment (T_earliest). 232 As RTOR is only used when the amount of outstanding data is less than 233 rrthresh segments, TCP implementations also need to track whether the 234 amount of outstanding data is more, equal, or less than rrthresh 235 segments. Although some packet-based TCP implementations (e.g. 236 Linux TCP) already track both the transmission times of all segments 237 and also the number of outstanding segments, not all implementations 238 do. Section 5.3 describes how to implement segment tracking for a 239 general TCP implementation. 241 5. Discussion 243 In this section, we discuss the applicability and a number of issues 244 surrounding RTOR. 246 5.1. Applicability 248 The currently standardized algorithm has been shown to add at least 249 one RTT to the loss recovery process in TCP [LS00] and SCTP 250 [HB11][PBP09]. For applications that have strict timing requirements 251 (e.g. interactive web) rather than throughput requirements, using 252 RTOR could be beneficial because the RTT and also the delACK timer of 253 receivers are often large components of the effective loss recovery 254 time. Measurements in [HB11] have shown that the total transfer time 255 of a lost segment (including the original transmission time and the 256 loss recovery time) can be reduced by 35% using RTOR. These results 257 match those presented in [PGH06][PBP09], where RTOR is shown to 258 significantly reduce retransmission latency. 260 There are also traffic types that do not benefit from RTOR. One 261 example of such traffic is bulk transmission. The reason why bulk 262 traffic does not benefit RTOR is related to the number of outstanding 263 segments that such flows usually have. Fast retransmit [RFC5681], 264 the preferred loss recovery mechanism, is triggered whenever three 265 dupACKs arrive at a TCP sender. Duplicate acknowledgments are 266 generated by a receiver when out-of-order segments arrive. As both 267 segment loss and segment reordering cause out-of-order arrival, fast 268 retransmit waits for three dupACKs before regarding the segment as 269 lost. Considering this, bulk flows will mostly use fast retransmit 270 as they often have three or more outstanding segments. Moreover, as 271 RTOR is not activated as long as there are rrthresh, or more, 272 segments outstanding the risk of recovering loss using timeouts 273 instead of fast retransmits can be controlled. 275 Given RTOR's ability to only work when it is beneficial for the loss 276 recovery process, it is suitable as a system-wide default mechanism 277 for TCP traffic. 279 5.2. Spurious Timeouts 281 RTOR can in some situations reduce the loss detection time and 282 thereby increase the risk of spurious timeouts. In theory, the 283 retransmission timer has a lower bound of 1 second [RFC6298], which 284 limits the risk of having spurious timeouts. However, in practice 285 most implementations use a significantly lower value. Initial 286 measurements, conducted by the authors, show slight increases in the 287 number of spurious timeouts when such lower values are used. 288 However, further experiments, in different environments and with 289 different types of traffic, are encouraged to quantify such increases 290 more reliably. 292 Does a slightly increased risk matter? Generally, spurious timeouts 293 have a negative effect on TCP/SCTP performance as the congestion 294 window is reduced to one segment [RFC5681], limiting an application's 295 ability to transmit large amounts of data instantaneously. However, 296 with respect to RTOR spurious timeouts are only a problem for 297 applications transmitting multiple bursts of data within a single 298 flow. Other types of flows, e.g. long-lived bulk flows, are not 299 affected as the algorithm is only applied when the amount of 300 outstanding segments is less than rrthresh and no previously unsent 301 data is available. Furthermore, short-lived and application-limited 302 flows are typically not affected as they are too short to experience 303 the effect of congestion control or have a transmission rate that is 304 quickly attainable. 306 While a slight increase in spurious timeouts has been observed using 307 RTOR, it is not clear whether the effects of this increase mandate 308 any future algorithmic changes or not -- especially since most modern 309 operating systems already include mechanisms to detect 310 [RFC3522][RFC3708][RFC5682] and resolve [RFC4015] possible problems 311 with spurious retransmissions. Further experimentation is needed to 312 determine this and thereby move this specification from experimental 313 to proposed standard. 315 5.3. Tracking Outstanding Segments 317 Section 3.2 of [RFC5827] outlines a general method of tracking the 318 number of outstanding segments. This method can be used by TCP 319 implementations that do not natively track this number. The basic 320 idea is to track the segment boundaries of the last transmitted 321 segments (rrthresh segments for RTOR). In practice this could be 322 achieved by keeping a circular list of the last rrthresh segment 323 boundaries. Then, cumulative ACKs that do not fall within this 324 region indicate that at least rrthresh segments are outstanding. 325 Similarly, when cumulative ACKs fall within this region, the number 326 of outstanding segments is smaller. 328 6. Related Work 330 There are several proposals that address the problem of not having 331 enough ACKs for loss recovery. In what follows, we explain why the 332 mechanism described here is complementary to these approaches: 334 The limited transmit mechanism [RFC3042] allows a TCP sender to 335 transmit a previously unsent segment for each of the first two 336 dupACKs. By transmitting new segments, the sender attempts to 337 generate additional dupACKs to enable fast retransmit. However, 338 limited transmit does not help if no previously unsent data is ready 339 for transmission or if the receiver has no buffer space. [RFC5827] 340 specifies an early retransmit algorithm to enable fast loss recovery 341 in such situations. By dynamically lowering the number of dupACKs 342 needed for fast retransmit (dupthresh), based on the number of 343 outstanding segments, a smaller number of dupACKs is needed to 344 trigger a retransmission. In some situations, however, the algorithm 345 is of no use or might not work properly. First, if a single segment 346 is outstanding, and lost, it is impossible to use early retransmit. 347 Second, if ACKs are lost, the early retransmit cannot help. Third, 348 if the network path reorders segments, the algorithm might cause more 349 unnecessary retransmissions than fast retransmit. 351 Following the fast retransmit mechanism standardized in [RFC5681] 352 this draft assumes a value of 3 for dupthresh, which is used as a 353 basis for rrthresh. However, by considering a dynamic value for 354 dupthresh a tighter integration with early retransmit (or other 355 experimental algorithms) could also be possible. 357 Tail Loss Probe [TLP] is a proposal to send up to two "probe 358 segments" when a timer fires which is set to a value smaller than the 359 RTO. A "probe segment" is a new segment if new data is available, 360 else a retransmission. The intention is to compensate for sluggish 361 RTO behavior in situations where the RTO greatly exceeds the RTT, 362 which, according to measurements reported in [TLP], is not uncommon. 363 The Probe timeout (PTO) is normally two RTTs, and a spurious PTO is 364 less risky than a spurious RTO because it would not have the same 365 negative effects (clearing the scoreboard and restarting with slow- 366 start). In contrast, RTOR is trying to make the RTO more appropriate 367 in cases where there is no need to be overly cautious. 369 TLP is applicable in situations where RTOR does not apply, and it 370 could overrule (yielding a similar general behavior, but with a lower 371 timeout) RTOR in cases where the number of outstanding segments is 372 smaller than four and no new segments are available for transmission. 373 The PTO has the same inherent problem of restarting the timer on an 374 incoming ACK, and could be combined with a strategy similar to RTOR's 375 to offer more consistent timeouts. 377 7. Acknowledgements 379 The authors wish to thank Godred Fairhurst, Yuchung Cheng, Mark 380 Allman, Anantha Ramaiah, Richard Scheffenegger, Nicolas Kuhn, and 381 Alexander Zimmermann for commenting the draft and the ideas behind 382 it. 384 All the authors are supported by RITE (http://riteproject.eu/ ), a 385 research project (ICT-317700) funded by the European Community under 386 its Seventh Framework Program. The views expressed here are those of 387 the author(s) only. The European Commission is not liable for any 388 use that may be made of the information in this document. 390 8. IANA Considerations 392 This memo includes no request to IANA. 394 9. Security Considerations 396 This document discusses a change in how to set the retransmission 397 timer's value when restarted. This change does not raise any new 398 security issues with TCP or SCTP. 400 10. Changes from Previous Versions 402 RFC-Editor note: please remove this section prior to publication. 404 10.1. Changes from draft-ietf-...-02 to -03 406 o Updated the document to use "RTOR" instead of "RTO Restart" when 407 refering to the modified algorithm. 409 o Moved document terminology to a section of its own. 411 o Introduced the rrthresh variable in the terminology section. 413 o Added a section to generalize the tracking of outstanding 414 segments. 416 o Updated the algorithm to work when the number of outstanding 417 segments is less than four and one segment is ready for 418 transmission, by restarting the timer when new data has been sent. 420 o Clarified the relationship between fast retransmit and RTOR. 422 o Improved the wording throughout the document. 424 10.2. Changes from draft-ietf-...-01 to -02 426 o Changed the algorithm description in Section 3 to use formal RFC 427 2119 language. 429 o Changed last paragraph of Section 3 to clarify why the RTO restart 430 algorithm is active when less than four segments are outstanding. 432 o Added two paragraphs in Section 4.1 to clarify why the algorithm 433 can be turned on for all TCP traffic without having any negative 434 effects on traffic patterns that do not benefit from a modified 435 timer restart. 437 o Improved the wording throughout the document. 439 o Replaced and updated some references. 441 10.3. Changes from draft-ietf-...-00 to -01 443 o Improved the wording throughout the document. 445 o Removed the possibility for a connection limited by the receiver's 446 advertised window to use RTO restart, decreasing the risk of 447 spurious retransmission timeouts. 449 o Added a section that discusses the applicability of and problems 450 related to the RTO restart mechanism. 452 o Updated the text describing the relationship to TLP to reflect 453 updates made in this draft. 455 o Added acknowledgments. 457 11. References 459 11.1. Normative References 461 [RFC1122] Braden, R., "Requirements for Internet Hosts - 462 Communication Layers", STD 3, RFC 1122, October 1989. 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, March 1997. 467 [RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing 468 TCP's Loss Recovery Using Limited Transmit", RFC 3042, 469 January 2001. 471 [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm 472 for TCP", RFC 3522, April 2003. 474 [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective 475 Acknowledgement (DSACKs) and Stream Control Transmission 476 Protocol (SCTP) Duplicate Transmission Sequence Numbers 477 (TSNs) to Detect Spurious Retransmissions", RFC 3708, 478 February 2004. 480 [RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm 481 for TCP", RFC 4015, February 2005. 483 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 484 4960, September 2007. 486 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 487 Control", RFC 5681, September 2009. 489 [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, 490 "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 491 Spurious Retransmission Timeouts with TCP", RFC 5682, 492 September 2009. 494 [RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and 495 P. Hurtig, "Early Retransmit for TCP and Stream Control 496 Transmission Protocol (SCTP)", RFC 5827, May 2010. 498 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 499 "Computing TCP's Retransmission Timer", RFC 6298, June 500 2011. 502 11.2. Informative References 504 [EL04] Ekstroem, H. and R. Ludwig, "The Peak-Hopper: A New End- 505 to-End Retransmission Timer for Reliable Unicast 506 Transport", IEEE INFOCOM 2004, March 2004. 508 [FDT13] Flach, T., Dukkipati, N., Terzis, A., Raghavan, B., 509 Cardwell, N., Cheng, Y., Jain, A., Hao, S., Katz-Bassett, 510 E., and R. Govindan, "Reducing Web Latency: the Virtue of 511 Gentle Aggression", Proc. ACM SIGCOMM Conf., August 2013. 513 [HB11] Hurtig, P. and A. Brunstrom, "SCTP: designed for timely 514 message delivery?", Springer Telecommunication Systems 47 515 (3-4), August 2011. 517 [LS00] Ludwig, R. and K. Sklower, "The Eifel retransmission 518 timer", ACM SIGCOMM Comput. Commun. Rev., 30(3), July 519 2000. 521 [P09] Petlund, A., "Improving latency for interactive, thin- 522 stream applications over reliable transport", Unipub PhD 523 Thesis, Oct 2009. 525 [PBP09] Petlund, A., Beskow, P., Pedersen, J., Paaby, E., Griwodz, 526 C., and P. Halvorsen, "Improving SCTP Retransmission 527 Delays for Time-Dependent Thin Streams", Springer 528 Multimedia Tools and Applications, 45(1-3), 2009. 530 [PGH06] Pedersen, J., Griwodz, C., and P. Halvorsen, 531 "Considerations of SCTP Retransmission Delays for Thin 532 Streams", IEEE LCN 2006, November 2006. 534 [RJ10] Ramachandran, S., "Web metrics: Size and number of 535 resources", Google 536 http://code.google.com/speed/articles/web-metrics.html, 537 May 2010. 539 [TLP] Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, 540 "TCP Loss Probe (TLP): An Algorithm for Fast Recovery of 541 Tail Losses", Internet-draft draft-dukkipati-tcpm-tcp- 542 loss-probe-01.txt, February 2013. 544 Authors' Addresses 546 Per Hurtig 547 Karlstad University 548 Universitetsgatan 2 549 Karlstad 651 88 550 Sweden 552 Phone: +46 54 700 23 35 553 Email: per.hurtig@kau.se 555 Anna Brunstrom 556 Karlstad University 557 Universitetsgatan 2 558 Karlstad 651 88 559 Sweden 561 Phone: +46 54 700 17 95 562 Email: anna.brunstrom@kau.se 563 Andreas Petlund 564 Simula Research Laboratory AS 565 P.O. Box 134 566 Lysaker 1325 567 Norway 569 Phone: +47 67 82 82 00 570 Email: apetlund@simula.no 572 Michael Welzl 573 University of Oslo 574 PO Box 1080 Blindern 575 Oslo N-0316 576 Norway 578 Phone: +47 22 85 24 20 579 Email: michawe@ifi.uio.no