idnits 2.17.1 draft-gjessing-taps-minset-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2594 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SUBCATEGORY' is mentioned on line 256, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-taps-transports-usage-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TAPS S. Gjessing 3 Internet-Draft M. Welzl 4 Intended status: Informational University of Oslo 5 Expires: September 14, 2017 March 13, 2017 7 A Minimal Set of Transport Services for TAPS Systems 8 draft-gjessing-taps-minset-04 10 Abstract 12 This draft recommends a minimal set of IETF Transport Services 13 offered by end systems supporting TAPS, and gives guidance on 14 choosing among the available mechanisms and protocols. It is based 15 on the set of transport features given in the TAPS document 16 draft-ietf-taps-transports-usage-03. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 14, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Step 1: Categorization -- The Superset of Transport 55 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.1. CONNECTION Related Transport Features . . . . . . . . . . 7 57 3.2. DATA Transfer Related Transport Features . . . . . . . . . 18 58 3.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . . 18 59 3.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . . 20 60 3.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 21 61 4. Step 2: Reduction -- The Reduced Set of Transport Features . . 22 62 4.1. CONNECTION Related Transport Features . . . . . . . . . . 23 63 4.2. DATA Transfer Related Transport Features . . . . . . . . . 24 64 4.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . . 24 65 4.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . . 24 66 4.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 24 67 5. Step 3: Discussion . . . . . . . . . . . . . . . . . . . . . . 24 68 5.1. Sending Messages, Receiving Bytes . . . . . . . . . . . . 24 69 5.2. Stream Schedulers Without Streams . . . . . . . . . . . . 26 70 5.3. Early Data Transmission . . . . . . . . . . . . . . . . . 27 71 5.4. Sender Running Dry . . . . . . . . . . . . . . . . . . . . 27 72 5.5. Capacity Profile . . . . . . . . . . . . . . . . . . . . . 28 73 5.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 28 74 5.7. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 29 75 6. Step 4: Construction -- the Minimal Set of Transport 76 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 77 6.1. Flow Creation, Connection and Termination . . . . . . . . 30 78 6.2. Flow Group Configuration . . . . . . . . . . . . . . . . . 31 79 6.3. Flow Configuration . . . . . . . . . . . . . . . . . . . . 32 80 6.4. Data Transfer . . . . . . . . . . . . . . . . . . . . . . 32 81 6.4.1. The Sender . . . . . . . . . . . . . . . . . . . . . . 32 82 6.4.2. The Receiver . . . . . . . . . . . . . . . . . . . . . 34 83 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 34 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 36 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 88 11.1. Normative References . . . . . . . . . . . . . . . . . . . 36 89 11.2. Informative References . . . . . . . . . . . . . . . . . . 36 90 Appendix A. Revision information . . . . . . . . . . . . . . . . 37 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 93 1. Introduction 95 An application has an intended usage and demands for transport 96 services, and the task of any system that implements TAPS is to offer 97 these services to its applications, i.e. the applications running on 98 top of TAPS, without binding them to a particular transport protocol. 99 Currently, the set of transport services that most applications use 100 is based on TCP and UDP; this limits the ability for the network 101 stack to make use of features of other protocols. For example, if a 102 protocol supports out-of-order message delivery but applications 103 always assume that the network provides an ordered bytestream, then 104 the network stack can never utilize out-of-order message delivery: 105 doing so would break a fundamental assumption of the application. 107 By exposing the transport services of multiple transport protocols, a 108 TAPS system can make it possible to use these services without having 109 to statically bind an application to a specific transport protocol. 110 The first step towards the design of such a system was taken by 111 [RFC8095], which surveys a large number of transports, and [TAPS2], 112 which identifies the specific transport features that are exposed to 113 applications by the protocols TCP, MPTCP, UDP(-Lite) and SCTP as well 114 as the LEDBAT congestion control mechanism. The present draft is 115 based on these documents and follows the same terminology (also 116 listed below). 118 The number of transport features of current IETF transports is large, 119 and exposing all of them has a number of disadvantages: generally, 120 the more functionality is exposed, the less freedom a TAPS system has 121 to automate usage of the various functions of its available set of 122 transport protocols. Some functions only exist in one particular 123 protocol, and if an application would use them, this would statically 124 tie the application to this protocol, counteracting the purpose of a 125 TAPS system. Also, if the number of exposed features is exceedingly 126 large, a TAPS system might become very hard to use for an application 127 programmer. Taking [TAPS2] as a basis, this document therefore 128 develops a minimal set of transport features, removing the ones that 129 could be harmful to the purpose of a TAPS system but keeping the ones 130 that must be retained for applications to benefit from useful 131 transport functionality. 133 Applications use a wide variety of APIs today. The point of this 134 document is to identify transport features that must be reflected in 135 *all* network APIs in order for the underlying functionality to 136 become usable everywhere. For example, it does not help an 137 application that talks to a middleware if only the Berkeley Sockets 138 API is extended to offer "unordered message delivery". Instead, the 139 middleware would have to expose the "unordered message delivery" 140 transport feature to its applications (alternatively, there may be 141 interesting ways for certain types of middleware to try to use some 142 of the transport features that we describe here without exposing them 143 to applications, based on knowledge about the applications -- but 144 this is not the general case). In most situations, in the interest 145 of being as flexible and efficient as possible, the best choice will 146 be for a middleware or library to expose all of the transport 147 features that are recommended as a "minimal set" here. As an example 148 considering only TCP and UDP, a middleware or library that only 149 exposes TCP's reliable bytestream cannot make use of UDP (unless it 150 implements extra functionality on top of UDP) -- doing so could break 151 a fundamental assumption that applications make about the data they 152 send and receive. 154 This document approaches the construction of a minimal set of 155 transport features in the following way: 156 1. Categorization: the superset of transport features from [TAPS2] 157 is presented, and transport features are categorized for later 158 reduction. 159 2. Reduction: a shorter list of transport features is derived from 160 the categorization in the first step. This removes all transport 161 features that do not require application-specific knowledge or 162 cannot be implemented with TCP. 163 3. Discussion: the resulting list shows a number of peculiarities 164 that are discussed, to provide a basis for constructing the 165 minimal set. 166 4. Construction: Based on the reduced set and the discussion of the 167 transport features therein, a minimal set is constructed. 169 2. Terminology 171 The following terms are used throughout this document, and in 172 subsequent documents produced by TAPS that describe the composition 173 and decomposition of transport services. 175 Transport Feature: a specific end-to-end feature that the transport 176 layer provides to an application. Examples include 177 confidentiality, reliable delivery, ordered delivery, message- 178 versus-stream orientation, etc. 179 Transport Service: a set of Transport Features, without an 180 association to any given framing protocol, which provides a 181 complete service to an application. 182 Transport Protocol: an implementation that provides one or more 183 different transport services using a specific framing and header 184 format on the wire. 186 Transport Service Instance: an arrangement of transport protocols 187 with a selected set of features and configuration parameters that 188 implements a single transport service, e.g., a protocol stack (RTP 189 over UDP). 190 Application: an entity that uses the transport layer for end-to-end 191 delivery data across the network (this may also be an upper layer 192 protocol or tunnel encapsulation). 193 Application-specific knowledge: knowledge that only applications 194 have. 195 Endpoint: an entity that communicates with one or more other 196 endpoints using a transport protocol. 197 Connection: shared state of two or more endpoints that persists 198 across messages that are transmitted between these endpoints. 199 Socket: the combination of a destination IP address and a 200 destination port number. 202 3. Step 1: Categorization -- The Superset of Transport Features 204 Following [TAPS2], we divide the transport features into two main 205 groups as follows: 206 1. CONNECTION related transport features 207 - ESTABLISHMENT 208 - AVAILABILITY 209 - MAINTENANCE 210 - TERMINATION 211 2. DATA Transfer Related transport features 212 - Sending Data 213 - Receiving Data 214 - Errors 216 Because QoS is out of scope of TAPS, this document assumes a "best 217 effort" service model [RFC5290], [RFC7305]. Applications using a 218 TAPS system can therefore not make any assumptions about e.g. the 219 time it will take to send a message. We also assume that TAPS 220 applications have no specific requirements that need knowledge about 221 the network, e.g. regarding the choice of network interface or the 222 end-to-end path. Even with these assumptions, there are certain 223 requirements that are strictly kept by transport protocols today, and 224 these must also be kept by a TAPS system. Some of these requirements 225 relate to transport features that we call "Functional". 227 Functional transport features provide functionality that cannot be 228 used without the application knowing about them, or else they violate 229 assumptions that might cause the application to fail. For example, 230 unordered message delivery is a functional transport feature: it 231 cannot be used without the application knowing about it because the 232 application's assumption could be that messages arrive in order. 234 Failure includes any change of the application behavior that is not 235 performance oriented, e.g. security. 237 "Change DSCP" and "Disable Nagle algorithm" are examples of transport 238 features that we call "Optimizing": if a TAPS system autonomously 239 decides to enable or disable them, an application will not fail, but 240 a TAPS system may be able to communicate more efficiently if the 241 application is in control of this optimizing transport feature. 242 These transport features require application-specific knowledge 243 (e.g., about delay/bandwidth requirements or the length of future 244 data blocks that are to be transmitted). 246 The transport features of IETF transport protocols that do not 247 require application-specific knowledge and could therefore be 248 transparently utilized by a TAPS system are called "Automatable". 250 Finally, some transport features are aggregated and/or slightly 251 changed in the TAPS API. These transport features are marked as 252 "ADDED". The corresponding transport features are automatable, and 253 they are listed immediately below the "ADDED" transport feature. 255 In this description, transport services are presented following the 256 nomenclature "CATEGORY.[SUBCATEGORY].SERVICENAME.PROTOCOL", 257 equivalent to "pass 2" in [TAPS2]. The PROTOCOL name "UDP(-Lite)" is 258 used when transport features are equivalent for UDP and UDP-Lite; the 259 PROTOCOL name "TCP" refers to both TCP and MPTCP. We also sketch how 260 some of the TAPS transport services can be implemented. For all 261 transport features that are categorized as "functional" or 262 "optimizing", and for which no matching TCP primitive exists in "pass 263 2" of [TAPS2], a brief discussion on how to fall back to TCP is 264 included. 266 We designate some transport features as "automatable" on the basis of 267 a broader decision that affects multiple transport features: 268 o Most transport features that are related to multi-streaming were 269 designated as "automatable". This was done because the decision 270 on whether to use multi-streaming or not does not depend on 271 application-specific knowledge. This means that a connection that 272 is exhibited to an application could be implemented by using a 273 single stream of an SCTP association instead of mapping it to a 274 complete SCTP association or TCP connection. This could be 275 achieved by using more than one stream when an SCTP association is 276 first established (CONNECT.SCTP parameter "outbound stream 277 count"), maintaining an internal stream number, and using this 278 stream number when sending data (SEND.SCTP parameter "stream 279 number"). Closing or aborting a connection could then simply free 280 the stream number for future use. This is discussed further in 281 Section 5.2. 283 o All transport features that are related to using multiple paths or 284 the choice of the network interface were designated as 285 "automatable". Choosing a path or an interface does not depend on 286 application-specific knowledge. For example, "Listen" could 287 always listen on all available interfaces and "Connect" could use 288 the default interface for the destination IP address. 290 3.1. CONNECTION Related Transport Features 292 ESTABLISHMENT: 293 o Connect 294 Protocols: TCP, SCTP, UDP(-Lite) 295 Functional because the notion of a connection is often reflected 296 in applications as an expectation to be able to communicate after 297 a "Connect" succeeded, with a communication sequence relating to 298 this transport feature that is defined by the application 299 protocol. 300 Implementation: via CONNECT.TCP, CONNECT.SCTP or CONNECT.UDP(- 301 Lite). 303 o Specify which IP Options must always be used 304 Protocols: TCP 305 Automatable because IP Options relate to knowledge about the 306 network, not the application. 308 o Request multiple streams 309 Protocols: SCTP 310 Automatable because using multi-streaming does not require 311 application-specific knowledge. 312 Implementation: see Section 5.2. 314 o Limit the number of inbound streams 315 Protocols: SCTP 316 Automatable because using multi-streaming does not require 317 application-specific knowledge. 318 Implementation: see Section 5.2. 320 o Specify number of attempts and/or timeout for the first 321 establishment message 322 Protocols: TCP, SCTP 323 Functional because this is closely related to potentially assumed 324 reliable data delivery for data that is sent before or during 325 connection establishment. 326 Implementation: Using a parameter of CONNECT.TCP and CONNECT.SCTP. 328 o Obtain multiple sockets 329 Protocols: SCTP 330 Automatable because the usage of multiple paths to communicate to 331 the same end host relates to knowledge about the network, not the 332 application. 334 o Disable MPTCP 335 Protocols: MPTCP 336 Automatable because the usage of multiple paths to communicate to 337 the same end host relates to knowledge about the network, not the 338 application. 339 Implementation: via a boolean parameter in CONNECT.MPTCP. 340 Fall-back to TCP: Do nothing. 342 o Specify which chunk types must always be authenticated 343 Protocols: SCTP 344 Functional because this has a direct influence on security. 345 Implementation: via a parameter in CONNECT.SCTP. 346 Fall-back to TCP: TBD: this relates to the TCP Authentication 347 Option in Section 7.1 of [RFC5925], which is not currently covered 348 by [TAPS2]. 350 o Indicate (and/or obtain upon completion) an Adaptation Layer via 351 an adaptation code point 352 Protocols: SCTP 353 Functional because it allows to send extra data for the sake of 354 identifying an adaptation layer, which by itself is application- 355 specific. 356 Implementation: via a parameter in CONNECT.SCTP. 357 Fall-back to TCP: not possible. 359 o Request to negotiate interleaving of user messages 360 Protocols: SCTP 361 Automatable because it requires using multiple streams, but 362 requesting multiple streams in the CONNECTION.ESTABLISHMENT 363 category is automatable. 364 Implementation: via a parameter in CONNECT.SCTP. 366 o Hand over a message to transfer (possibly multiple times) before 367 connection establishment 368 Protocols: TCP 369 Functional because this is closely tied to properties of the data 370 that an application sends or expects to receive. 371 Implementation: via a parameter in CONNECT.TCP. 373 o Hand over a message to transfer during connection establishment 374 Protocols: SCTP 375 Functional because this can only work if the message is limited in 376 size, making it closely tied to properties of the data that an 377 application sends or expects to receive. 378 Implementation: via a parameter in CONNECT.SCTP. 380 o Enable UDP encapsulation with a specified remote UDP port number 381 Protocols: SCTP 382 Automatable because UDP encapsulation relates to knowledge about 383 the network, not the application. 385 AVAILABILITY: 386 o Listen 387 Protocols: TCP, SCTP, UDP(-Lite) 388 Functional because the notion of accepting connection requests is 389 often reflected in applications as an expectation to be able to 390 communicate after a "Listen" succeeded, with a communication 391 sequence relating to this transport feature that is defined by the 392 application protocol. 393 ADDED. This differs from the 3 automatable transport features 394 below in that it leaves the choice of interfaces for listening 395 open. 396 Implementation: by listening on all interfaces via LISTEN.TCP (not 397 providing a local IP address) or LISTEN.SCTP (providing SCTP port 398 number / address pairs for all local IP addresses). 400 o Listen, 1 specified local interface 401 Protocols: TCP, SCTP, UDP(-Lite) 402 Automatable because decisions about local interfaces relate to 403 knowledge about the network and the Operating System, not the 404 application. 406 o Listen, N specified local interfaces 407 Protocols: SCTP, UDP(-Lite) 408 Automatable because decisions about local interfaces relate to 409 knowledge about the network and the Operating System, not the 410 application. 412 o Listen, all local interfaces 413 Protocols: TCP, SCTP, UDP(-Lite) 414 Automatable because decisions about local interfaces relate to 415 knowledge about the network and the Operating System, not the 416 application. 418 o Specify which IP Options must always be used 419 Protocols: TCP 420 Automatable because IP Options relate to knowledge about the 421 network, not the application. 423 o Disable MPTCP 424 Protocols: MPTCP 425 Automatable because the usage of multiple paths to communicate to 426 the same end host relates to knowledge about the network, not the 427 application. 429 o Specify which chunk types must always be authenticated 430 Protocols: SCTP 431 Functional because this has a direct influence on security. 432 Implementation: via a parameter in CONNECT.SCTP. 433 Fall-back to TCP: TBD: this relates to the TCP Authentication 434 Option in Section 7.1 of [RFC5925], which is not currently covered 435 by [TAPS2]. 437 o Obtain requested number of streams 438 Protocols: SCTP 439 Automatable because using multi-streaming does not require 440 application-specific knowledge. 441 Implementation: see Section 5.2. 443 o Limit the number of inbound streams 444 Protocols: SCTP 445 Automatable because using multi-streaming does not require 446 application-specific knowledge. 447 Implementation: see Section 5.2. 449 o Indicate (and/or obtain upon completion) an Adaptation Layer via 450 an adaptation code point 451 Protocols: SCTP 452 Functional because it allows to send extra data for the sake of 453 identifying an adaptation layer, which by itself is application- 454 specific. 455 Implementation: via a parameter in LISTEN.SCTP. 456 Fall-back to TCP: not possible. 458 o Request to negotiate interleaving of user messages 459 Protocols: SCTP 460 Automatable because it requires using multiple streams, but 461 requesting multiple streams in the CONNECTION.ESTABLISHMENT 462 category is automatable. 463 Implementation: via a parameter in LISTEN.SCTP. 465 MAINTENANCE: 466 o Change timeout for aborting connection (using retransmit limit or 467 time value) 468 Protocols: TCP, SCTP 469 Functional because this is closely related to potentially assumed 470 reliable data delivery. 471 Implementation: via CHANGE-TIMEOUT.TCP or CHANGE-TIMEOUT.SCTP. 473 o Suggest timeout to the peer 474 Protocols: TCP 475 Functional because this is closely related to potentially assumed 476 reliable data delivery. 477 Implementation: via CHANGE-TIMEOUT.TCP. 479 o Disable Nagle algorithm 480 Protocols: TCP, SCTP 481 Optimizing because this decision depends on knowledge about the 482 size of future data blocks and the delay between them. 483 Implementation: via DISABLE-NAGLE.TCP and DISABLE-NAGLE.SCTP. 485 o Request an immediate heartbeat, returning success/failure 486 Protocols: SCTP 487 Automatable because this informs about network-specific knowledge. 489 o Notification of Excessive Retransmissions (early warning below 490 abortion threshold) 491 Protocols: TCP 492 Optimizing because it is an early warning to the application, 493 informing it of an impending functional event. 494 Implementation: via ERROR.TCP. 496 o Add path 497 Protocols: MPTCP, SCTP 498 MPTCP Parameters: source-IP; source-Port; destination-IP; 499 destination-Port 500 SCTP Parameters: local IP address 501 Automatable because the usage of multiple paths to communicate to 502 the same end host relates to knowledge about the network, not the 503 application. 505 o Remove path 506 Protocols: MPTCP, SCTP 507 MPTCP Parameters: source-IP; source-Port; destination-IP; 508 destination-Port 509 SCTP Parameters: local IP address 510 Automatable because the usage of multiple paths to communicate to 511 the same end host relates to knowledge about the network, not the 512 application. 514 o Set primary path 515 Protocols: SCTP 516 Automatable because the usage of multiple paths to communicate to 517 the same end host relates to knowledge about the network, not the 518 application. 520 o Suggest primary path to the peer 521 Protocols: SCTP 522 Automatable because the usage of multiple paths to communicate to 523 the same end host relates to knowledge about the network, not the 524 application. 526 o Configure Path Switchover 527 Protocols: SCTP 528 Automatable because the usage of multiple paths to communicate to 529 the same end host relates to knowledge about the network, not the 530 application. 532 o Obtain status (query or notification) 533 Protocols: SCTP, MPTCP 534 SCTP parameters: association connection state; destination 535 transport address list; destination transport address reachability 536 states; current local and peer receiver window size; current local 537 congestion window sizes; number of unacknowledged DATA chunks; 538 number of DATA chunks pending receipt; primary path; most recent 539 SRTT on primary path; RTO on primary path; SRTT and RTO on other 540 destination addresses; MTU per path; interleaving supported yes/no 541 MPTCP parameters: subflow-list (identified by source-IP; source- 542 Port; destination-IP; destination-Port) 543 Automatable because these parameters relate to knowledge about the 544 network, not the application. 546 o Specify DSCP field 547 Protocols: TCP, SCTP, UDP(-Lite) 548 Optimizing because choosing a suitable DSCP value requires 549 application-specific knowledge. 550 Implementation: via SET_DSCP.TCP / SET_DSCP.SCTP / SET_DSCP.UDP(- 551 Lite) 553 o Notification of ICMP error message arrival 554 Protocols: TCP, UDP(-Lite) 555 Optimizing because these messages can inform about success or 556 failure of functional transport features (e.g., host unreachable 557 relates to "Connect") 558 Implementation: via ERROR.TCP or ERROR.UDP(-Lite). 560 o Obtain information about interleaving support 561 Protocols: SCTP 562 Automatable because it requires using multiple streams, but 563 requesting multiple streams in the CONNECTION.ESTABLISHMENT 564 category is automatable. 565 Implementation: via a parameter in GETINTERL.SCTP. 567 o Change authentication parameters 568 Protocols: SCTP 569 Functional because this has a direct influence on security. 570 Implementation: via SETAUTH.SCTP. 571 Fall-back to TCP: TBD: this relates to the TCP Authentication 572 Option in Section 7.1 of [RFC5925], which is not currently covered 573 by [TAPS2]. 575 o Obtain authentication information 576 Protocols: SCTP 577 Functional because authentication decisions may have been made by 578 the peer, and this has an influence on the necessary application- 579 level measures to provide a certain level of security. 580 Implementation: via GETAUTH.SCTP. 581 Fall-back to TCP: TBD: this relates to the TCP Authentication 582 Option in Section 7.1 of [RFC5925], which is not currently covered 583 by [TAPS2]. 585 o Reset Stream 586 Protocols: SCTP 587 Automatable because using multi-streaming does not require 588 application-specific knowledge. 589 Implementation: see Section 5.2. 591 o Notification of Stream Reset 592 Protocols: STCP 593 Automatable because using multi-streaming does not require 594 application-specific knowledge. 595 Implementation: see Section 5.2. 597 o Reset Association 598 Protocols: SCTP 599 Functional because it affects "Obtain a message delivery number", 600 which is functional. 601 Implementation: via RESETASSOC.SCTP. 602 Fall-back to TCP: not possible. 604 o Notification of Association Reset 605 Protocols: STCP 606 Functional because it affects "Obtain a message delivery number", 607 which is functional. 608 Implementation: via RESETASSOC-EVENT.SCTP. 609 Fall-back to TCP: not possible. 611 o Add Streams 612 Protocols: SCTP 613 Automatable because using multi-streaming does not require 614 application-specific knowledge. 616 Implementation: see Section 5.2. 618 o Notification of Added Stream 619 Protocols: STCP 620 Automatable because using multi-streaming does not require 621 application-specific knowledge. 622 Implementation: see Section 5.2. 624 o Choose a scheduler to operate between streams of an association 625 Protocols: SCTP 626 Optimizing because the scheduling decision requires application- 627 specific knowledge. However, if a TAPS system would not use this, 628 or wrongly configure it on its own, this would only affect the 629 performance of data transfers; the outcome would still be correct 630 within the "best effort" service model. 631 Implementation: using SETSTREAMSCHEDULER.SCTP. 632 Fall-back to TCP: do nothing. 634 o Configure priority or weight for a scheduler 635 Protocols: SCTP 636 Optimizing because the priority or weight requires application- 637 specific knowledge. However, if a TAPS system would not use this, 638 or wrongly configure it on its own, this would only affect the 639 performance of data transfers; the outcome would still be correct 640 within the "best effort" service model. 641 Implementation: using CONFIGURESTREAMSCHEDULER.SCTP. 642 Fall-back to TCP: do nothing. 644 o Configure send buffer size 645 Protocols: SCTP 646 Automatable because this decision relates to knowledge about the 647 network and the Operating System, not the application (see also 648 the discussion in Section 5.4). 650 o Configure receive buffer (and rwnd) size 651 Protocols: SCTP 652 Automatable because this decision relates to knowledge about the 653 network and the Operating System, not the application. 655 o Configure message fragmentation 656 Protocols: SCTP 657 Automatable because fragmentation relates to knowledge about the 658 network and the Operating System, not the application. 659 Implementation: by always enabling it with 660 CONFIG_FRAGMENTATION.SCTP and auto-setting the fragmentation size 661 based on network or Operating System conditions. 663 o Configure PMTUD 664 Protocols: SCTP 665 Automatable because Path MTU Discovery relates to knowledge about 666 the network, not the application. 668 o Configure delayed SACK timer 669 Protocols: SCTP 670 Automatable because the receiver-side decision to delay sending 671 SACKs relates to knowledge about the network, not the application 672 (it can be relevant for a sending application to request not to 673 delay the SACK of a message, but this is a different transport 674 feature). 676 o Set Cookie life value 677 Protocols: SCTP 678 Functional because it relates to security (possibly weakened by 679 keeping a cookie very long) versus the time between connection 680 establishment attempts. Knowledge about both issues can be 681 application-specific. 682 Fall-back to TCP: the closest TCP functionality is the cookie in 683 TCP Fast Open; for this, [RFC7413] states that the server "can 684 expire the cookie at any time to enhance security" and section 685 4.1.2 describes an example implementation where updating the key 686 on the server side causes the cookie to expire; however, this is 687 different from this transport feature because SCTP's cookie life 688 value is set on the client side, not the server side. The TCP 689 client has no control of this value. Thus, the recommended fall- 690 back implementation is to do nothing. 692 o Set maximum burst 693 Protocols: SCTP 694 Automatable because it relates to knowledge about the network, not 695 the application. 697 o Configure size where messages are broken up for partial delivery 698 Protocols: SCTP 699 Functional because this is closely tied to properties of the data 700 that an application sends or expects to receive. 701 Fall-back to TCP: do nothing. Since TCP does not deliver 702 messages, partial or not, this will have no effect on TCP. 704 o Disable checksum when sending 705 Protocols: UDP 706 Functional because application-specific knowledge is necessary to 707 decide whether it can be acceptable to lose data integrity. 708 Implementation: via CHECKSUM.UDP. 709 Fall-back to TCP: do nothing. 711 o Disable checksum requirement when receiving 712 Protocols: UDP 713 Functional because application-specific knowledge is necessary to 714 decide whether it can be acceptable to lose data integrity. 715 Implementation: via CHECKSUM_REQUIRED.UDP. 716 Fall-back to TCP: do nothing. 718 o Specify checksum coverage used by the sender 719 Protocols: UDP-Lite 720 Functional because application-specific knowledge is necessary to 721 decide for which parts of the data it can be acceptable to lose 722 data integrity. 723 Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite. 724 Fall-back to TCP: do nothing. 726 o Specify minimum checksum coverage required by receiver 727 Protocols: UDP-Lite 728 Functional because application-specific knowledge is necessary to 729 decide for which parts of the data it can be acceptable to lose 730 data integrity. 731 Implementation: via SET_MIN_CHECKSUM_COVERAGE.UDP-Lite. 732 Fall-back to TCP: do nothing. 734 o Specify DF field 735 Protocols: UDP(-Lite) 736 Optimizing because the DF field can be used to carry out Path MTU 737 Discovery, which can lead an application to choose message sizes 738 that can be transmitted more efficiently. 739 Implementation: via MAINTENANCE.SET_DF.UDP(-Lite) and 740 SEND_FAILURE.UDP(-Lite). 741 Fall-back to TCP: do nothing. With TCP the sender is not in 742 control of transport message sizes, making this functionality 743 irrelevant. 745 o Specify TTL/Hop count field 746 Protocols: UDP(-Lite) 747 Automatable because a TAPS system can use a large enough system 748 default to avoid communication failures. Allowing an application 749 to configure it differently can produce notifications of ICMP 750 error message arrivals that yield information which only relates 751 to knowledge about the network, not the application. 753 o Obtain TTL/Hop count field 754 Protocols: UDP(-Lite) 755 Automatable because the TTL/Hop count field relates to knowledge 756 about the network, not the application. 758 o Specify ECN field 759 Protocols: UDP(-Lite) 760 Automatable because the ECN field relates to knowledge about the 761 network, not the application. 763 o Obtain ECN field 764 Protocols: UDP(-Lite) 765 Automatable because the ECN field relates to knowledge about the 766 network, not the application. 768 o Specify IP Options 769 Protocols: UDP(-Lite) 770 Automatable because IP Options relate to knowledge about the 771 network, not the application. 773 o Obtain IP Options 774 Protocols: UDP(-Lite) 775 Automatable because IP Options relate to knowledge about the 776 network, not the application. 778 o Enable and configure a "Low Extra Delay Background Transfer" 779 Protocols: A protocol implementing the LEDBAT congestion control 780 mechanism 781 Optimizing because whether this service is appropriate or not 782 depends on application-specific knowledge. However, wrongly using 783 this will only affect the speed of data transfers (albeit 784 including other transfers that may compete with the TAPS transfer 785 in the network), so it is still correct within the "best effort" 786 service model. 787 Implementation: via CONFIGURE.LEDBAT and/or SET_DSCP.TCP / 788 SET_DSCP.SCTP / SET_DSCP.UDP(-Lite) [LBE-draft]. 789 Fall-back to TCP: do nothing. 791 TERMINATION: 792 o Close after reliably delivering all remaining data, causing an 793 event informing the application on the other side 794 Protocols: TCP, SCTP 795 Functional because the notion of a connection is often reflected 796 in applications as an expectation to have all outstanding data 797 delivered and no longer be able to communicate after a "Close" 798 succeeded, with a communication sequence relating to this 799 transport feature that is defined by the application protocol. 800 Implementation: via CLOSE.TCP and CLOSE.SCTP. 802 o Abort without delivering remaining data, causing an event 803 informing the application on the other side 804 Protocols: TCP, SCTP 805 Functional because the notion of a connection is often reflected 806 in applications as an expectation to potentially not have all 807 outstanding data delivered and no longer be able to communicate 808 after an "Abort" succeeded, with a communication sequence relating 809 to this transport feature that is defined by the application 810 protocol. 811 Implementation: via ABORT.TCP and ABORT.SCTP. 813 o Timeout event when data could not be delivered for too long 814 Protocols: TCP, SCTP 815 Functional because this notifies that potentially assumed reliable 816 data delivery is no longer provided. 817 Implementation: via TIMEOUT.TCP and TIMEOUT.SCTP. 819 3.2. DATA Transfer Related Transport Features 821 3.2.1. Sending Data 823 o Reliably transfer data, with congestion control 824 Protocols: TCP, SCTP 825 Functional because this is closely tied to properties of the data 826 that an application sends or expects to receive. 827 Implementation: via SEND.TCP and SEND.SCTP. 829 o Reliably transfer a message, with congestion control 830 Protocols: SCTP 831 Functional because this is closely tied to properties of the data 832 that an application sends or expects to receive. 833 Implementation: via SEND.SCTP and SEND.TCP. With SEND.TCP, 834 messages will not be identifiable by the receiver. Inform the 835 application of the result. 837 o Unreliably transfer a message 838 Protocols: SCTP, UDP(-Lite) 839 Optimizing because only applications know about the time 840 criticality of their communication, and reliably transfering a 841 message is never incorrect for the receiver of a potentially 842 unreliable data transfer, it is just slower. 843 ADDED. This differs from the 2 automatable transport features 844 below in that it leaves the choice of congestion control open. 845 Implementation: via SEND.SCTP or SEND.UDP or SEND.TCP. With 846 SEND.TCP, messages will not be identifiable by the receiver. 847 Inform the application of the result. 849 o Unreliably transfer a message, with congestion control 850 Protocols: SCTP 851 Automatable because congestion control relates to knowledge about 852 the network, not the application. 854 o Unreliably transfer a message, without congestion control 855 Protocols: UDP(-Lite) 856 Automatable because congestion control relates to knowledge about 857 the network, not the application. 859 o Configurable Message Reliability 860 Protocols: SCTP 861 Optimizing because only applications know about the time 862 criticality of their communication, and reliably transfering a 863 message is never incorrect for the receiver of a potentially 864 unreliable data transfer, it is just slower. 865 Implementation: via SEND.SCTP. 866 Fall-back to TCP: By using SEND.TCP and ignoring this 867 configuration: based on the assumption of the best-effort service 868 model, unnecessarily delivering data does not violate application 869 expectations. Moreover, it is not possible to associate the 870 requested reliability to a "message" in TCP anyway. 872 o Choice of stream 873 Protocols: SCTP 874 Automatable because it requires using multiple streams, but 875 requesting multiple streams in the CONNECTION.ESTABLISHMENT 876 category is automatable. Implementation: see Section 5.2. 878 o Choice of path (destination address) 879 Protocols: SCTP 880 Automatable because it requires using multiple sockets, but 881 obtaining multiple sockets in the CONNECTION.ESTABLISHMENT 882 category is automatable. 884 o Choice between unordered (potentially faster) or ordered delivery 885 of messages 886 Protocols: SCTP 887 Functional because this is closely tied to properties of the data 888 that an application sends or expects to receive. 889 Implementation: via SEND.SCTP. 890 Fall-back to TCP: By using SEND.TCP and always sending data 891 ordered: based on the assumption of the best-effort service model, 892 ordered delivery may just be slower and does not violate 893 application expectations. Moreover, it is not possible to 894 associate the requested delivery order to a "message" in TCP 895 anyway. 897 o Request not to bundle messages 898 Protocols: SCTP 899 Optimizing because this decision depends on knowledge about the 900 size of future data blocks and the delay between them. 901 Implementation: via SEND.SCTP. 902 Fall-back to TCP: By using SEND.TCP and DISABLE-NAGLE.TCP to 903 disable the Nagle algorithm when the request is made and enable it 904 again when the request is no longer made. 906 o Specifying a "payload protocol-id" (handed over as such by the 907 receiver) 908 Protocols: SCTP 909 Functional because it allows to send extra application data with 910 every message, for the sake of identification of data, which by 911 itself is application-specific. 912 Implementation: SEND.SCTP. 913 Fall-back to TCP: not possible. 915 o Specifying a key id to be used to authenticate a message 916 Protocols: SCTP 917 Functional because this has a direct influence on security. 918 Implementation: via a parameter in SEND.SCTP. 919 Fall-back to TCP: TBD: this relates to the TCP Authentication 920 Option in Section 7.1 of [RFC5925], which is not currently covered 921 by [TAPS2]. 923 o Request not to delay the acknowledgement (SACK) of a message 924 Protocols: SCTP 925 Optimizing because only an application knows for which message it 926 wants to quickly be informed about success / failure of its 927 delivery. 928 Fall-back to TCP: do nothing. 930 3.2.2. Receiving Data 932 o Receive data (with no message delineation) 933 Protocols: TCP 934 Functional because a TAPS system must be able to send and receive 935 data. 936 Implementation: via RECEIVE.TCP 938 o Receive a message 939 Protocols: SCTP, UDP(-Lite) 940 Functional because this is closely tied to properties of the data 941 that an application sends or expects to receive. 942 Implementation: via RECEIVE.SCTP and RECEIVE.UDP(-Lite). 943 Fall-back to TCP: not possible. 945 o Choice of stream to receive from 946 Protocols: SCTP 947 Automatable because it requires using multiple streams, but 948 requesting multiple streams in the CONNECTION.ESTABLISHMENT 949 category is automatable. 950 Implementation: see Section 5.2. 952 o Information about partial message arrival 953 Protocols: SCTP 954 Functional because this is closely tied to properties of the data 955 that an application sends or expects to receive. 956 Implementation: via RECEIVE.SCTP. 957 Fall-back to TCP: do nothing: this information is not available 958 with TCP. 960 o Obtain a message delivery number 961 Protocols: SCTP 962 Functional because this number can let applications detect and, if 963 desired, correct reordering. Whether messages are in the correct 964 order or not is closely tied to properties of the data that an 965 application sends or expects to receive. 966 Implementation: via RECEIVE.SCTP. 967 Fall-back to TCP: not possible. 969 3.2.3. Errors 971 This section describes sending failures that are associated with a 972 specific call to in the "Sending Data" category (Section 3.2.1). 974 o Notification of send failures 975 Protocols: SCTP, UDP(-Lite) 976 Functional because this notifies that potentially assumed reliable 977 data delivery is no longer provided. 978 ADDED. This differs from the 2 automatable transport features 979 below in that it does not distinugish between unsent and 980 unacknowledged messages. 981 Implementation: via SENDFAILURE-EVENT.SCTP and SEND_FAILURE.UDP(- 982 Lite). 983 Fall-back to TCP: do nothing: this notification is not available 984 and will therefore not occur with TCP. 986 o Notification of an unsent (part of a) message 987 Protocols: SCTP, UDP(-Lite) 988 Automatable because the distinction between unsent and 989 unacknowledged is network-specific. 991 o Notification of an unacknowledged (part of a) message 992 Protocols: SCTP 993 Automatable because the distinction between unsent and 994 unacknowledged is network-specific. 996 o Notification that the stack has no more user data to send 997 Protocols: SCTP 998 Optimizing because reacting to this notification requires the 999 application to be involved, and ensuring that the stack does not 1000 run dry of data (for too long) can improve performance. 1001 Fall-back to TCP: do nothing. See also the discussion in 1002 Section 5.4. 1004 o Notification to a receiver that a partial message delivery has 1005 been aborted 1006 Protocols: SCTP 1007 Functional because this is closely tied to properties of the data 1008 that an application sends or expects to receive. 1009 Fall-back to TCP: do nothing. This notification is not available 1010 and will therefore not occur with TCP. 1012 4. Step 2: Reduction -- The Reduced Set of Transport Features 1014 By hiding automatable transport features from the application, a TAPS 1015 system can gain opportunities to automate the usage of network- 1016 related functionality. This can facilitate using the TAPS system for 1017 the application programmer and it allows for optimizations that may 1018 not be possible for an application. For instance, system-wide 1019 configurations regarding the usage of multiple interfaces can better 1020 be exploited if the choice of the interface is not entirely up to the 1021 application. Therefore, since they are not strictly necessary to 1022 expose in a TAPS system, we do not include automatable transport 1023 features in the reduced set of transport features. This leaves us 1024 with only the transport features that are either optimizing or 1025 functional. 1027 A TAPS system should be able to fall back to TCP or UDP if 1028 alternative transport protocols are found not to work. Here we only 1029 consider falling back to TCP. For some transport features, it was 1030 identified that no fall-back to TCP is possible. This eliminates the 1031 possibility to use TCP whenever an application makes use of one of 1032 these transport features. Thus, we only keep the functional and 1033 optimizing transport features for which a fall-back to TCP is 1034 possible in our reduced set. "Reset Association" and "Notification 1035 of Association Reset" are only functional because of their 1036 relationship to "Obtain a message delivery number", which is 1037 functional. Because "Obtain a message delivery number" does not have 1038 a fall-back to TCP, none of these three transport features are 1039 included in the reduced set. 1041 4.1. CONNECTION Related Transport Features 1043 ESTABLISHMENT: 1044 o Connect 1045 o Specify number of attempts and/or timeout for the first 1046 establishment message 1047 o Specify which chunk types must always be authenticated 1048 o Hand over a message to transfer (possibly multiple times) before 1049 connection establishment 1050 o Hand over a message to transfer during connection establishment 1052 AVAILABILITY: 1053 o Listen 1054 o Specify which chunk types must always be authenticated 1056 MAINTENANCE: 1057 o Change timeout for aborting connection (using retransmit limit or 1058 time value) 1059 o Suggest timeout to the peer 1060 o Disable Nagle algorithm 1061 o Notification of Excessive Retransmissions (early warning below 1062 abortion threshold) 1063 o Specify DSCP field 1064 o Notification of ICMP error message arrival 1065 o Change authentication parameters 1066 o Obtain authentication information 1067 o Choose a scheduler to operate between streams of an association 1068 o Configure priority or weight for a scheduler 1069 o Set Cookie life value 1070 o Configure size where messages are broken up for partial delivery 1071 o Disable checksum when sending 1072 o Disable checksum requirement when receiving 1073 o Specify checksum coverage used by the sender 1074 o Specify minimum checksum coverage required by receiver 1075 o Specify DF field 1076 o Enable and configure a "Low Extra Delay Background Transfer" 1078 TERMINATION: 1079 o Close after reliably delivering all remaining data, causing an 1080 event informing the application on the other side 1081 o Abort without delivering remaining data, causing an event 1082 informing the application on the other side 1084 o Timeout event when data could not be delivered for too long 1086 4.2. DATA Transfer Related Transport Features 1088 4.2.1. Sending Data 1090 o Reliably transfer data, with congestion control 1091 o Reliably transfer a message, with congestion control 1092 o Unreliably transfer a message 1093 o Configurable Message Reliability 1094 o Choice between unordered (potentially faster) or ordered delivery 1095 of messages 1096 o Request not to bundle messages 1097 o Specifying a key id to be used to authenticate a message 1098 o Request not to delay the acknowledgement (SACK) of a message 1100 4.2.2. Receiving Data 1102 o Receive data (with no message delineation) 1103 o Information about partial message arrival 1105 4.2.3. Errors 1107 This section describes sending failures that are associated with a 1108 specific call to in the "Sending Data" category (Section 3.2.1). 1110 o Notification of send failures 1111 o Notification that the stack has no more user data to send 1112 o Notification to a receiver that a partial message delivery has 1113 been aborted 1115 5. Step 3: Discussion 1117 The reduced set in the previous section exhibits a number of 1118 peculiarities, which we will discuss in the following. 1120 5.1. Sending Messages, Receiving Bytes 1122 There are several transport features related to sending, but only a 1123 single transport feature related to receiving: "Receive data (with no 1124 message delineation)" (and, strangely, "information about partial 1125 message arrival"). Notably, the transport feature "Receive a 1126 message" is also the only non-automatable transport feature of UDP(- 1127 Lite) that had to be removed because no fall-back to TCP is possible. 1128 It is also represents the only way that UDP(-Lite) applications can 1129 receive data today. 1131 For the transport to operate on messages, it only needs be informed 1132 about them as they are handed over by a sending application; on the 1133 receiver side, receiving a message only differs from receiving a 1134 bytestream in that the application is told where messages begin and 1135 end in the former case but not in the latter. The receiving 1136 application can still operate on these messages as long as it does 1137 not rely on the transport layer to inform it about message 1138 boundaries. 1140 For example, if an application requests to transfer fixed-size 1141 messages of 100 bytes with partial reliability, this needs the 1142 receiving application to be prepared to accept data in chunks of 100 1143 bytes. If, then, some of these 100 byte messages are missing (e.g., 1144 if SCTP with Configurable Reliability is used), this is the expected 1145 application behavior. With TCP, no messages would be missing, but 1146 this is also correct for the application, and possible retransmission 1147 delay is acceptable within the best effort service model. Still, the 1148 receiving application would separate the byte stream into 100-byte 1149 chunks. 1151 Note that this usage of messages does not require all messages to be 1152 equal in size. Many application protocols use some form of Type- 1153 Length-Value (TLV) encoding, e.g. by defining a header including 1154 length fields; another alternative is the use of byte stuffing 1155 methods such as COBS [COBS]. If an application needs message 1156 numbers, e.g. to restore the correct sequence of messages, these must 1157 also be encoded by the application itself, as the sequence number 1158 related transport features of SCTP are no longer provided (in the 1159 interest of enabling a fall-back to TCP). 1161 For the implementation of a TAPS system, this has the following 1162 consequences: 1163 o Because the receiver-side transport leaves it up to the 1164 application to delineate messages, messages must always remain 1165 intact as they are handed over by the transport receiver. Data 1166 can be handed over at any time as they arrive, but the byte stream 1167 must never "skip ahead" to the beginning of the next message. 1168 o With SCTP, a "partial flag" informs a receiving application that a 1169 message is incomplete. Then, the next receive calls will only 1170 deliver remaining parts of the same message (i.e., no messages or 1171 partial messages will arrive on other streams until the message is 1172 complete) (see Section 8.1.20 in [RFC6458]). This can facilitate 1173 the implementation of the receiver buffer in the receiving 1174 application, but then such an application does not support message 1175 interleaving (which is required by stream schedulers). However, 1176 receiving a byte stream from multiple SCTP streams requires a per- 1177 stream receiver buffer anyway, so this potential benefit is lost 1178 and the "partial flag" (the transport feature "Information about 1179 partial message arrival") becomes unnecessary for a TAPS system. 1180 With it, the transport features "Configure size where messages are 1181 broken up for partial delivery" and "Notification to a receiver 1182 that a partial message delivery has been aborted" become 1183 unnecessary too. 1184 o From the above, a TAPS system should always support message 1185 interleaving because it enables the use of stream schedulers and 1186 comes at no additional implementation cost on the receiver side. 1187 Stream schedulers operate on the sender side. Hence, because a 1188 TAPS sender-side application may talk to an SCTP receiver that 1189 does not support interleaving, it cannot assume that stream 1190 schedulers will always work as expected. 1192 5.2. Stream Schedulers Without Streams 1194 We have already stated that multi-streaming does not require 1195 application-specific knowledge. Potential benefits or disadvantages 1196 of, e.g., using two streams over an SCTP association versus using two 1197 separate SCTP associations or TCP connections are related to 1198 knowledge about the network and the particular transport protocol in 1199 use, not the application. However, the transport features "Choose a 1200 scheduler to operate between streams of an association" and 1201 "Configure priority or weight for a scheduler" operate on streams. 1202 Here, streams identify communication channels between which a 1203 scheduler operates, and they can be assigned a priority. Moreover, 1204 the transport features in the MAINTENANCE category all operate on 1205 assocations in case of SCTP, i.e. they apply to all streams in that 1206 assocation. 1208 With only these semantics necessary to represent, the interface to a 1209 TAPS system becomes easier if we rename connections into "TAPS flows" 1210 (the TAPS equivalent of a connection which may be a transport 1211 connection or association, but could also become a stream of an 1212 existing SCTP association, for example) and allow assigning a "Group 1213 Number" to a TAPS flow. Then, all MAINTENANCE transport features can 1214 be said to operate on flow groups, not connections, and a scheduler 1215 also operates on the flows within a group. 1217 For the implementation of a TAPS system, this has the following 1218 consequences: 1219 o Streams may be identified in different ways across different 1220 protocols. The only multi-streaming protocol considered in this 1221 document, SCTP, uses a stream id. The transport association below 1222 still uses a Transport Address (which includes one port number) 1223 for each communicating endpoint. To implement a TAPS system 1224 without exposed streams, an application must be given an 1225 identifier for each TAPS flow (akin to a socket), and depending on 1226 whether streams are used or not, there will be a 1:1 mapping 1227 between this identifier and local ports or not. 1228 o In SCTP, a fixed number of streams exists from the beginning of an 1229 association; streams are not "established", there is no handshake 1230 or any other form of signaling to create them: they can just be 1231 used. They are also not "gracefully shut down" -- at best, an 1232 "SSN Reset Request Parameter" in a "RE-CONFIG" chunk [RFC6525] can 1233 be used to inform the peer that of a "Stream Reset", as a rough 1234 equivalent of an "Abort". This has an impact on the semantics 1235 connection establishment and teardown (see Section 6.1). 1236 o To support stream schedulers, a receiver-side TAPS system should 1237 always support message interleaving because it comes at no 1238 additional implementation cost (because of the receiver-side 1239 stream reception discussed in Section 5.1). Note, however, that 1240 Stream schedulers operate on the sender side. Hence, because a 1241 TAPS sender-side application may talk to a native TCP-based 1242 receiver-side application, it cannot assume that stream schedulers 1243 will always work as expected. 1245 5.3. Early Data Transmission 1247 There are two transport features related to transferring a message 1248 early: "Hand over a message to transfer (possibly multiple times) 1249 before connection establishment", which relates to TCP Fast Open 1250 [RFC7413], and "Hand over a message to transfer during connection 1251 establishment", which relates to SCTP's ability to transfer data 1252 together with the COOKIE-Echo chunk. Also without TCP Fast Open, TCP 1253 can transfer data during the handshake, together with the SYN packet 1254 -- however, the receiver of this data may not hand it over to the 1255 application until the handshake has completed. This functionality is 1256 commonly available in TCP and supported in several implementations, 1257 but the TCP specification does not specify how to provide it to 1258 applications. 1260 The amount of data that can successfully be transmitted before or 1261 during the handshake depends on various factors: the transport 1262 protocol, the use of header options, the choice of IPv4 and IPv6 and 1263 the Path MTU. A TAPS system should therefore allow a sending 1264 application to query the maximum amount of data it can possibly 1265 transmit before or during connection establishment, respectively. 1267 5.4. Sender Running Dry 1269 The transport feature "Notification that the stack has no more user 1270 data to send" relates to SCTP's "SENDER DRY" notification. Such 1271 notifications can, in principle, be used to avoid having an 1272 unnecessarily large send buffer, yet ensure that the transport sender 1273 always has data available when it has an opportunity to transmit it. 1274 This has been found to be very beneficial for some applications 1276 [WWDC2015]. However, "SENDER DRY" truly means that the buffer has 1277 emptied -- i.e., when it notifies the sender, it is already too late, 1278 the transport protocol already missed an opportunity to send data. 1279 Some modern TCP implementations now include the unspecified 1280 "TCP_NOTSENT_LOWAT" socket option proposed in [WWDC2015], which 1281 limits the amount of unsent data that TCP can keep in the socket 1282 buffer; this allows to specify at which buffer filling level the 1283 socket becomes writable, rather than waiting for the buffer to run 1284 empty. 1286 SCTP has means to configure the sender-side buffer too: the 1287 automatable Transport Feature "Configure send buffer size" provides 1288 this functionality, but only for the complete buffer, which includes 1289 both unsent and unacknowledged data. SCTP does not allow to control 1290 these two sizes separately. A TAPS system should allow for uniform 1291 access to "TCP_NOTSENT_LOWAT" as well as the "SENDER DRY" 1292 notification. 1294 5.5. Capacity Profile 1296 The transport features: 1297 o Disable Nagle algorithm 1298 o Enable and configure a "Low Extra Delay Background Transfer" 1299 o Specify DSCP field 1300 all relate to a QoS-like application need such as "low latency" or 1301 "scavenger". In the interest of flexibility of a TAPS system, they 1302 could therefore be offered in a uniform, more abstract way, where a 1303 TAPS system could e.g. decide by itself how to use combinations of 1304 LEDBAT-like congestion control and certain DSCP values, and an 1305 application would only specify a general "capacity profile" (a 1306 description of how it wants to use the available capacity). A need 1307 for "lowest possible latency at the expense of overhead" could then 1308 translate into automatically disabling the Nagle algorithm. 1310 In some cases, the Nagle algorithm is best controlled directly by the 1311 application because it is not only related to a general profile but 1312 also to knowledge about the size of future messages. For fine-grain 1313 control over Nagle-like functionality, the "Request not to bundle 1314 messages" is available. 1316 5.6. Security 1318 Both TCP and SCTP offer authentication. SCTP allows to configure 1319 which of SCTP's chunk types must always be authenticated -- if this 1320 is exposed as such, it creates an undesirable dependency on the 1321 transport protocol. Generally, to an application it is relevant 1322 whether the transport protocol authenticates its own control data, 1323 the user data, or both, and a TAPS system should therefore allow to 1324 configure and query these three cases. 1326 TBD -- more to come in the next version. This relates to the TCP 1327 Authentication Option in Section 7.1 of [RFC5925], which is not 1328 currently covered. 1330 Set Cookie life value -- TBD in the next version: SCTP is client- 1331 side, TCP is server-side. 1333 5.7. Packet Size 1335 UDP(-Lite) has a transport feature called "Specify DF field". This 1336 yields an error message in case of sending a message that exceeds the 1337 Path MTU, which is necessary for a UDP-based application to be able 1338 to implement Path MTU Discovery (a function that UDP-based 1339 applications must do by themselves). This is the only transport 1340 feature related to packet sizes. UDP applications typically make use 1341 of IP-layer functionality to obtain the size of the link MTU; it 1342 would therefore seem that offering such functionality to TAPS 1343 applications could be useful, albeit in a transport protocol 1344 independent way. 1346 This also relates to the fact that the choice of path is automatable: 1347 if a TAPS system can switch a path at any time, unknown to an 1348 application, yet the application intends to do Path MTU Discovery, 1349 this could yield very inefficient behavior. Thus, a TAPS system 1350 should probably avoid automatically switching paths, and inform the 1351 application about any unavoidable path changes, when applications 1352 request to disallow fragmentation with the "Specify DF field" 1353 feature. 1355 6. Step 4: Construction -- the Minimal Set of Transport Features 1357 Based on the categorization, reduction and discussion in the previous 1358 sections, this section presents the minimal set of transport features 1359 that is offered by end systems supporting TAPS. They are described 1360 in an abstract fashion, i.e. they can be implemented in various 1361 different ways. For example, information that is provided to an 1362 application can either be offered via a primitive that is polled, or 1363 via an asynchronous notification. 1365 Future versions of this document will probably describe the transport 1366 features in this section in greater detail; for now, we only specify 1367 how they differ from the transport features they are based upon. We 1368 carry out an additional simplification: CONNECTION.ESTABLISHMENT 1369 "Specify number of attempts and/or timeout for the first 1370 establishment message" and CONNECTION.MAINTENANCE "Change timeout for 1371 aborting connection (using retransmit limit or time value)" are 1372 essentially the same, just applied upon connection establishment or 1373 during the lifetime of a connection. The same is the case for 1374 CONNECTION.ESTABLISHMENT "Specify which chunk types must always be 1375 authenticated" and CONNECTION.MAINTENANCE "Change authentication 1376 parameters". We therefore state that connections (called TAPS flows) 1377 must be instantiated before connecting them, and allow configurations 1378 to be carried out before connecting (in cases where this is not 1379 allowed by the transport protocol, a TAPS system will have to 1380 internall delay this configuration until the flow has been 1381 connected). 1383 6.1. Flow Creation, Connection and Termination 1385 A TAPS flow must be "created" before it is connected, to allow for 1386 initial configurations to be carried out. All configuration 1387 parameters in Section 6.2 and Section 6.3 can be used initially, 1388 although some of them may only take effect when the flow has been 1389 connected. Configuring a flow early helps a TAPS system make the 1390 right decisions. In particular, the "group number" can influence the 1391 the TAPS system to implement a TAPS flow as a stream of a multi- 1392 streaming protocol's existing association or not. 1394 A created flow can be queried for the maximum amount of data that an 1395 application can possibly expect to have transmitted before or during 1396 connection establishment. An application can also give the flow a 1397 message for transmission before or during connection establishment, 1398 and specify which case is preferred (before / during). In case of 1399 transmission before establishment, the receiving application must be 1400 prepared to potentially receive multiple copies of the message. 1402 To be compatible with multiple transports, including streams of a 1403 multi-streaming protocol (used as if they were transports 1404 themselves), the semantics of opening and closing need to be the most 1405 restrictive subset of all of them. For example, TCP's support of 1406 half-closed connections can be seen as a feature on top of the more 1407 restrictive "ABORT"; this feature cannot be supported because not all 1408 protocols used by a TAPS system (including streams of an association) 1409 support half-closed connections. 1411 After creation, a flow can be actively connected to the other side 1412 using "Connect", or passively listen for incoming connection requests 1413 with "Listen". Note that "Connect" may or may not trigger a 1414 notification on the listening side. It is possible that the first 1415 notification on the listening side is the arrival of the first data 1416 that the active side sends (a receiver-side TAPS system could handle 1417 this by continuing a blocking "Listen" call, immediately followed by 1418 issuing "Receive", for example). This also means that the active 1419 opening side is assumed to be the first side sending data. 1421 A flow can be actively closed, i.e. terminated after reliably 1422 delivering all remaining data, or aborted, i.e. terminated without 1423 delivering remaining data. A timeout can be configured to abort a 1424 flow when data could not be delivered for too long. Because half- 1425 closed connections are not supported, when a TAPS host receives a 1426 notification that the peer is closing or aborting the flow, the other 1427 side may not be able to read outstanding data. This means that 1428 unacknowledged data residing in the TAPS system's send buffer may 1429 have to be dropped from that buffer upon arrival of a notification to 1430 close or abort the flow from the peer. In case of SCTP streams, 1431 "Stream Reset" (a "SSN Reset Request Parameter" in a "RE-CONFIG" 1432 chunk [RFC6525]) can be used to notify a peer of an intention to 1433 close a flow. 1435 6.2. Flow Group Configuration 1437 A flow group can be configured with a number of transport features, 1438 and there are some notifications to applications about a flow group. 1439 Here we list transport features and notifications that are taken from 1440 Section 4 unchanged, with the exception that some of them can also be 1441 applied initially (before a flow is connected). 1443 Timeout, error notifications: 1444 o Change timeout for aborting connection (using retransmit limit or 1445 time value) 1446 o Suggest timeout to the peer 1447 o Notification of Excessive Retransmissions (early warning below 1448 abortion threshold) 1449 o Notification of ICMP error message arrival 1451 Checksums: 1452 o Disable checksum when sending 1453 o Disable checksum requirement when receiving 1454 o Specify checksum coverage used by the sender 1455 o Specify minimum checksum coverage required by receiver 1457 Others: 1458 o Choose a scheduler to operate between flows of a group 1460 The following transport features are new or changed, based on the 1461 discussion in Section 5: 1462 o Capacity profile 1463 This describes how an application wants to use its available 1464 capacity. Choices can be "lowest possible latency at the expense 1465 of overhead", "scavenger", and some more values that help 1466 determine the DSCP value for a flow (e.g. similar to table 1 in 1468 [I-D.ietf-tsvwg-rtcweb-qos]). (details TBD) 1470 o Authentication 1471 TBD in the next version: Different from SCTP's original transport 1472 features, this will only allow to configure authenticating the 1473 whole transport, all control information, or user data (not to 1474 distinguish between various SCTP chunks, to avoid this protocol 1475 dependency). It will also have to be made in line with TCP 1476 Authentication [RFC5925]. For SCTP, this functionality will be 1477 based on the transport features "Change authentication 1478 parameters", "Obtain authentication information" and the initially 1479 available "Specify which chunk types must always be 1480 authenticated". Note that SCTP also allows per-message 1481 configuration via "Specifying a key id to be used to authenticate 1482 a message", which may affect Section 6.4. 1484 o Set Cookie life value 1485 TBD in the next version (not yet sure how to handle the client vs. 1486 server semantics of SCTP and TCP, respectively) 1488 6.3. Flow Configuration 1490 A flow can be assigned a priority or weight for a scheduler. 1492 6.4. Data Transfer 1494 6.4.1. The Sender 1496 This section discusses how to send data after flow establishment. 1497 Section 6.1 discusses the possiblity to hand over a message to send 1498 before or during establishment. 1500 For compatibility with TCP receiver semantics, we define an 1501 "Application-Framed Bytestream". This is a bytestream where the 1502 sending application optionally informs the transport about frame 1503 boundaries and required properties per frame (configurable order and 1504 reliability, or embedding a request not to delay the acknowledgement 1505 of a frame). Whenever the sending application specifies per-frame 1506 properties that relax the notion of reliable in-order delivery of 1507 bytes, it must assume that the receiving application is 1) able to 1508 determine frame boundaries, provided that frames are always kept 1509 intact, and 2) able to accept these relaxed per-frame properties. 1510 Any signaling of such information to the peer is up to an 1511 application-layer protocol and considered out of scope of this 1512 document. 1514 Here we list per-frame properties that a sender can optionally 1515 configure if it hands over a delimited frame for sending with 1516 congestion control, taken from Section 4: 1517 o Configurable Message Reliability 1518 o Choice between unordered (potentially faster) or ordered delivery 1519 of messages 1520 o Request not to bundle messages 1521 o Request not to delay the acknowledgement (SACK) of a message 1523 Additionally, an application can hand over delimited frames for 1524 unreliable transmission without congestion control (note that such 1525 applications should perform congestion control in accordance with 1526 [RFC2914]). Then, none of the per-frame properties listed above have 1527 any effect, but it is possible to use the transport feature "Specify 1528 DF field" to allow/disallow fragmentation. 1530 AUTHOR'S NOTE: do folks agree with this design? It ties 1531 fragmentation to UDP only, because we called SCTP's "Configure 1532 message fragmentation" transport feature "automatable". It is indeed 1533 questionable whether applications need control over fragmentation 1534 when they work with SCTP -- doing so creates a complication for app 1535 writers that may not be necessary, especially when messages can be 1536 interleaved. 1538 Following Section 5.7, there are two new transport features and a 1539 notification: 1540 o Query maximum unfragmented frame size 1541 This is optional for a TAPS system to offer, and if it is offered, 1542 it informs the sender about the maximum expected size of a data 1543 frame that it can send without fragmentation. This can aid 1544 applications implementing Path MTU Discovery. 1546 o Query maximum transport frame size 1547 Irrespective of fragmentation, there is a size limit for the 1548 messages that can be handed over to SCTP or UDP(-Lite); because a 1549 TAPS system is independent of the transport, it must allow a TAPS 1550 application to query this value -- the maximum size of a frame in 1551 an Application-Framed-Bytestream. 1553 o Notify the application of a path change 1554 If an application has disallowed fragmentation via the "Specify DF 1555 field" transport feature, this notification may optionally tell it 1556 that a path has changed (with a means to identify the path, so 1557 that the application can e.g. tell two flipping paths apart from 1558 completely diverse path changes). This informs the application 1559 that it may have to repeat Path MTU Discovery, and it can have 1560 relevance for application-level congestion control. For MPTCP and 1561 SCTP, a TAPS system can implement this functionality using the 1562 "Obtain status (query or notification)" transport feature. 1564 There are two more sender-side notifications. These are unreliable, 1565 i.e. a TAPS system cannot be assumed to implement them, but they may 1566 occur: 1567 o Notification of send failures 1568 A TAPS system may inform a sender application of a failure to send 1569 a specific frame. This was taken over unchanged from Section 4. 1571 o Notification of draining below a low water mark 1572 A TAPS system can notify a sender application when the TAPS 1573 system's filling level of the buffer of unsent data is below a 1574 configurable threshold in bytes. Even for TAPS systems that do 1575 implement this notification, supporting thresholds other than 0 is 1576 optional. 1578 "Notification of draining below a low water mark" is a generic 1579 notification that tries to enable uniform access to 1580 "TCP_NOTSENT_LOWAT" as well as the "SENDER DRY" notification (as 1581 discussed in Section 5.4 -- SCTP's "SENDER DRY" is a special case 1582 where the threshold is 0). Note that this threshold and its 1583 notification should operate across the buffers of the whole TAPS 1584 system, i.e. also any potential buffers that the TAPS system itself 1585 may use on top of the transport's send buffer. 1587 6.4.2. The Receiver 1589 A receiving application obtains an Application-Framed Bytestream. 1590 Similar to TCP's receiver semantics, it is just stream of bytes. If 1591 frame boundaries were specified by the sender, a TAPS system will 1592 still not inform the receiving application about them, but frames 1593 themselves will always stay intact (partial frames are not supported 1594 - see Section 5.1). Different from TCP's semantics, there is no 1595 guarantee that all bytes in the bytestream are received, and that all 1596 of them are in the same sequence in which they were handed over by 1597 the sender. If an application is aware of frame delimiters in the 1598 bytestream, and if the sender-side application has informed the TAPS 1599 system about these boundaries and about potentially relaxed 1600 requirements regarding the sequence of frames or per-frame 1601 reliability, frames within the receiver-side bytestream may be out- 1602 of-order or missing. 1604 7. Conclusion 1606 By decoupling applications from transport protocols, a TAPS system 1607 provides a different abstraction level than the Berkeley sockets 1608 interface. As with high- vs. low-level programming languages, a 1609 higher abstraction level allows more freedom for automation below the 1610 interface, yet it takes some control away from the application 1611 programmer. This is the design trade-off that a TAPS system 1612 developer is facing, and this document provides guidance on the 1613 design of this abstraction level. Some transport features are 1614 currently rarely offered by APIs, yet they must be offered or they 1615 can never be used ("functional" transport features). Other transport 1616 features are offered by the APIs of the protocols covered here, but 1617 not exposing them in a TAPS API would allow for more freedom to 1618 automate protocol usage in a TAPS system. 1620 The minimal set presented in this document is an effort to find a 1621 middle ground that can be recommended for TAPS systems to implement, 1622 on the basis of the transport features discussed in [TAPS2]. This 1623 middle ground eliminates a large number of transport features on the 1624 basis that they do not require application-specific knowledge, but 1625 rather rely on knowledge about the network or the Operating System. 1626 This leaves us with an unanswered question about how exactly a TAPS 1627 system should automate using all these transport features. 1629 The answers are different for every case. In some cases, it may be 1630 best to not entirely automate the decision making, but leave it up to 1631 a system-wide policy. For example, when multiple paths are 1632 available, a system policy could guide the decision on whether to 1633 connect via a WiFi or a cellular interface. Such high-level guidance 1634 could also be provided by application developers, e.g. via a 1635 primitive that lets applications specify such preferences. As long 1636 as this kind of information from applications is treated as advisory, 1637 it will not lead to a permanent protocol binding and does therefore 1638 not limit the flexibility of a TAPS system. Decisions to add such 1639 primitives are therefore left open to TAPS system designers. 1641 8. Acknowledgements 1643 The authors would like to thank the participants of the TAPS Working 1644 Group and the NEAT research project for valuable input to this 1645 document. We especially thank Michael Tuexen for help with TAPS flow 1646 connection establishment/teardown and Gorry Fairhurst for his 1647 suggestions regarding fragmentation and packet sizes. This work has 1648 received funding from the European Union's Horizon 2020 research and 1649 innovation programme under grant agreement No. 644334 (NEAT). The 1650 views expressed are solely those of the author(s). 1652 9. IANA Considerations 1654 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 1656 This memo includes no request to IANA. 1658 10. Security Considerations 1660 Authentication, confidentiality protection, and integrity protection 1661 are identified as transport features by [RFC8095]. As currently 1662 deployed in the Internet, these features are generally provided by a 1663 protocol or layer on top of the transport protocol; no current full- 1664 featured standards-track transport protocol provides all of these 1665 transport features on its own. Therefore, these transport features 1666 are not considered in this document, with the exception of native 1667 authentication capabilities of TCP and SCTP for which the security 1668 considerations in [RFC5925] and [RFC4895] apply. 1670 11. References 1672 11.1. Normative References 1674 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 1675 Ed., "Services Provided by IETF Transport Protocols and 1676 Congestion Control Mechanisms", RFC 8095, DOI 10.17487/ 1677 RFC8095, March 2017, 1678 . 1680 [TAPS2] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of 1681 Transport Features Provided by IETF Transport Protocols", 1682 draft-ietf-taps-transports-usage-03 (work in progress), 1683 March 2017. 1685 11.2. Informative References 1687 [COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte 1688 Stuffing", September 1997, 1689 . 1691 [I-D.ietf-tsvwg-rtcweb-qos] 1692 Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP 1693 Packet Markings for WebRTC QoS", 1694 draft-ietf-tsvwg-rtcweb-qos-18 (work in progress), 1695 August 2016. 1697 [LBE-draft] 1698 Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", 1699 draft-tsvwg-le-phb-00 (work in progress), October 2016. 1701 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 1702 RFC 2914, DOI 10.17487/RFC2914, September 2000, 1703 . 1705 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 1706 "Authenticated Chunks for the Stream Control Transmission 1707 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, 1708 August 2007, . 1710 [RFC5290] Floyd, S. and M. Allman, "Comments on the Usefulness of 1711 Simple Best-Effort Traffic", RFC 5290, DOI 10.17487/ 1712 RFC5290, July 2008, 1713 . 1715 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1716 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1717 June 2010, . 1719 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 1720 Yasevich, "Sockets API Extensions for the Stream Control 1721 Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/ 1722 RFC6458, December 2011, 1723 . 1725 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 1726 Transmission Protocol (SCTP) Stream Reconfiguration", 1727 RFC 6525, DOI 10.17487/RFC6525, February 2012, 1728 . 1730 [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet 1731 Technology Adoption and Transition (ITAT)", RFC 7305, 1732 DOI 10.17487/RFC7305, July 2014, 1733 . 1735 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1736 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1737 . 1739 [WWDC2015] 1740 Lakhera, P. and S. Cheshire, "Your App and Next Generation 1741 Networks", Apple Worldwide Developers Conference 2015, San 1742 Francisco, USA, June 2015, 1743 . 1745 Appendix A. Revision information 1747 XXX RFC-Ed please remove this section prior to publication. 1749 -02: implementation suggestions added, discussion section added, 1750 terminology extended, DELETED category removed, various other fixes; 1751 list of Transport Features adjusted to -01 version of [TAPS2] except 1752 that MPTCP is not included. 1754 -03: updated to be consistent with -02 version of [TAPS2]. 1756 -04: updated to be consistent with -03 version of [TAPS2]. 1757 Reorganized document, rewrote intro and conclusion, and made a first 1758 stab at creating a real "minimal set". 1760 Authors' Addresses 1762 Stein Gjessing 1763 University of Oslo 1764 PO Box 1080 Blindern 1765 Oslo, N-0316 1766 Norway 1768 Phone: +47 22 85 24 44 1769 Email: steing@ifi.uio.no 1771 Michael Welzl 1772 University of Oslo 1773 PO Box 1080 Blindern 1774 Oslo, N-0316 1775 Norway 1777 Phone: +47 22 85 24 20 1778 Email: michawe@ifi.uio.no