idnits 2.17.1 draft-iab-considerations-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2914' is mentioned on line 412, but not defined == Missing Reference: 'RFC 2130' is mentioned on line 709, but not defined == Missing Reference: 'RFC 2277' is mentioned on line 711, but not defined == Outdated reference: A later version (-03) exists of draft-tsvarea-sipchange-02 == Outdated reference: A later version (-05) exists of draft-klensin-dns-role-03 -- Obsolete informational reference (is this intentional?): RFC 2481 (Obsoleted by RFC 3168) -- Obsolete informational reference (is this intentional?): RFC 2598 (Obsoleted by RFC 3246) -- Obsolete informational reference (is this intentional?): RFC 3205 (Obsoleted by RFC 9205) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Floyd, Editor 3 INTERNET DRAFT 4 draft-iab-considerations-02.txt August, 2002 6 General Architectural and Policy Considerations 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document suggests general architectural and policy questions 32 that the IETF community has to address when working on new standards 33 and protocols. We note that this document contains questions to be 34 addressed, as opposed to guidelines or architectural principles to be 35 followed. 37 Changes from draft-iab-considerations-01.txt: 39 * Added a discussion on overloading. 41 * Added a discussion on complexity, robustness, and fragility. 43 * Added a section on Internationalization. 45 1. Introduction 47 This document suggests general architectural and policy questions to 48 be addressed in our work in the IETF. This document contains 49 questions to be addressed, as opposed to guidelines or architectural 50 principles to be followed. These questions are somewhat similar to 51 the "Security Considerations" currently required in IETF documents 52 [RFC2316]. 54 This document is motivated in part by concerns about a growing lack 55 of coherence in the overall Internet architecture. We have moved 56 from a world of a single, coherent architecture designed by a small 57 group of people, to a world of a complex, intricate architecture to 58 address a wide-spread and heterogeneous environment. Because 59 individual pieces of the architecture are often designed by sub- 60 communities, with each sub-community having its own set of interests, 61 it is necessary to pay increasing attention to how each piece fits 62 into the larger picture, and to consider how each piece is chosen. 63 For example, it is unavoidable that each of us is inclined to solve a 64 problem at the layer of the protocol stack and using the tools that 65 we understand the best; that does not necessarily mean that this is 66 the most appropriate layer or set of tools for solving this problem 67 in the long-term. 69 2. Relationship to "Architectural Principles of the Internet" 71 RFC 1958 [RFC1958] outlines some architectural principles of the 72 Internet, as "guidelines that have been found useful in the past, and 73 that may be useful to those designing new protocols or evaluating 74 such designs." An example guideline is that "it is also generally 75 felt that end-to-end functions can best be realized by end-to-end 76 protocols." Similarly, an example design issue from [RFC1958] is that 77 "heterogeneity is inevitable and must be supported by design." 79 In contrast, this document serves a slightly different purpose, by 80 suggesting additional architectural questions to be addressed. Thus, 81 one question suggested in this document is the following: "Is this 82 proposal the best long-term solution to the problem? If not, what 83 are the long-term costs of this solution, in terms of restrictions on 84 future development, if any?" This question could be translated to a 85 roughly equivalent architectural guideline, as follows: "Identify 86 whether the proposed protocol is a long-term solution or a short-term 87 solution, and identify the long-term costs and the exit strategy for 88 any short-term solutions." 90 In contrast, other questions are more open-ended, such as the 91 question about robustness: "How robust is the protocol, not just to 92 the failure of nodes, but also to compromised or malfunctioning 93 nodes, imperfect or defective implementations, etc?" As a community, 94 we are still learning about the degree of robustness that we are able 95 to build into our protocols, as well as the tools that are available 96 to ensure this robustness. Thus, there are not yet clear 97 architectural guidelines along the lines of "Ensure that your 98 protocol is robust against X, Y, and Z." 100 3. Questions. 102 In this section we list some questions to ask in designing protocols. 103 Each question is discussed in more depth in the rest of this paper. 104 We aren't suggesting that all protocol design efforts should be 105 required to explicitly answer all of these questions; some questions 106 will be more relevant to one document than to another. We also 107 aren't suggesting that this is a complete list of architectural 108 concerns. 110 Justifying the Solution: 112 * Why are you proposing this solution, instead of proposing something 113 else? 115 Interactions between Layers: 117 * Why are you proposing a solution at this layer of the protocol 118 stack, rather than at another layer? Are there solutions at other 119 layers of the protocol stack as well? 121 * Is this an appropriate layer in terms of correctness of function, 122 data integrity, performance, ease of deployment, the diagnosibility 123 of failures, and other concerns? 125 * What are the interactions between layers, if any? 127 Long-term vs. Short-term Solutions: 129 * Is this proposal the best long-term solution to the problem? 131 * If not, what are the long-term costs of this solution, in terms of 132 restrictions on future development, if any? What are the 133 requirements for the development of longer-term solutions? 135 Robustness: 137 * How robust is the protocol, not just to the failure of nodes, but 138 also to compromised or malfunctioning nodes, imperfect or defective 139 implementations, etc? 140 Tragedy of the Commons: 142 * Is performance still robust if everyone is using this protocol? 143 Are there other potential impacts of widespread deployment that need 144 to be considered? 146 Protecting Competing Interests: 148 * Does the protocol protect the interests of competing parties (e.g., 149 not only end-users, but also ISPs, router vendors, software vendors, 150 or other parties)? Is the design modularized to allow competing 151 interests to play out, while also isolating "tussles" and preventing 152 them from spilling out into unrelated areas? 154 Designing for Choice vs. Avoiding Unnecessary Complexity: 156 * Is the protocol designed for choice, to allow different players to 157 express their preferences where appropriate? At the same time, does 158 the protocol avoid the "kitchen sink" approach of providing too many 159 options and too much choice? 161 Weighing Benefits against Costs: 163 * How do the architectural benefits of a proposed new protocol 164 compare against the architectural costs, if any? Have the 165 architectural costs been carefully considered? 167 The Whole Picture vs. Building Blocks: 169 * Have you considered the larger context, while appropriately 170 restricting your own design efforts to one part of the whole? 172 * Are there parts of the overall solution that will have to be 173 provided by other IETF Working Groups or by other standards bodies? 175 Preserving Evolvability? 177 * Does the protocol protect the interests of the future, by 178 preserving the evolvability of the Internet? Does the protocol 179 enable future developments? 181 * If an old protocol is overloaded with new functionality, or reused 182 for new purposes, have the possible complexities introduced been 183 taken carefully into account? 185 * For a protocol that introduces new complexity to the Internet 186 architecture, how does the protocol add robustness and preserve 187 evolvability, and how does it also introduce new fragilities to the 188 system? 190 Internationalization: 192 * Where protocols require elements in text format, have the possibly 193 conflicting requirements of global comprehensibility and the ability 194 to represent local text content been properly weighed against each 195 other? 197 Each of these questions is discussed in more depth in the rest of 198 this paper. 200 4. Justifying the Solution. 202 Question: Why are you proposing this solution, instead of proposing 203 something else? 205 4.1. Case study: Integrated and Differentiated Services. 207 A good part of the work of developing integrated and differentiated 208 services has been to understand the problem to be solved, and to come 209 to agreement on the architectural framework of the solution, and on 210 the nature of specific services. Thus, when integrated services was 211 being developed, the specification of the Controlled Load [RFC2211] 212 and Guaranteed [RFC2212] services each required justification of the 213 need for that particular service, of low loss and bounded delay 214 respectively. 216 Later, when RFC 2475 on "An Architecture for Differentiated Services" 217 proposed a scalable, service differentiation architecture that 218 differs from the previously-defined architecture for integrated 219 services, the document also had to clearly justify the requirements 220 for this new architecture, and compare the proposed architecture to 221 other possible approaches [RFC2475]. Similarly, when the Assured 222 Forwarding [RFC2597] and Expedited Forwarding [RFC2598] Per-Hop 223 Behaviors of differentiated services were proposed, each service 224 required a justification of the need for that service in the 225 Internet. 227 5. Interactions between Layers. 229 Questions: Why are you proposing a solution at this layer of the 230 protocol stack, rather than at another layer? Are there solutions at 231 other layers of the protocol stack as well? 233 Is this an appropriate layer in terms of correctness of function, 234 data integrity, performance, ease of deployment, the diagnosibility 235 of failures, and other concerns? 236 What are the interactions between layers, if any? 238 5.1. Case study: Endpoint Congestion Management. 240 The goal of the Congestion Manager in Endpoint Congestion Management 241 is to allow multiple concurrent flows with the same source and 242 destination address to share congestion control state [RFC3124]. 243 There has been a history of proposals for multiplexing flows at 244 different levels of the protocol stack; proposals have included 245 adding multiplexing at the HTTP (WebMux) and TCP (TCP Control Blocks) 246 layers, as well as below TCP (the Congestion Manager) [Multiplexing]. 248 However, the 1989 article on "Layered Multiplexing Considered 249 Harmful" suggests that "the extensive duplication of multiplexing 250 functionality across the middle and upper layers is harmful and 251 should be avoided" [T89]. Thus, one of the key issues in providing 252 mechanisms for multiplexing flows is to determine which layer of the 253 protocol stack is most appropriate for providing this functionality. 254 The natural tendency of each researcher is generally to add 255 functionality at the layer that they know the best; this does not 256 necessarily result in the most appropriate overall architecture. 257 This is elaborated upon in the section below. 259 5.2. Discussion: The End-to-End Argument 261 The classic 1984 paper on "End-To-End Arguments In System Design" 262 [SRC84] begins a discussion of where to place functions among modules 263 by suggesting that "functions placed at low levels of a system may be 264 redundant or of little value when compared with the cost of providing 265 them at that low level. Examples discussed in the paper include bit 266 error recovery, security using encryption, duplicate message 267 suppression, recovery from system crashes, and delivery 268 acknowledgement. Low level mechanisms to support these functions are 269 justified only as performance enhancements." The end-to-end 270 principle is one of the key architectural guidelines to consider in 271 choosing the appropriate layer for a function. 273 5.3. Case study: Layering Applications on Top of HTTP. 275 There has been considerable interest in layering applications on top 276 of HTTP [RFC3205]. Reasons cited include compatibility with widely- 277 deployed browsers, the ability to reuse client and server libraries, 278 the ability to use existing security mechanisms, and the ability to 279 traverse firewalls. As RFC 3205 discusses, "the recent interest in 280 layering new protocols over HTTP has raised a number of questions 281 when such use is appropriate, and the proper way to use HTTP in 282 contexts where it is appropriate." Thus, RFC 3205 addresses not only 283 the benefits of layering applications on top of HTTP, but also 284 evaluates the additional complexity and overhead of layering an 285 application on top of HTTP, compared to the costs of introducing a 286 special-purpose protocol. 288 The web page on "References on Layering and the Internet 289 Architecture" has pointers to additional papers discussing general 290 layering issues in the Internet architecture [Layering]. 292 6. Long-term vs. Short-term Solutions 294 Questions: Is this proposal the best long-term solution to the 295 problem? 297 If not, what are the long-term costs of this solution, in terms of 298 restrictions on future development, if any? What are the 299 requirements for the development of longer-term solutions? 301 6.1. Case study: Traversing NATs. 303 In order to address problems with NAT middleboxes altering the 304 external address of endpoints, various proposals have been made for 305 mechanisms where an originating process attempts to determine the 306 address (and port) by which it is known on the other side of a NAT. 307 This would allow an originating process to be able to use address 308 data in the protocol exchange, or to advertise an external address 309 from which it will receive connections. 311 The IAB in [UNSAF] has outlined reasons why these proposals can be 312 considered at best as short-term fixes to specific problems, and the 313 specific issues to be carefully evaluated before standardizing such 314 proposals. These issues include the identification of the limited- 315 scope problem to be fixed, the description of an exit strategy for 316 the short-term solution, and the description of the longer-term 317 problems left unsolved by the short-term solution. 319 7. General Robustness Questions 321 Questions: How robust is the protocol, not just to the failure of 322 nodes, but also to compromised or malfunctioning nodes, imperfect or 323 defective implementations, etc? 325 Does the protocol take into account the realistic conditions of the 326 current or future Internet (e.g., packet drops and packet corruption; 327 packet reordering; asymmetric routing; etc.)? 329 7.1. Discussion: Designing for Robustness. 331 Robustness has long been cited as one of the overriding goals of the 332 Internet architecture [Clark88]. The robustness issues discussed in 333 [Clark88] largely referred to the robustness of packet delivery even 334 in the presence of failed routers; today robustness concerns have 335 widened to include a goal of robust performance in the presence of a 336 wide range of failures, buggy code, and malicious actions. 338 As [ASSW02] argues, protocols need to be designed somewhat 339 defensively, to maximize robustness against inconsistencies and 340 errors. [ASSW02] discusses several approaches for increasing 341 robustness in protocols, such as verifying information whenever 342 possible; designing interfaces that are conceptually simple and 343 therefore less conducive to error; protecting resources against 344 attack or overuse; and identifying and exposing errors so that they 345 can be repaired. 347 Techniques for verifying information range from verifying that 348 acknowledgements in TCP acknowledge data that was actually sent, to 349 providing mechanisms for routers to verify information in routing 350 messages. 352 Techniques for protecting resources against attack range from 353 preventing "SYN flood" attacks by designing protocols that don't 354 allocate resources for a single SYN packet, to partitioning resources 355 (e.g., preventing one flow or aggregate from using all of the link 356 bandwidth). 358 7.2. Case Study: Explicit Congestion Notification (ECN). 360 The Internet is based on end-to-end congestion control, and 361 historically the Internet has used packet drops as the only method 362 for routers to indicate congestion to the end nodes. ECN [RFC3168] 363 is a recent addition to the IP architecture to allow routers to set a 364 bit in the IP packet header to inform end-nodes of congestion, 365 instead of dropping the packet. 367 The first, Experimental specification of ECN [RFC2481] contained an 368 extensive discussion of the dangers of a rogue or broken router 369 "erasing" information from the ECN field in the IP header, thus 370 preventing indications of congestion from reaching the end-nodes. To 371 add robustness, the standards-track specification [RFC3168] specified 372 an additional codepoint in the IP header's ECN field, to use for an 373 ECN "nonce". The development of the ECN nonce was motivated by 374 earlier research on specific robustness issues in TCP [SCWA99]. RFC 375 3168 explains that the addition of the codepoint "is motivated 376 primarily by the desire to allow mechanisms for the data sender to 377 verify that network elements are not erasing the CE codepoint, and 378 that data receivers are properly reporting to the sender the receipt 379 of packets with the CE codepoint set, as required by the transport 380 protocol." Supporting mechanisms for the ECN nonce are needed in the 381 transport protocol to ensure robustness of delivery of the ECN-based 382 congestion indication. 384 In contrast, a more difficult and less clear-cut robustness issue for 385 ECN concerns the differential treatment of packets in the network by 386 middleboxes, based on the TCP header's ECN flags in a TCP SYN packet 387 [RFC3360]. The issue concerns "ECN-setup" SYN packets, that is, SYN 388 packets with ECN flags set in the TCP header to negotiate the use of 389 ECN between the two TCP end-hosts. There exist firewalls in the 390 network that drop "ECN-setup" SYN packets, others that send TCP Reset 391 messages, and yet others that zero ECN flags in TCP headers. None of 392 this was anticipated by the designers of ECN, and RFC 3168 added 393 optional mechanisms to permit the robust operation of TCP in the 394 presence of firewalls that drop "ECN-setup" SYN packets. However, 395 ECN is still not robust to all possible scenarios of middleboxes 396 zeroing ECN flags in the TCP header. Up until now, transport 397 protocols have been standardized independently from the mechanisms 398 used by middleboxes to control the use of these protocols, and it is 399 still not clear what degree of robustness is required from transport 400 protocols in the presence of the unauthorized modification of 401 transport headers in the network. These and similar issues are 402 discussed in more detail in [RFC3360]. 404 8. Avoiding Tragedy of the Commons. 406 Question: Is performance still robust if everyone is using the new 407 protocol? Are there other potential impacts of widespread deployment 408 that need to be considered? 410 8.1. Case Study: End-to-end Congestion Control. 412 [RFC2914] discusses the potential for congestion collapse if flows 413 are not using end-to-end congestion control in a time of high 414 congestion. For example, if a new transport protocol was proposed 415 that did not use end-to-end congestion control, it might be easy to 416 show that a flow using the new transport protocol would perform quite 417 well as long as all of the competing flows in the network were using 418 end-to-end congestion control. To fully evaluate the new transport 419 protocol, it is necessary to look at performance when many flows are 420 competing, all using the new transport protocol. If all of the 421 competing flows were using the more aggressive transport protocol in 422 a time of high congestion, the result could be a tragedy of the 423 commons, with many links busy carrying packets that will only be 424 dropped downstream. 426 9. Balancing Competing Interests 428 Question: Does the protocol protect the interests of competing 429 parties (e.g., not only end-users, but also ISPs, router vendors, 430 software vendors, or other parties)? Is the design modularized to 431 allow competing interests to play out, while also isolating "tussles" 432 and preventing them from spilling out into unrelated areas? 434 9.1. Discussion: balancing competing interests 436 [CWSB02] discusses the role that competition between competing 437 interests plays in the evolution of the Internet, and takes the 438 position that the role of Internet protocols is to design the playing 439 field in this competition, rather than to pick the outcome. The IETF 440 has long taken the position that it can only design the protocols, 441 and that often two competing approaches will be developed, with the 442 marketplace left to decide between them [A02]. (It has also been 443 suggested that "the marketplace" left entirely to itself does not 444 always make the best decisions, and that working to identify and 445 adopt the technically best solution is sometimes helpful.) 447 An example cited in [CWSB02] of modularization in support of 448 competing interests is the decision to use codepoints in the IP 449 header to select QoS, rather than binding QoS to other properties 450 such as port numbers. This separates the structural and economic 451 issues related to QoS from technical issues of protocols and port 452 numbers, and allows space for a wide range of structural and pricing 453 solutions to emerge. 455 It has also been suggested that companies in some cases have an 456 incentive to add complexity to protocol design in order to make the 457 protocol more difficult to implement, as a way of increasing the 458 barrier for competition. Clearly if this were to occur, such a 459 protocol would not be protecting the interests of competing parties. 461 10. Designing for Choice vs. Avoiding Unnecessary Complexity: 463 Is the protocol designed for choice, to allow different players to 464 express their preferences where appropriate? At the same time, does 465 the protocol avoid the "kitchen sink" approach of providing too many 466 options and too much choice? 468 10.1. Discussion: the importance of choice 470 [CWSB02] suggests that "the fundamental design goal of the Internet 471 is to hook computers together, and since computers are used for 472 unpredictable and evolving purposes, making sure that the users are 473 not constrained in what they can do is doing nothing more than 474 preserving the core design tenet of the Internet. In this context, 475 user empowerment is a basic building block, and should be embedded 476 into all mechanism whenever possible." 478 As an example of choice, "the design of the mail system allows the 479 user to select his SMTP server and his POP server" [CWSB02]. More 480 open-ended questions about choice concern the design of mechanisms 481 that would enable the user to choose the path at the level of 482 providers, or to allow users to choose third-party intermediaries 483 such as web caches, or providers for Open Pluggable Edge Services 484 (OPES). [CWSB02] also notes that the issue of choice itself reflects 485 competing interests. For example, ISPs would generally like to lock 486 in customers, while customers would like to preserve their ability to 487 change among providers. 489 At the same time, we note that excessive choice can lead to "kitchen 490 sink" protocols that are inefficient and hard to understand, have too 491 much negotiation, or have unanticipated interactions between options. 492 These dangers are discussed in [BMMWRO02], which gives guidelines for 493 responding to the "continuous flood" of suggestions for modifications 494 and extensions to SIP (Session Initiation Protocol). In particular, 495 the SIP Working Group is concerned that proposed extensions have 496 general use, and do not provide efficiency at the expense of 497 simplicity or robustness. [BMMWRO02] suggests that other highly 498 extensible protocols developed in the IETF might also benefit from 499 more coordination of extensions. 501 11. Weighing architectural benefits against architectural costs. 503 Questions: How do the architectural benefits of a proposed new 504 protocol compare against the architectural costs, if any? Have the 505 architectural costs been carefully considered? 507 11.1. Case Study: Performance-enhancing proxies (PEPs) 509 RFC 3135 [RFC3135] considers the relative costs and benefits of 510 placing performance-enhancing proxies (PEPs) in the middle of a 511 network to address link-related degradations. In the case of PEPs, 512 the potential costs include disabling the end-to-end use of IP layer 513 security mechanisms; introducing a new possible point of failure that 514 is not under the control of the end systems; adding increased 515 difficulty in diagnosing and dealing with failures; and introducing 516 possible complications with asymmetric routing or mobile hosts. RFC 517 3135 carefully considers these possible costs, the mitigations that 518 can be introduced, and the cases when the benefits of performance- 519 enhancing proxies to the user are likely to outweight the costs. 521 11.2. Case Study: Open Pluggable Edge Services (OPES) 523 One of the issues raised by middleboxes in the Internet involves the 524 end-to-end integrity of data. This is illustrated in the recent 525 question of chartering the Open Pluggable Edge Services (OPES) 526 Working Group. Open Pluggable Edge Services are services that would 527 be deployed as application-level intermediaries in the network, for 528 example, at a web proxy cache between the origin server and the 529 client. These intermediaries would transform or filter content, with 530 the explicit consent of either the content provider or the end user. 532 One of the architectural issues that arose in the process of 533 chartering the OPES Working Group concerned the end-to-end integrity 534 of data. As an example, it was suggested that ``OPES would reduce 535 both the integrity, and the perception of integrity, of 536 communications over the Internet, and would significantly increase 537 uncertainly about what might have been done to content as it moved 538 through the network'', and that therefore the risks of OPES 539 outweighed the benefits [CDT01]. 541 As one consequence of this debate, the IAB wrote a document on "IAB 542 Architectural and Policy Considerations for OPES", considering both 543 the potential architectural benefits and costs of OPES [RFC3238]. 544 This document did not recommend specific solutions or mandate 545 specific functional requirements, but instead included 546 recommendations of issues such as concerns about data integrity that 547 OPES solutions standardized in the IETF should be required to 548 address. 550 11.3. Case Study: Stresses on DNS. 552 As an example, over and over again, we find people wanting to 553 overload the DNS with new services and functions. In each case, we 554 may ask whether or not it is feasible to add a particular feature, 555 and often the answer is yes. What we rarely ask is the impact of all 556 this added functionality on the provision of the original service. 557 [K02] considers many of the newer demands being placed upon the DNS. 559 12. Looking at the whole picture vs. making a building block. 561 For a complex protocol which interacts with protocols from other 562 standards bodies as well as from other IETF working groups, it can be 563 necessary to keep in mind the overall picture while, at the same 564 time, breaking out specific parts of the problem to be standardized 565 in particular working groups. 567 Question: Have you considered the larger context, while restricting 568 your own design efforts to one part of the whole? 569 Question: Are there parts of the overall solution that will have to 570 be provided by other IETF Working Groups or by other standards 571 bodies? 573 12.1. Case Study: The Session Initiation Protocol (SIP) 575 The Session Initiation Protocol (SIP) [RFC2543], for managing 576 connected, multimedia sessions, is an example of a complex protocol 577 that has been broken into pieces for standardization in other working 578 groups. SIP has also involved interaction with other standardization 579 bodies. 581 The basic SIP framework is being standardized by the SIP working 582 group. This working group has focused on the core functional 583 features of setting up, managing, and tearing down multimedia 584 sessions. Extensions are considered if they relate to these core 585 features. 587 The task of setting up a multimedia session also requires a 588 description of the desired multimedia session. This is provided by 589 the Session Description Protocol (SDP). SDP is a building block that 590 is supplied by the Multiparty Multimedia Session Control (MMUSIC) 591 working group. It is not standardized within the SIP working group. 593 Other working groups are involved in standardizing extensions to SIP 594 that fall outside of core functional features or applications. The 595 SIPPING working group is analyzing the requirements for SIP applied 596 to different tasks, and the SIMPLE working group is examining the 597 application of SIP to instant messaging and presence. The IPTEL 598 working group is defining a call processing language (CPL) that 599 interacts with SIP in various ways. These working groups occasionally 600 feed requirements back into the main SIP working group. 602 Finally, outside standardization groups have been very active in 603 providing the SIP working group with requirements. The Distributed 604 Call Signaling (DCS) group from the PacketCable Consortium, 3GPP, and 605 3GPP2 are all using SIP for various telephony-related applications, 606 and members of these groups have been involved in drafting 607 requirements for SIP. In addition, there are extensions of SIP which 608 are under consideration in these standardization bodies that are not 609 appropriate material for IETF, because they are not generally 610 applicable but only relate to the particular application of SIP being 611 developed by the standardization bodies. An example is particular 612 interactions with accounting and billing for mobile telephony. 614 13. Preserving evolvability? 616 Does the protocol protect the interests of the future, by preserving 617 the evolvability of the Internet? Does the protocol enable future 618 developments? 620 If an old protocol is overloaded with new functionality, or reused 621 for new purposes, have the possible complexities introduced been 622 taken into account? 624 For a protocol that introduces new complexity to the Internet 625 architecture, does the protocol add robustness and preserve 626 evolvability? Does it also introduce unwanted new fragilities to the 627 system? 629 13.1. Discussion: evolvability. 631 There is an extensive literature and an ongoing discussion about the 632 evolvability, or lack of evolvability, of the Internet 633 infrastructure; the web page on "Papers on the Evolvability of the 634 Internet Infrastructure" has pointers to some of this literature 635 [Evolvability]. Issues range from the evolvability and overloading 636 of the DNS; the difficulties of the Internet in evolving to 637 incorporate multicast, QoS, or IPv6; the difficulties of routing in 638 meeting the demands of a changing and expanding Internet; and the 639 role of firewalls and other middleboxes in limiting evolvability. 641 [CWSB02] suggests that among all of the issues of evolvability, 642 "keeping the net open and transparent for new applications is the 643 most important goal." In the beginning, the relative transparency of 644 the infrastructure in transmitting packets from one end-node to 645 another was sufficient to ensure evolvability. However, this 646 transparency has become more murky over time, as cataloged in 647 [RFC3234]. [CWSB02] also realistically suggests the following 648 guideline: "Failures of transparency will occur - design what happens 649 then." Thus, maintaining evolvability also requires mechanisms for 650 allowing evolution in the face of a lack of transparency of the 651 infrastructure itself. 653 13.2. Discussion: overloading. 655 There has been a strong tendency in the last few years to overload 656 some designs with new functionality, with resulting operational 657 complexities. Extensible protocols could be seen as one of the tools 658 for providing evolvability. However, if protocols and systems are 659 stretched beyond their reasonable design parameters, then scaling, 660 reliability, or security isssues could be introduced. Examples of 661 protocols that could be seen as either productively extended, or as 662 dangerously overloaded, include DNS [K02], MPLS, and BGP. In some 663 cases, overloading or extending a protocol may reduce total 664 complexity by avoiding the creation of a new protocol; in other cases 665 a new protocol might be the simpler solution. 667 We have a number of re-useable technologies, including component 668 technologies specifically designed for re-use. Examples include SASL, 669 BEEP and APEX. On the other hand, re-use should not go so far as to 670 turn a protocol into a Trojan Horse, as has happened with HTTP 671 [RFC3205]. 673 13.3. Discussion: complexity, robustness, and fragility. 675 [WD02] gives a historical account of the evolution of the Internet as 676 a complex system, with particular attention to the tradeoffs between 677 complexity, robustness, and fragility. [WD02] describes the 678 robustness that follows from the simplicity of a connectionless, 679 layered, datagram infrastructure and a universal logical addressing 680 scheme, and, as case studies, describes the increasing complexity of 681 TCP and of BGP. The paper describes a complexity/robustness spiral 682 of an initially robust design and the appearance of fragilities, 683 followed by modifications for more robustness that themselves 684 introduce new fragilities. [WD02] conjectures that "the Internet is 685 only now beginning to experience an acceleration of this 686 complexity/robustness spiral and, if left unattended, can be fully 687 expected to experience arcane, irreconcilable, and far-reaching 688 robustness problems in the not-too-distant future." Citing [WD02], 689 [BFM02] views complexity as the primary mechanism that impedes 690 efficient scaling, and discusses the ways that complexity increases 691 capital and operational expenditures in carrier IP networks. 693 14. Internationalization. 695 Where protocols require elements in text format, have the possibly 696 conflicting requirements of global comprehensibility and the ability 697 to represent local text content been properly weighed against each 698 other? 700 14.1. Discussion: internationalization. 702 RFC 1958 [RFC1958] included a simple statement of the need for a 703 common language: 705 "Public (i.e. widely visible) names should be in case-independent 706 ASCII. Specifically, this refers to DNS names, and to protocol 707 elements that are transmitted in text format." 709 The IETF has studied character set issues in general [RFC 2130] and 710 made specific recommendations for the use of a standardised approach 711 [RFC 2277]. The situation is complicated by the fact that some uses 712 of text are hidden entirely in protocol elements and need only be 713 read by machines, while other uses are intended entirely for human 714 consumption. Many uses lie between these two extremes, which leads to 715 conflicting implementation requirements. 717 For the specific case of DNS, the Internationalized Domain Name 718 working group is considering these issues. As stated in the charter 719 of that working group, "A fundamental requirement in this work is to 720 not disturb the current use and operation of the domain name system, 721 and for the DNS to continue to allow any system anywhere to resolve 722 any domain name." This leads to some very strong requirements for 723 backwards compatibility with the existing ASCII-only DNS. Yet since 724 the DNS has come to be used as if it was a directory service, domain 725 names are also expected to be presented to users in local character 726 sets. 728 This document does not attempt to resolve these complex and difficult 729 issues, but simply states this as an issue to be addressed in our 730 work. The requirement that names encoded in a text format within 731 protocol elements be universally decodable (i.e. encoded in a 732 globally standard format with no intrinsic ambiguity) does not seem 733 likely to change. However, at some point, it is possible that this 734 format will no longer be case-independent ASCII. 736 15. Conclusions 738 This document, in progress, suggests general architectural and policy 739 questions to be addressed when working on new protocols and standards 740 in the IETF. 742 We would welcome feedback on this document. Feedback could be send 743 to the editor, Sally Floyd, at floyd@icir.org. 745 16. Acknowledgements 747 This document has borrowed text freely from other IETF RFCs, and has 748 drawn on ideas from [ASSW02], [CWSB02], [M01] and elsewhere. This 749 document has developed from discussions in the IAB, and has drawn 750 from suggestions made at IAB Plenary sessions and on the ietf general 751 discussion mailing list. The case study on SIP was contributed by 752 James Kempf, and the case study on Stresses on DNS was contributed by 753 Karen Sollins. The discussions on Internationization and on 754 Overloading were based on an earlier document by Brian Carpenter and 755 Rob Austein. We have also benefited from discussions with Noel 756 Chiappa, Karen Sollins, John Wroclawski, and others, and from helpful 757 feedback from members of the IESG. 759 17. Normative References 761 18. Informative References 763 [A02] Harald Alvestrand, "Re: How many standards or protocols...", 764 email to the ietf discussion mailing list, Message-id: 765 <598204031.1018942481@localhost>, April 16, 2002. 767 [ASSW02] T. Anderson, S. Shenker, I. Stoica, and D. Wetherall, 768 "Towards More Robust Internet Protocols", February 2002. [No public 769 URL yet.] 771 [BFM02] Randy Bush, Tim Griffin, and David Meyer, "Some Internet 772 Architectural Guidelines and Philosophy", internet draft, work in 773 progress, July 2002. 775 [BMMWRO02] S. Bradner, A. Mankin, R. Mahy, D. Willis, B. Rosen, J. 776 Ott, "Change Process for the Session Initiation Protocol (SIP)", 777 draft-tsvarea-sipchange-02.txt, internet draft, work in progress, May 778 2002. 780 [CDT01] Policy Concerns Raised by Proposed OPES Working Group 781 Efforts, email to the IESG, from the Center for Democracy & 782 Technology, August 3, 2001. URL "http://www.imc.org/ietf- 783 openproxy/mail-archive/msg00828.html". 785 [Clark88] David D. Clark, The Design Philosophy of the DARPA Internet 786 Protocols, SIGCOMM 1988. 788 [CWSB02] Clark, D., Wroslawski, J., Sollins, K., and Braden, R., 789 "Tussle in Cyberspace: Defining Tomorrow's Internet", SIGCOMM 2002. 790 URL "http://www.acm.org/sigcomm/sigcomm2002/adprog.html". 792 [Evolvability] Floyd, S., "Papers on the Evolvability of the Internet 793 Infrastructure". Web Page, URL 794 "http://www.icir.org/floyd/evolution.html". 796 [K02] John C. Klensin, "Role of the Domain Name System", draft- 797 klensin-dns-role-03.txt, internet-draft, work in progress, June 2002. 799 [Layering] Floyd, S., "References on Layering and the Internet 800 Architecture", Web Page, URL "http://www.icir.org/floyd/layers.html". 802 [Multiplexing] S. Floyd, "Multiplexing, TCP, and UDP: Pointers to the 803 Discussion", Web Page, URL "http://www.icir.org/floyd/tcp_mux.html". 805 [M01] Tim Moors, A Critical Review of End-to-end Arguments in System 806 Design, 2001. URL "http://uluru.poly.edu/~tmoors/". 808 [RFC1958] B. Carpenter, "Architectural Principles of the Internet", 809 RFC 1958, June 1996. 811 [RFC2211] Wroclawski, J., "Specification of the Controlled Load 812 Quality of Service", RFC 2211, September 1997. 814 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 815 of Guaranteed Quality of Service", RFC 2212, September 1997. 817 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 818 and W. Weiss, "An Architecture for Differentiated Services", RFC 819 2475, December 1998. 821 [RFC2481] K. K. Ramakrishnan and S. Floyd, A Proposal to add Explicit 822 Congestion Notification (ECN) to IP, RFC 2481, January 1999. 824 [RFC2543] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, 825 "SIP: Session Initiation Protocol", RFC 25434, March 1999. 827 [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, 828 "Assured Forwarding PHB Group", RFC 2597. June 1999. 830 [RFC2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited 831 Forwarding PHB", RFC 2598, June 1999. 833 [RFC2316] Bellovin, S., "Report of the IAB Security Architecture 834 Workshop", RFC 2316, April 1998. 836 [RFC3124] H. Balakrishnan and S. Seshan, "The Congestion Manager", 837 RFC 3124, June 2001. 839 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. 840 Shelby, "Performance Enhancing Proxies Intended to Mitigate Link- 841 Related Degradations", RFC 3135, June 2001. 843 [RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of 844 Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed 845 Standard, September 2001. 847 [RFC3205] K. Moore, "On the use of HTTP as a Substrate", RFC 3205, 848 February 2002. 850 [RFC3234] B. Carpenter and S. Brim, "Middleboxes: Taxonomy and 851 Issues", RFC 3234, February 2002. 853 [RFC3238] S. Floyd and L. Daigle, "IAB Architectural and Policy 854 Considerations for Open Pluggable Edge Services", RFC 3238, 855 Informational, January 2002. 857 [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", 858 RFC 3360, August 2002. 860 [SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, Tom Anderson, 861 "TCP Congestion Control with a Misbehaving Receiver", ACM Computer 862 Communications Review, October 1999. 864 [SRC84] J. Saltzer, D. Reed, and D. D. Clark, "End-To-End Arguments 865 In System Design", ACM Transactions on Computer Systems, V.2, N.4, p. 866 277-88. 1984. 868 [T89] D. Tennenhouse, "Layered Multiplexing Considered Harmful", 869 Protocols for High-Speed Networks, 1989. 871 [UNSAF] L. Daigle, "IAB Considerations for UNilateral Self-Address 872 Fixing (UNSAF)", draft-iab-unsaf-considerations-02.txt, internet- 873 draft, work in progress, June 2002. 875 [WD02] Walter Willinger and John Doyle, "Robustness and the Internet: 876 Design and Evolution", draft, March 2002, URL 877 "http://netlab.caltech.edu/internet/". 879 19. Security Considerations 881 This document does not propose any new protocols, and therefore does 882 not involve any security considerations in that sense. However, 883 throughout this document there are discussions of the privacy and 884 integrity issues and the architectural requirements created by those 885 issues. 887 20. IANA Considerations 889 There are no IANA considerations regarding this document. 891 AUTHORS' ADDRESSES 893 Internet Architecture Board 894 EMail: iab@iab.org 896 IAB Membership at time this document was completed: 898 Harald Alvestrand 899 Ran Atkinson 900 Rob Austein 901 Fred Baker 902 Leslie Daigle 903 Steve Deering 904 Sally Floyd 905 Ted Hardie 906 Geoff Huston 907 Charlie Kaufman 908 James Kempf 909 Eric Rescorla 910 Mike St. Johns 912 This draft was created in August 2002.