idnits 2.17.1 draft-ietf-tcpm-rtorestart-04.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 (October 27, 2014) is 3469 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: April 30, 2015 A. Petlund 6 Simula Research Laboratory AS 7 M. Welzl 8 University of Oslo 9 October 27, 2014 11 TCP and SCTP RTO Restart 12 draft-ietf-tcpm-rtorestart-04 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 April 30, 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 can degrade the performance 112 of flows with multiple bursts of data, as a burst following a 113 spurious timeout might not fit within the reduced congestion window 114 (cwnd). There are, however, several techniques to mitigate the 115 effects of such unnecessary retransmissions (cf. [RFC4015]). 117 While this document focuses on TCP, the described changes are also 118 valid for the Stream Control Transmission Protocol (SCTP) [RFC4960] 119 which has similar loss recovery and congestion control algorithms. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 This document introduces the following variable: 129 RTO Restart threshold (rrthresh): RTOR is enabled whenever the total 130 number of outstanding and previously unsent segments is below this 131 threshold. 133 3. RTO Restart Overview 135 The RTO management algorithm described in [RFC6298] recommends that 136 the retransmission timer is restarted when an acknowledgment (ACK) 137 that acknowledges new data is received and there is still outstanding 138 data. The restart is conducted to guarantee that unacknowledged 139 segments will be retransmitted after approximately RTO seconds. 140 However, by restarting the timer on each incoming ACK, 141 retransmissions are not typically triggered RTO seconds after their 142 previous transmission but rather RTO seconds after the last ACK 143 arrived. The duration of this extra delay depends on several factors 144 but is in most cases approximately one RTT. Hence, in most 145 situations, the time before a retransmission is triggered is equal to 146 "RTO + RTT". 148 The standardized RTO timer management is illustrated in Figure 1 149 where a TCP sender transmits three segments to a receiver. The 150 arrival of the first and second segment triggers a delayed ACK 151 (delACK) [RFC1122], which restarts the RTO timer at the sender. RTO 152 restart is performed approximately one RTT after the transmission of 153 the third segment. Thus, if the third segment is lost, as indicated 154 in Figure 1, the effective loss detection time is "RTO + RTT" 155 seconds. In some situations, the effective loss detection time 156 becomes even longer. Consider a scenario where only two segments are 157 outstanding. If the second segment is lost, the time to expire the 158 delACK timer will also be included in the effective loss detection 159 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 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: 213 (1) Set T_earliest = 0. 215 (2) If the total number of outstanding and previously unsent 216 segments is less than an RTOR threshold (rrthresh), set 217 T_earliest to the time elapsed since the earliest outstanding 218 segment was sent. 220 (3) Restart the retransmission timer so that it will expire after 221 (for the current value of RTO): 223 (a) RTO - T_earliest, if RTO - T_earliest is > 0. 225 (b) RTO, otherwise. 227 The RECOMMENDED value of rrthresh is four, as it will prevent RTOR 228 from being more aggressive and potentially causing RTOs instead of 229 fast retransmits. This update needs TCP implementations to track the 230 time elapsed since the transmission of the earliest outstanding 231 segment (T_earliest). As RTOR is only used when the amount of 232 outstanding and unsent data is less than rrthresh segments, TCP 233 implementations also need to track whether the amount of outstanding 234 and unsent data is more, equal, or less than rrthresh segments. 235 Although some packet-based TCP implementations (e.g. Linux TCP) 236 already track both the transmission times of all segments and also 237 the number of outstanding segments, not all implementations do. 238 Section 5.3 describes how to implement segment tracking for a general 239 TCP implementation. RTOR is applied only if the calculated 240 expiration time is positive (step 3(a) in the list above). This is 241 done to ensure that RTOR does not trigger retransmissions prematurely 242 when previously retransmitted segments are acknowledged. 244 5. Discussion 246 In this section, we discuss the applicability and a number of issues 247 surrounding RTOR. 249 5.1. Applicability 251 The currently standardized algorithm has been shown to add at least 252 one RTT to the loss recovery process in TCP [LS00] and SCTP 253 [HB11][PBP09]. For applications that have strict timing requirements 254 (e.g. interactive web) rather than throughput requirements, using 255 RTOR could be beneficial because the RTT and also the delACK timer of 256 receivers are often large components of the effective loss recovery 257 time. Measurements in [HB11] have shown that the total transfer time 258 of a lost segment (including the original transmission time and the 259 loss recovery time) can be reduced by 35% using RTOR. These results 260 match those presented in [PGH06][PBP09], where RTOR is shown to 261 significantly reduce retransmission latency. 263 There are also traffic types that do not benefit from RTOR. One 264 example of such traffic is bulk transmission. The reason why bulk 265 traffic does not benefit from RTOR is that such traffic flows mostly 266 have four or more segments outstanding, allowing loss recovery by 267 fast retransmit. However, there is no harm in using RTOR for such 268 traffic as the algorithm only is active when the amount of 269 outstanding and unsent segments are less than rrthresh (default 4). 271 Given RTOR's ability to only work when it is beneficial for the loss 272 recovery process, it is suitable as a system-wide default mechanism 273 for TCP traffic. 275 5.2. Spurious Timeouts 277 RTOR can in some situations reduce the loss detection time and 278 thereby increase the risk of spurious timeouts. In theory, the 279 retransmission timer has a lower bound of 1 second [RFC6298], which 280 limits the risk of having spurious timeouts. However, in practice 281 most implementations use a significantly lower value. Initial 282 measurements, conducted by the authors, show slight increases in the 283 number of spurious timeouts when such lower values are used. 284 However, further experiments, in different environments and with 285 different types of traffic, are encouraged to quantify such increases 286 more reliably. 288 Does a slightly increased risk matter? Generally, spurious timeouts 289 have a negative effect on TCP/SCTP performance as the congestion 290 window is reduced to one segment [RFC5681], limiting an application's 291 ability to transmit large amounts of data instantaneously. However, 292 with respect to RTOR spurious timeouts are only a problem for 293 applications transmitting multiple bursts of data within a single 294 flow. Other types of flows, e.g. long-lived bulk flows, are not 295 affected as the algorithm is only applied when the amount of 296 outstanding and unsent segments is less than rrthresh. Furthermore, 297 short-lived and application-limited flows are typically not affected 298 as they are too short to experience the effect of congestion control 299 or have a transmission rate that is quickly attainable. 301 While a slight increase in spurious timeouts has been observed using 302 RTOR, it is not clear whether the effects of this increase mandate 303 any future algorithmic changes or not -- especially since most modern 304 operating systems already include mechanisms to detect 305 [RFC3522][RFC3708][RFC5682] and resolve [RFC4015] possible problems 306 with spurious retransmissions. Further experimentation is needed to 307 determine this and thereby move this specification from experimental 308 to proposed standard. 310 5.3. Tracking Outstanding and Previously Unsent Segments 312 Section 3.2 of [RFC5827] outlines a general method of tracking the 313 number of outstanding segments. This method can be used by TCP 314 implementations that do not natively perform such tracking. The 315 basic idea is to track the segment boundaries of the last transmitted 316 segments. In practice this could be achieved by keeping a circular 317 list of the last rrthresh segment boundaries. Then, cumulative ACKs 318 that do not fall within this region indicate that at least rrthresh 319 segments are outstanding. Similarly, when cumulative ACKs fall 320 within this region, it is possible to exactly determine the number of 321 outstanding segments. To determine the number of previously unsent 322 segments, a sender can simply divide the number of bytes in its send 323 queue with the SMSS. 325 6. Related Work 327 There are several proposals that address the problem of not having 328 enough ACKs for loss recovery. In what follows, we explain why the 329 mechanism described here is complementary to these approaches: 331 The limited transmit mechanism [RFC3042] allows a TCP sender to 332 transmit a previously unsent segment for each of the first two 333 dupACKs. By transmitting new segments, the sender attempts to 334 generate additional dupACKs to enable fast retransmit. However, 335 limited transmit does not help if no previously unsent data is ready 336 for transmission. [RFC5827] specifies an early retransmit algorithm 337 to enable fast loss recovery in such situations. By dynamically 338 lowering the number of dupACKs needed for fast retransmit 339 (dupthresh), based on the number of outstanding segments, a smaller 340 number of dupACKs is needed to trigger a retransmission. In some 341 situations, however, the algorithm is of no use or might not work 342 properly. First, if a single segment is outstanding, and lost, it is 343 impossible to use early retransmit. Second, if ACKs are lost, early 344 retransmit cannot help. Third, if the network path reorders 345 segments, the algorithm might cause more unnecessary retransmissions 346 than fast retransmit. The recommended value of RTOR's rrthresh 347 variable is based on the dupthresh, but is possible to adapt to allow 348 tighter integration with other experimental algorithms such as early 349 retransmit. 351 Tail Loss Probe [TLP] is a proposal to send up to two "probe 352 segments" when a timer fires which is set to a value smaller than the 353 RTO. A "probe segment" is a new segment if new data is available, 354 else a retransmission. The intention is to compensate for sluggish 355 RTO behavior in situations where the RTO greatly exceeds the RTT, 356 which, according to measurements reported in [TLP], is not uncommon. 357 The Probe timeout (PTO) is normally two RTTs, and a spurious PTO is 358 less risky than a spurious RTO because it would not have the same 359 negative effects (clearing the scoreboard and restarting with slow- 360 start). In contrast, RTOR is trying to make the RTO more appropriate 361 in cases where there is no need to be overly cautious. 363 TLP is applicable in situations where RTOR does not apply, and it 364 could overrule (yielding a similar general behavior, but with a lower 365 timeout) RTOR in cases where the number of outstanding segments is 366 smaller than four and no new segments are available for transmission. 367 The PTO has the same inherent problem of restarting the timer on an 368 incoming ACK, and could be combined with a strategy similar to RTOR's 369 to offer more consistent timeouts. 371 7. Acknowledgements 373 The authors wish to thank Godred Fairhurst, Yuchung Cheng, Mark 374 Allman, Anantha Ramaiah, Richard Scheffenegger, Nicolas Kuhn, and 375 Alexander Zimmermann for commenting the draft and the ideas behind 376 it. 378 All the authors are supported by RITE (http://riteproject.eu/ ), a 379 research project (ICT-317700) funded by the European Community under 380 its Seventh Framework Program. The views expressed here are those of 381 the author(s) only. The European Commission is not liable for any 382 use that may be made of the information in this document. 384 8. IANA Considerations 386 This memo includes no request to IANA. 388 9. Security Considerations 390 This document discusses a change in how to set the retransmission 391 timer's value when restarted. This change does not raise any new 392 security issues with TCP or SCTP. 394 10. Changes from Previous Versions 396 RFC-Editor note: please remove this section prior to publication. 398 10.1. Changes from draft-ietf-...-03 to -04 400 o Changed the algorithm to allow RTOR when there is unsent data 401 available, but the cwnd does not allow transmission. 403 o Changed the algorithm to not trigger if "RTO - T_earliest" <= 0, 404 to avoid that ACKs to previous retransmissions trigger premature 405 timeouts. 407 o Made minor adjustments throughout the document to adjust for the 408 algorithmic change. 410 o Improved the wording throughout the document. 412 10.2. Changes from draft-ietf-...-02 to -03 414 o Updated the document to use "RTOR" instead of "RTO Restart" when 415 refering to the modified algorithm. 417 o Moved document terminology to a section of its own. 419 o Introduced the rrthresh variable in the terminology section. 421 o Added a section to generalize the tracking of outstanding 422 segments. 424 o Updated the algorithm to work when the number of outstanding 425 segments is less than four and one segment is ready for 426 transmission, by restarting the timer when new data has been sent. 428 o Clarified the relationship between fast retransmit and RTOR. 430 o Improved the wording throughout the document. 432 10.3. Changes from draft-ietf-...-01 to -02 434 o Changed the algorithm description in Section 3 to use formal RFC 435 2119 language. 437 o Changed last paragraph of Section 3 to clarify why the RTO restart 438 algorithm is active when less than four segments are outstanding. 440 o Added two paragraphs in Section 4.1 to clarify why the algorithm 441 can be turned on for all TCP traffic without having any negative 442 effects on traffic patterns that do not benefit from a modified 443 timer restart. 445 o Improved the wording throughout the document. 447 o Replaced and updated some references. 449 10.4. Changes from draft-ietf-...-00 to -01 451 o Improved the wording throughout the document. 453 o Removed the possibility for a connection limited by the receiver's 454 advertised window to use RTO restart, decreasing the risk of 455 spurious retransmission timeouts. 457 o Added a section that discusses the applicability of and problems 458 related to the RTO restart mechanism. 460 o Updated the text describing the relationship to TLP to reflect 461 updates made in this draft. 463 o Added acknowledgments. 465 11. References 467 11.1. Normative References 469 [RFC1122] Braden, R., "Requirements for Internet Hosts - 470 Communication Layers", STD 3, RFC 1122, October 1989. 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, March 1997. 475 [RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing 476 TCP's Loss Recovery Using Limited Transmit", RFC 3042, 477 January 2001. 479 [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm 480 for TCP", RFC 3522, April 2003. 482 [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective 483 Acknowledgement (DSACKs) and Stream Control Transmission 484 Protocol (SCTP) Duplicate Transmission Sequence Numbers 485 (TSNs) to Detect Spurious Retransmissions", RFC 3708, 486 February 2004. 488 [RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm 489 for TCP", RFC 4015, February 2005. 491 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 492 4960, September 2007. 494 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 495 Control", RFC 5681, September 2009. 497 [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, 498 "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 499 Spurious Retransmission Timeouts with TCP", RFC 5682, 500 September 2009. 502 [RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and 503 P. Hurtig, "Early Retransmit for TCP and Stream Control 504 Transmission Protocol (SCTP)", RFC 5827, May 2010. 506 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 507 "Computing TCP's Retransmission Timer", RFC 6298, June 508 2011. 510 11.2. Informative References 512 [EL04] Ekstroem, H. and R. Ludwig, "The Peak-Hopper: A New End- 513 to-End Retransmission Timer for Reliable Unicast 514 Transport", IEEE INFOCOM 2004, March 2004. 516 [FDT13] Flach, T., Dukkipati, N., Terzis, A., Raghavan, B., 517 Cardwell, N., Cheng, Y., Jain, A., Hao, S., Katz-Bassett, 518 E., and R. Govindan, "Reducing Web Latency: the Virtue of 519 Gentle Aggression", Proc. ACM SIGCOMM Conf., August 2013. 521 [HB11] Hurtig, P. and A. Brunstrom, "SCTP: designed for timely 522 message delivery?", Springer Telecommunication Systems 47 523 (3-4), August 2011. 525 [LS00] Ludwig, R. and K. Sklower, "The Eifel retransmission 526 timer", ACM SIGCOMM Comput. Commun. Rev., 30(3), July 527 2000. 529 [P09] Petlund, A., "Improving latency for interactive, thin- 530 stream applications over reliable transport", Unipub PhD 531 Thesis, Oct 2009. 533 [PBP09] Petlund, A., Beskow, P., Pedersen, J., Paaby, E., Griwodz, 534 C., and P. Halvorsen, "Improving SCTP Retransmission 535 Delays for Time-Dependent Thin Streams", Springer 536 Multimedia Tools and Applications, 45(1-3), 2009. 538 [PGH06] Pedersen, J., Griwodz, C., and P. Halvorsen, 539 "Considerations of SCTP Retransmission Delays for Thin 540 Streams", IEEE LCN 2006, November 2006. 542 [RJ10] Ramachandran, S., "Web metrics: Size and number of 543 resources", Google 544 http://code.google.com/speed/articles/web-metrics.html, 545 May 2010. 547 [TLP] Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, 548 "TCP Loss Probe (TLP): An Algorithm for Fast Recovery of 549 Tail Losses", Internet-draft draft-dukkipati-tcpm-tcp- 550 loss-probe-01.txt, February 2013. 552 Authors' Addresses 554 Per Hurtig 555 Karlstad University 556 Universitetsgatan 2 557 Karlstad 651 88 558 Sweden 560 Phone: +46 54 700 23 35 561 Email: per.hurtig@kau.se 563 Anna Brunstrom 564 Karlstad University 565 Universitetsgatan 2 566 Karlstad 651 88 567 Sweden 569 Phone: +46 54 700 17 95 570 Email: anna.brunstrom@kau.se 571 Andreas Petlund 572 Simula Research Laboratory AS 573 P.O. Box 134 574 Lysaker 1325 575 Norway 577 Phone: +47 67 82 82 00 578 Email: apetlund@simula.no 580 Michael Welzl 581 University of Oslo 582 PO Box 1080 Blindern 583 Oslo N-0316 584 Norway 586 Phone: +47 22 85 24 20 587 Email: michawe@ifi.uio.no