RFC 3426

General Architectural and Policy Considerations

📅 published November 2002, from ietf

General Architectural and Policy Considerations 🎀

Title block: this one is by S. Floyd, Editor for the Internet Architecture Board (the Network Working Group). It's Request for Comments 3426, filed in the Informational category and dated November 2002. The title block doesn't list anything it obsoletes or updates.

Status of this Memo 📌

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract ✨

Okay so this doc suggests the general architectural and policy questions the IETF community has to address when working on new standards and protocols 🧚 Important bit: it's full of questions to be addressed, not guidelines or architectural principles you're supposed to follow. Think of it as homework prompts, not rules. 📝

1. Introduction 🦋

Bestie, this doc suggests general architectural and policy questions that we need to work through in the IETF. It's packed with questions to be addressed, not guidelines or architectural principles to be followed. These questions are kinda similar to the "Security Considerations" that IETF documents currently have to include [RFC2316]. 🔐

It's also motivated partly by a growing lack of coherence in the overall Internet architecture 😭 We went from one coherent architecture designed by a small group of people to a world of complex, intricate architecture built for a wide-spread and heterogeneous environment. Since sub-communities design individual pieces, each with their own interests, we have to pay more and more attention to how each piece fits into the bigger picture and how each piece gets picked. Like, it's unavoidable that each of us is inclined to solve a problem at the layer of the protocol stack and with the tools we understand best 🙈 But that doesn't automatically mean it's the most appropriate layer or set of tools for solving that problem in the long term. Not me being a buzzkill, just real. 💅

Our assumption is that this document gets used as suggestions (but not a checklist!) of issues IETF members should address when chartering new working groups, when working in working groups, and when evaluating the output from other working groups 🫶 It's not a primer on how to design protocols and architectures, and it doesn't provide answers to anything. Just questions, babes. 🌸

2. Relationship to "Architectural Principles of the Internet" 🌈

Okay so RFC 1958 [RFC1958] outlines some architectural principles of the Internet, described as "guidelines that have been found useful in the past, and that may be useful to those designing new protocols or evaluating such designs." An example guideline is that "it is also generally felt that end-to-end functions can best be realized by end-to-end protocols." Similarly, an example design issue from [RFC1958] is that "heterogeneity is inevitable and must be supported by design." 🍓

This doc is a little different, though, since it suggests additional architectural questions to be addressed. One question it suggests is this one: "Is this proposal the best long-term solution to the problem? If not, what are the long-term costs of this solution, in terms of restrictions on future development, if any?" This question could be turned into a roughly equivalent architectural guideline, like: "Identify whether the proposed protocol is a long-term solution or a short-term solution, and identify the long-term costs and the exit strategy for any short-term solutions." ✨

Other questions are more open-ended, though, like the one about robustness: "How robust is the protocol, not just to the failure of nodes, but also to compromised or malfunctioning components, imperfect or defective implementations, etc?" As a community we're still learning how much robustness we can actually build into our protocols, plus which tools are around to make sure that robustness happens. So there aren't yet clear architectural guidelines along the lines of "Ensure that your protocol is robust against X, Y, and Z." It's giving "still figuring it out" energy 🧚 💀

3. Questions 💖

In this section we list some questions to ask when designing protocols. Each question gets discussed in more depth in the rest of this paper. We aren't suggesting that all protocol design efforts should be required to explicitly answer all of these questions, since some questions will be more relevant to one document than another. We also aren't suggesting that this is a complete list of architectural concerns. 🎀

DESIGN QUESTIONS:

Justifying the Solution:

  • Why are you proposing this solution, instead of proposing something else, or instead of using existing protocols and procedures?

Interactions between Layers:

  • Why are you proposing a solution at this layer of the protocol stack, rather than at another layer? Are there solutions at other layers of the protocol stack as well?
  • Is this an appropriate layer in terms of correctness of function, data integrity, performance, ease of deployment, the diagnosability of failures, and other concerns?
  • What are the interactions between layers, if any?

Long-term vs. Short-term Solutions:

  • Is this proposal the best long-term solution to the problem?
  • If not, what are the long-term costs of this solution, in terms of restrictions on future development, if any? What are the requirements for the development of longer-term solutions?

The Whole Picture vs. Building Blocks:

  • Have you considered the larger context, while appropriately restricting your own design efforts to one part of the whole?
  • Are there parts of the overall solution that will have to be provided by other IETF Working Groups or by other standards bodies?

EVALUATION QUESTIONS:

Weighing Benefits against Costs:

  • How do the architectural benefits of a proposed new protocol compare against the architectural costs, if any? Have the architectural costs been carefully considered?

Robustness:

  • How robust is the protocol, not just to the failure of nodes, but also to compromised or malfunctioning components, imperfect or defective implementations, etc?
  • Does the protocol take into account the realistic conditions of the current or future Internet (e.g., packet drops and packet corruption; packet reordering; asymmetric routing; etc.)?

Tragedy of the Commons:

  • Is performance still robust if everyone is using this protocol? Are there other potential impacts of widespread deployment that need to be considered?

Protecting Competing Interests:

  • Does the protocol protect the interests of competing parties (e.g., not only end-users, but also ISPs, router vendors, software vendors, or other parties)?

Designing for Choice vs. Avoiding Unnecessary Complexity:

  • Is the protocol designed for choice, to allow different players to express their preferences where appropriate? At the other extreme, does the protocol provide so many choices that it threatens interoperability or introduces other significant problems?

Preserving Evolvability?

  • Does the protocol protect the interests of the future, by preserving the evolvability of the Internet? Does the protocol enable future developments?
  • If an old protocol is overloaded with new functionality, or reused for new purposes, have the possible complexities introduced been taken carefully into account?
  • For a protocol that introduces new complexity to the Internet architecture, how does the protocol add robustness and preserve evolvability, and how does it also introduce new fragilities to the system?

Internationalization:

  • Where protocols require elements in text format, have the possibly conflicting requirements of global comprehensibility and the ability to represent local text content been properly weighed against each other?

DEPLOYMENT QUESTIONS:

  • Is the protocol deployable?

Each of these questions is discussed in more depth in the rest of this paper. 🦋

4. Justifying the Solution 💜

Question: Why are you proposing this solution, instead of proposing something else, or instead of using existing protocols and procedures?

4.1. Case study: Integrated and Differentiated Services ✨

Okay this one is a total case study moment 😭 A good part of the work on developing integrated and differentiated services was understanding the problem to be solved, agreeing on the architectural framework of the solution, and agreeing on the nature of specific services. So when integrated services were being developed, the specification of the Controlled Load [RFC2211] and Guaranteed [RFC2212] services each needed a justification for that particular service: low loss and bounded delay, respectively. 🌸

Later, RFC 2475 on "An Architecture for Differentiated Services" proposed a scalable service differentiation architecture that differs from the previously-defined architecture for integrated services. That document also had to clearly justify the requirements for this new architecture and compare the proposed architecture to other possible approaches [RFC2475]. Similarly, when the Assured Forwarding [RFC2597] and Expedited Forwarding [RFC3246] Per-Hop Behaviors of differentiated services were proposed, each service needed a justification for why it was needed in the Internet. Every single one had to show receipts 💅

5. Interactions between Layers 🌐

Questions: Why are you proposing a solution at this layer of the protocol stack, rather than at another layer? Are there solutions at other layers of the protocol stack as well?

Is this an appropriate layer in terms of correctness of function, data integrity, performance, ease of deployment, the diagnosability of failures, and other concerns?

What are the interactions between layers, if any?

5.1. Discussion: The End-to-End Argument 🧚

Now the classic one! The 1984 paper "End-To-End Arguments In System Design" [SRC84] kicks off a discussion of where to place functions among modules, suggesting that "functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level. Examples discussed in the paper include bit error recovery, security using encryption, duplicate message suppression, recovery from system crashes, and delivery acknowledgement. Low level mechanisms to support these functions are justified only as performance enhancements." 🔥 The end-to-end principle is one of the key architectural guidelines to consider when choosing the appropriate layer for a function. Iconic, honestly. 👑

5.2. Case study: Endpoint Congestion Management ✨

okay so the goal of the Congestion Manager in Endpoint Congestion Management is to let multiple concurrent flows with the same source and destination address share congestion control state [RFC3124]. 💖 the idea is giving the whole crew one shared brain for congestion instead of every flow doing its own thing.

there's a whole history of proposals for multiplexing flows at different layers of the protocol stack 🧚. some wanted multiplexing at the HTTP layer (WebMux), some at the TCP layer (TCP Control Blocks), and some below TCP (the Congestion Manager) [Multiplexing]. it's giving layer-hopping, fr fr.

BUT the 1989 article "Layered Multiplexing Considered Harmful" said that "the extensive duplication of multiplexing functionality across the middle and upper layers is harmful and should be avoided" [T89] 💀. so one of the big questions is figuring out which layer or layers are the best place to put this functionality. ngl the natural tendency for each researcher is to add stuff at the layer they know best 🙈, and that doesn't always give you the most appropriate overall architecture. not me building the whole thing in my favorite layer and calling it a day 😭.

5.3. Case study: Layering Applications on Top of HTTP 🎀

there's been a LOT of interest in layering applications on top of HTTP [RFC3205] 👑. the reasons people give are compatibility with widely-deployed browsers, being able to reuse client and server libraries, being able to use existing security mechanisms, and being able to get through firewalls. it's giving convenience, highkey.

as RFC 3205 puts it, "the recent interest in layering new protocols over HTTP has raised a number of questions when such use is appropriate, and the proper way to use HTTP in contexts where it is appropriate." so RFC 3205 doesn't just talk about the perks of layering apps on HTTP 🦋. it also looks at the extra complexity and overhead of doing that, compared to the cost of making a special-purpose protocol. honestly the balance is the whole point 💅.

the web page "References on Layering and the Internet Architecture" has links to more papers on general layering issues in the Internet architecture [Layering] 📚🌸.

6. Long-term vs. Short-term Solutions ⭐

Question: Is this proposal the best long-term solution to the problem? 🤔

If not, what are the long-term costs of this solution, in terms of restrictions on future development, if any? What are the requirements for the development of longer-term solutions? 🫶

6.1. Case study: Traversing NATs 🌈

so NAT middleboxes can change the external address of endpoints, and that's a whole problem 😩. to deal with it, people have proposed mechanisms where an originating process tries to figure out the address (and port) it's known by on the other side of a NAT. this would let the process use address data inside the protocol exchange, or advertise an external address it'll receive connections on.

the IAB in [RFC3424] explained why these proposals can be considered, at best, short-term fixes to specific problems 🍓. the specific issues to be carefully evaluated before standardizing them include identifying the limited-scope problem being fixed, describing an exit strategy for the short-term solution, and describing the longer-term problems the short-term solution leaves unsolved. basically a girl needs a plan for after the band-aid 🩹✨.

7. Looking at the whole picture vs. making a building block 🧩

for a complex protocol that interacts with protocols from other standards bodies as well as from other IETF working groups, it can be necessary to keep the overall picture in mind 👀. at the same time, you break out specific parts of the problem to standardize in particular working groups. it's a balancing act, bestie 💖.

Question: Have you considered the larger context, while restricting your own design efforts to one part of the whole? 🦋

Question: Are there parts of the overall solution that will have to be provided by other IETF Working Groups or by other standards bodies? 🤍

7.1. Case Study: The Session Initiation Protocol (SIP) 📞

the Session Initiation Protocol (SIP) [RFC2543] is for managing connected, multimedia sessions 🎶. it's an example of a complex protocol that has been broken into pieces and standardized in different working groups. SIP has also involved interaction with other standardization bodies, so it's a whole group project 👯‍♀️.

the basic SIP framework is being standardized by the SIP working group 💜. this group focuses on the core features: setting up, managing, and tearing down multimedia sessions. extensions are considered if they relate to those core features 🔥.

setting up a multimedia session also needs a description of the session you want. that's provided by the Session Description Protocol (SDP) 📝. SDP is a building block supplied by the Multiparty Multimedia Session Control (MMUSIC) working group, and it's NOT standardized within the SIP working group 🙅‍♀️. (ok fine, it's "not standardized" in caps-free form, but you get it 😌.)

other working groups handle extensions to SIP that fall outside the core features or applications 🌷. the SIPPING working group is analyzing requirements for SIP applied to different tasks, and the SIMPLE working group is looking at applying SIP to instant messaging and presence 💬. the IPTEL working group is defining a call processing language (CPL) that interacts with SIP in various ways 🧚. these groups occasionally feed requirements back into the main SIP working group, which is so iconic of them ✨.

and outside standardization groups have been super active in giving the SIP working group requirements 📣. the Distributed Call Signaling (DCS) group from the PacketCable Consortium, 3GPP, and 3GPP2 are all using SIP for various telephony applications, and members of those groups helped draft SIP requirements. there are also extensions of SIP under consideration in those bodies. procedures are being developed in the IETF to address proposed SIP extensions, including a category of preliminary, private, or proprietary extensions, and to provide for the safe management of the SIP namespace [MBMWOR02] 🔐🎀.

8. Weighing architectural benefits against architectural costs ⚖️

Questions: How do the architectural benefits of a proposed new protocol compare against the architectural costs, if any? Have the architectural costs been carefully considered? 🤔💅

8.1. Case Study: Performance-enhancing proxies (PEPs) 🚀

RFC 3135 [RFC3135] looks at the relative costs and benefits of putting performance-enhancing proxies (PEPs) in the middle of a network to address link-related degradations 🛣️. for PEPs, the potential costs include disabling the end-to-end use of IP layer security mechanisms 😱, introducing a new possible point of failure that isn't under the control of the end systems 💀, making it harder to diagnose and deal with failures 🙃, and introducing possible complications with asymmetric routing or mobile hosts 📱. RFC 3135 carefully considers these costs, the mitigations that can be introduced, and the cases where the benefits to the user are likely to outweigh the costs 🫶🌈.

8.2. Case Study: Open Pluggable Edge Services (OPES) 🧃

one of the issues middleboxes raise on the Internet involves the end-to-end integrity of data 🔍. this came up in the recent question of chartering the Open Pluggable Edge Services (OPES) Working Group. Open Pluggable Edge Services are services deployed as application-level intermediaries in the network, for example at a web proxy cache between the origin server and the client 🌐. these intermediaries would transform or filter content, with the explicit consent of either the content provider or the end user 🫧.

one of the architectural issues that came up while chartering the OPES Working Group was end-to-end integrity of data 😬. as an example, it was suggested that "OPES would reduce both the integrity, and the perception of integrity, of communications over the Internet, and would significantly increase uncertainly about what might have been done to content as it moved through the network", and therefore the risks of OPES outweighed the benefits [CDT01] 😭🙈.

as one result of this debate, the IAB wrote "IAB Architectural and Policy Considerations for OPES", which looks at both the potential architectural benefits and costs of OPES [RFC3238] 📝. this document didn't recommend specific solutions or mandate specific functional requirements. instead, it included recommendations on issues, such as concerns about data integrity, that OPES solutions standardized in the IETF should be required to address 💜✨.

9. General Robustness Questions 🛡️

Questions: How robust is the protocol, not just to the failure of nodes, but also to compromised or malfunctioning components, imperfect or defective implementations, etc? 😤

Does the protocol take into account the realistic conditions of the current or future Internet (e.g., packet drops and packet corruption, packet reordering, asymmetric routing, etc.)? 🌪️

9.1. Discussion: Designing for Robustness 💪

robustness has long been cited as one of the overriding goals of the Internet architecture [Clark88] 👑. the robustness issues discussed in [Clark88] mostly referred to the robustness of packet delivery even when routers had failed. today, robustness concerns have widened to include a goal of robust performance in the presence of a wide range of failures, buggy code, and malicious actions 🦹‍♀️.

as [ASSW02] argues, protocols need to be designed somewhat defensively to maximize robustness against inconsistencies and errors 🧱. [ASSW02] discusses several approaches for increasing robustness in protocols, such as verifying information whenever possible, designing interfaces that are conceptually simple and therefore less conducive to error, protecting resources against attack or overuse, and identifying and exposing errors so they can be repaired 🔧🩷.

techniques for verifying information range from checking that TCP acknowledgements acknowledge data that was actually sent, to providing mechanisms for routers to verify information in routing messages 🔎.

techniques for protecting resources against attack range from preventing "SYN flood" attacks by designing protocols that don't allocate resources for a single SYN packet, to partitioning resources (e.g., preventing one flow or aggregate from using all of the link bandwidth) 🛡️🌸.

9.2. Case Study: Explicit Congestion Notification (ECN) ✨

Okay so the Internet runs on end-to-end congestion control 🌸, and for the longest time the only way a router could say "hey, it's jammed in here" was to just... drop the packet 💀. ECN [RFC3168] is the glow-up 💅: routers can set a bit in the IP packet header to tell the end-nodes about congestion instead of dropping the packet ✨.

The first, Experimental spec of ECN [RFC3168] had a whole long discussion about the danger of a rogue or broken router "erasing" info from the ECN field in the IP header, which would stop congestion signals from ever reaching the end-nodes 😭. To make it more robust, the standards-track spec [RFC3168] added an extra codepoint in the IP header's ECN field, for an ECN "nonce" 🔐. The nonce idea came from earlier research on specific robustness problems in TCP [SCWA99]. RFC 3168 says the codepoint "is motivated primarily by the desire to allow mechanisms for the data sender to verify that network elements are not erasing the CE codepoint, and that data receivers are properly reporting to the sender the receipt of packets with the CE codepoint set, as required by the transport protocol." Supporting mechanisms for the ECN nonce are needed in the transport protocol to ensure robustness of delivery of the ECN-based congestion indication 🫶.

Now the messier one 🙈. Middleboxes have been treating packets differently based on the TCP header's ECN flags in a TCP SYN packet [RFC3360], and that's a much less clear-cut robustness issue. The problem is "ECN-setup" SYN packets, which are SYN packets with ECN flags set in the TCP header to negotiate ECN use between the two TCP end-hosts. Some firewalls in the network drop "ECN-setup" SYN packets, others send TCP Reset messages, and yet others zero the ECN flags in TCP headers 🫠. None of this was anticipated by the ECN designers, and RFC 3168 added optional mechanisms so TCP can still work properly with firewalls that drop "ECN-setup" SYN packets. However, ECN is still not robust to all possible scenarios of middleboxes zeroing ECN flags in the TCP header. Up until now, transport protocols have been standardized independently from the mechanisms middleboxes use to control their use, and it is still not clear what degree of robustness is required from transport protocols in the presence of the unauthorized modification of transport headers in the network 👀. These and similar issues are discussed in more detail in [RFC3360].

10. Avoiding Tragedy of the Commons 🍓

Question: Is performance still robust if everyone is using the new protocol? Are there other potential impacts of widespread deployment that need to be considered?

10.1. Case Study: End-to-end Congestion Control 🐑

[RFC2914] talks about the potential for congestion collapse if flows aren't using end-to-end congestion control during high congestion. Picture this: a new transport protocol is proposed that doesn't use end-to-end congestion control. It might be super easy to show that one flow using it performs really well, as long as all the competing flows in the network are using end-to-end congestion control 😤. To fully evaluate it, you have to look at performance when many flows are competing and they're all using the new transport protocol. If they all used the more aggressive protocol during high congestion, the result could be high steady-state packet drop rates and reduced overall throughput, with busy links carrying packets that will only get dropped downstream 📉. This is a form of tragedy of the commons: something that's productive when only one person does it (like adding a few more sheep to the common grazing pasture) becomes counter-productive when everyone does it [H68] 🐑💀.

11. Balancing Competing Interests ⚖️

Question: Does the protocol protect the interests of competing parties (e.g., not only end-users, but also ISPs, router vendors, software vendors, or other parties)?

11.1. Discussion: balancing competing interests

[CWSB02] discusses the role that competition between competing interests plays in the evolution of the Internet. It takes the position that the role of Internet protocols is to design the playing field in this competition, rather than to pick the outcome 🏟️. The IETF has long taken the position that it can only design the protocols, and that often two competing approaches will be developed, with the marketplace left to decide between them [A02]. (It has also been suggested that "the marketplace" left entirely to itself does not always make the best decisions, and that working to identify and adopt the technically best solution is sometimes helpful. Thus, while the role of the marketplace should not be ignored, the decisions of the marketplace should also not be held as sacred or infallible. 🤭)

An example cited in [CWSB02] of modularization in support of competing interests is the decision to use codepoints in the IP header to select QoS, rather than binding QoS to other properties such as port numbers. This separates the structural and economic issues related to QoS from technical issues of protocols and port numbers, and leaves room for a wide range of structural and pricing solutions to emerge 🧩.

There have been perceived problems over the years with individuals adding unnecessary complexity to IETF protocols, which increases the barrier to other implementations of those protocols 😒. Clearly, that kind of action would not be protecting the interests of open competition. Underspecified protocols can also serve as an unnecessary barrier to open competition 🚧.

12. Designing for Choice vs. Avoiding Unnecessary Complexity: 🎛️

Is the protocol designed for choice, to allow different players to express their preferences where appropriate? At the other extreme, does the protocol provide so many choices that it threatens interoperability or introduces other significant problems?

12.1. Discussion: the importance of choice

[CWSB02] suggests that "the fundamental design goal of the Internet is to hook computers together, and since computers are used for unpredictable and evolving purposes, making sure that the users are not constrained in what they can do is doing nothing more than preserving the core design tenet of the Internet. In this context, user empowerment is a basic building block, and should be embedded into all mechanism whenever possible." 🙌

As an example of choice, "the design of the mail system allows the user to select his SMTP server and his POP server" [CWSB02] 📬. More open-ended questions about choice concern the design of mechanisms that would let the user choose the path at the level of providers, or let users choose third-party intermediaries such as web caches, or providers for Open Pluggable Edge Services (OPES) 🗺️. [CWSB02] also notes that the issue of choice itself reflects competing interests. For example, ISPs would generally like to lock in customers, while customers would like to keep their ability to change among providers 🔒.

At the same time, excessive choice can lead to "kitchen sink" protocols that are inefficient and hard to understand, have too much negotiation, or have unanticipated interactions between options 🚰. For example, [P99] notes that excessive choice can lead to difficulty in ensuring interoperability between two independent, conformant implementations of the protocol 🙃.

The dangers of excessive options are also discussed in [MBMWOR02], which gives guidelines for responding to the "continuous flood" of suggestions for modifications and extensions to SIP (Session Initiation Protocol) 🌊. In particular, the SIP Working Group is concerned that proposed extensions have general use, and do not provide efficiency at the expense of simplicity or robustness 🧐. [MBMWOR02] suggests that other highly extensible protocols developed in the IETF might also benefit from more coordination of extensions 🤝.

13. Preserving evolvability? 🦋

Does the protocol protect the interests of the future, by preserving the evolvability of the Internet? Does the protocol enable future developments?

If an old protocol is overloaded with new functionality, or reused for new purposes, have the possible complexities introduced been taken into account?

For a protocol that introduces new complexity to the Internet architecture, does the protocol add robustness and preserve evolvability? Does it also introduce unwanted new fragilities to the system? 🥺

13.1. Discussion: evolvability

There is an extensive literature and an ongoing discussion about the evolvability, or lack of evolvability, of the Internet infrastructure. The web page on "Papers on the Evolvability of the Internet Infrastructure" has pointers to some of this literature [Evolvability] 📚. Issues range from the evolvability and overloading of the DNS, to the difficulties the Internet has in evolving to incorporate multicast, QoS, or IPv6, to the difficulties of routing in meeting the demands of a changing and expanding Internet, and the role of firewalls and other middleboxes in limiting evolvability 🚦.

[CWSB02] suggests that among all of the issues of evolvability, "keeping the net open and transparent for new applications is the most important goal." 🌈 In the beginning, the relative transparency of the infrastructure was sufficient to ensure evolvability, where a "transparent" network simply routes packets from one end-node to another. However, this transparency has become more murky over time, as cataloged in [RFC3234], which discusses the ways that middleboxes interact with existing protocols and increase the difficulties in diagnosing failures 🕵️‍♀️. [CWSB02] realistically suggests the following guideline: "Failures of transparency will occur - design what happens then," where examples of failures of transparency include firewalls, application filtering, connection redirection, caches, kludges to DNS, and the like 🛠️. Thus, maintaining evolvability also requires mechanisms for allowing evolution in the face of a lack of transparency of the infrastructure itself 💜.

One of the ways to maintain evolvability is for designers of new mechanisms and protocols to be as clear as possible about the assumptions they make about the rest of the network 📝. New mechanisms that make unwarranted assumptions about the network can end up placing unreasonable constraints on the future evolution of the network 🙅‍♀️.

13.2. Discussion: overloading 💅✨

Okay so, there's been a strong tendency lately to overload designs with new functionality, and bestie, the operational complexity that comes with it is wild 😭. Extensible protocols can be one of the tools for evolvability 🦋. BUT if protocols and systems get stretched way past their reasonable design parameters, scaling, reliability, or security issues can show up 💀. Examples of protocols that have been seen as productively extended, as dangerously overloaded, or both, include DNS [K02,RFC3403], MPLS [A02a], and BGP [B02] 🌈. In some cases, overloading or extending a protocol can reduce total complexity and deployment costs by avoiding the creation of a new protocol. In other cases, a new protocol might be the simpler solution 🎀.

We have a bunch of reusable technologies, including component technologies that were specifically designed for re-use 🧚. Examples include SASL, BEEP and APEX. TCP and UDP can also be viewed as reusable transport protocols, used by a range of applications 🫶. On the other hand, re-use should not go so far that a protocol turns into a Trojan Horse, which is exactly what happened with HTTP [RFC3205] 🙈.

13.3. Discussion: complexity, robustness, and fragility 🌸

[WD02] gives a historical account of the evolution of the Internet as a complex system, with particular attention to the tradeoffs between complexity, robustness, and fragility 📜. [WD02] describes the robustness that follows from the simplicity of a connectionless, layered, datagram infrastructure and a universal logical addressing scheme. As case studies, it describes the increasing complexity of TCP and of BGP 🔥. The paper describes a complexity/robustness spiral: an initially robust design, the appearance of fragilities, and then modifications for more robustness that themselves introduce new fragilities. It's giving cycle, honestly 🌀. [WD02] conjectures that "the Internet is only now beginning to experience an acceleration of this complexity/robustness spiral and, if left unattended, can be fully expected to experience arcane, irreconcilable, and far-reaching robustness problems in the not-too-distant future." Yikes 😳. Citing [WD02], [BFM02] focuses on the ways that complexity increases capital and operational expenditures in carrier IP networks, and it views complexity as the primary mechanism that impedes efficient scaling 💸.

14. Internationalization 🌍

Where protocols require elements in text format, have the possibly conflicting requirements of global comprehensibility and the ability to represent local text content been properly weighed against each other? 🤔

14.1. Discussion: internationalization 🗣️

RFC 1958 [RFC1958] included a simple statement of the need for a common language 💜:

"Public (i.e. widely visible) names should be in case-independent ASCII. Specifically, this refers to DNS names, and to protocol elements that are transmitted in text format."

The IETF has studied character set issues in general [RFC 2130] and made specific recommendations for the use of a standardized approach [RFC 2277] 📚. It's a little messy, because some uses of text are hidden entirely inside protocol elements and only need to be read by machines, while other uses are meant entirely for human eyes 👀. Lots of uses sit somewhere in between these two extremes, and that's what leads to conflicting implementation requirements 🙃.

For the specific case of DNS, the Internationalized Domain Name working group is considering these issues ✨. As stated in the charter of that working group, "A fundamental requirement in this work is to not disturb the current use and operation of the domain name system, and for the DNS to continue to allow any system anywhere to resolve any domain name." This leads to some very strong requirements for backwards compatibility with the existing ASCII-only DNS 🔒. Yet since the DNS has come to be used as if it were a directory service, domain names are also expected to be presented to users in local character sets 🧁.

This document does not try to resolve these complex and difficult issues. It simply names them as an issue to be addressed in our work 🫠. The requirement that names encoded in a text format within protocol elements be universally decodable (i.e. encoded in a globally standard format with no intrinsic ambiguity) doesn't seem likely to change 💅. However, at some point, it's possible that this format will no longer be case-independent ASCII 👑.

15. Deployability 🚀

Question: Is the protocol deployable? 🤍

15.1. Discussion: deployability 📦

It has been suggested that failing to understand deployability considerations in the current environment is one of the major weaknesses of the IETF 😬. As examples of deployment difficulties, RFC 2990 [RFC2990] discusses deployment difficulties with Quality of Service (QoS) architectures. Various documents of the MBONE Deployment Working Group address deployment problems with IP Multicast, and the IPv6 Working Group discusses a wealth of issues related to the deployment of IPv6 🌐. [CN02] discusses how the deployment of Integrated Services has been limited by factors such as the failure to take administrative boundaries into account 🚧. Additional papers on difficulties in the evolution of the Internet architecture are available from [Evolvability] 📖.

Issues that can complicate deployment include whether the protocol is compatible with pre-existing standards, and whether it's compatible with the installed base 🧱. For example, a transport protocol is more likely to be deployable if it performs correctly and reasonably robustly in the presence of dropped, reordered, duplicated, delayed, and rerouted packets, because all of that can happen on the current Internet 🌪️. Main character energy for packets, honestly 🎀.

16. Conclusions 🦋

This document suggests general architectural and policy questions to be addressed when working on new protocols and standards in the IETF 💖.

The case studies in this document have generally been short illustrations of how the questions proposed here have been addressed in working groups in the past ⭐. However, we have generally steered away from case studies of more controversial issues, where there isn't yet consensus in the IETF community 🙊. So we side-stepped suggestions for adding a case study for IKE (Internet Key Exchange) as a possible example of a protocol with too much negotiation. We also side-stepped adding a case study of network management protocols as an illustration of the possible costs of leaving things to the marketplace to decide 🫣. We would encourage others to contribute case studies of these or any other issues that may shed light on some of the questions in this document. Any such case studies could include a careful presentation of the architectural reasoning on both sides ⚖️.

We would conjecture that there is a lot to be learned, in terms of the range of answers to the questions posed in this document, by studying the successes, failures, and other struggles of the past 🍓. Honestly, history is the cheat code 🧠.

We would welcome feedback on this document for future revisions 💌. Feedback could be sent to the editor, Sally Floyd, at floyd@icir.org ✉️.

17. Acknowledgements 💜

This document has borrowed text freely from other IETF RFCs, and has drawn on ideas from [ASSW02], [CWSB02], [M01] and elsewhere 🫶. It developed from discussions in the IAB, and drew from suggestions made at IAB Plenary sessions and on the ietf general discussion mailing list 🎤. The case study on SIP was contributed by James Kempf. An early case study on Stresses on DNS was contributed by Karen Sollins, and Keith Moore contributed suggestions that were incorporated in a number of places in the document 🙌. The discussions on Internationalization and on Overloading were based on an earlier document by Brian Carpenter and Rob Austein 🌸. We have also benefited from discussions with Noel Chiappa, Karen Sollins, John Wroclawski, and others, and from helpful feedback from members of the IESG 🧚. We specifically thank Senthilkumar Ayyasamy, John Loughney, Keith Moore, Eric Rosen, and Dean Willis, and others, for feedback on various stages of this document 💖.

18. Normative References 📚

19. Informative References 📚✨

okay bestie, this is the reading list 🤓 these aren't required to implement anything, they're just the receipts behind the arguments in the doc. I've kept every label, title, author, and URL exactly as written, typos included 💅

  • [A02] Harald Alvestrand, "Re: How many standards or protocols...", email to the ietf discussion mailing list, Message-id: <598204031.1018942481@localhost>, April 16, 2002.
  • [A02a] Loa Andersson, "The Role of MPLS in Current IP Network", MPLS World News, September 16, 2002. URL "http://www.mplsworld.com/archi_drafts/focus/analy-andersson.htm".
  • [ASSW02] T. Anderson, S. Shenker, I. Stoica, and D. Wetherall, "Design Guidelines for Robust Internet Protocols", HotNets-I, October 2002.
  • [BFM02] Randy Bush, Tim Griffin, and David Meyer, "Some Internet Architectural Guidelines and Philosophy", Work in Progress.
  • [B02] Hamid Ould-Brahim, Bryan Gleeson, Peter Ashwood-Smith, Eric C. Rosen, Yakov Rekhter, Luyuan Fang, Jeremy De Clercq, Riad Hartani, and Tissa Senevirathne, "Using BGP as an Auto-Discovery Mechanism for Network-based VPNs", Work in Progress.
  • [CDT01] Policy Concerns Raised by Proposed OPES Working Group Efforts, email to the IESG, from the Center for Democracy & Technology, August 3, 2001. URL "http://www.imc.org/ietf-openproxy/mail-archive/msg00828.html".
  • [Clark88] David D. Clark, The Design Philosophy of the DARPA Internet Protocols, SIGCOMM 1988.
  • [CN02] Brian Carpenter, Kathleen Nichols, "Differentiated Services in the Internet", Technical Report, February 2002, URL "http://www.research.ibm.com/resources/paper_search.shtml".
  • [CWSB02] Clark, D., Wroslawski, J., Sollins, K., and Braden, R., "Tussle in Cyberspace: Defining Tomorrow's Internet", SIGCOMM 2002. URL "http://www.acm.org/sigcomm/sigcomm2002/papers/tussle.html".
  • [Evolvability] Floyd, S., "Papers on the Evolvability of the Internet Infrastructure". Web Page, URL "http://www.icir.org/floyd/evolution.html".
  • [H68] Garrett Hardin, "The Tragedy of the Commons", Science, V. 162, 1968, pp. 1243-1248. URL "http://dieoff.org/page95.htm".
  • [K02] John C. Klensin, "Role of the Domain Name System", Work in Progress.
  • [Layering] Floyd, S., "References on Layering and the Internet Architecture", Web Page, URL "http://www.icir.org/floyd/layers.html".
  • [Multiplexing] S. Floyd, "Multiplexing, TCP, and UDP: Pointers to the Discussion", Web Page, URL "http://www.icir.org/floyd/tcp_mux.html".
  • [MBMWOR02] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, November 2002.
  • [M01] Tim Moors, A Critical Review of End-to-end Arguments in System Design, 2001. URL "http://uluru.poly.edu/~tmoors/".
  • [P99] Radia Perlman, "Protocol Design Folklore", in Interconnections Second Edition: Bridges, Routers, Switches, and Internetworking Protocols, Addison-Wesley, 1999.
  • [RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
  • [RFC2211] Wroclawski, J., "Specification of the Controlled Load Quality of Service", RFC 2211, September 1997.
  • [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
  • [RFC2316] Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998.
  • [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
  • [RFC2543] Handley, M., Schulzrinne, H., Schooler, B. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 25434, March 1999.
  • [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
  • [RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.
  • [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
  • [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.
  • [RFC3168] Ramakrishnan, K. K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
  • [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002.
  • [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
  • [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
  • [RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
  • [RFC3246] Davie, B., Charny, A., Bennet, J. C. R., Benson, K., Le Boudec, J. Y., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
  • [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002.
  • [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
  • [RFC3424] Daigle, L., "IAB Considerations for UNilateral Self-Address Fixing (UNSAF)", RFC 3424, November 2002.
  • [SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, Tom Anderson, "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communications Review, October 1999.
  • [SRC84] J. Saltzer, D. Reed, and D. D. Clark, "End-To-End Arguments In System Design", ACM Transactions on Computer Systems, V.2, N.4, p. 277-88. 1984.
  • [T89] D. Tennenhouse, "Layered Multiplexing Considered Harmful", Protocols for High-Speed Networks, 1989.
  • [WD02] Walter Willinger and John Doyle, "Robustness and the Internet: Design and Evolution", draft, March 2002, URL "http://netlab.caltech.edu/internet/".

20. Security Considerations 🔐

this one's kinda plot-twisty 😭 this doc doesn't propose any new protocols, so in that specific sense there are no security considerations to report 🙈 BUT throughout the whole thing, there are real discussions of privacy and integrity issues, plus the architectural requirements those issues create. so don't skip the vibes just because there's no new wire format 💀

21. IANA Considerations 🧚

no IANA stuff here. zero registries, zero codepoints, nothing to assign 🌸 There are no IANA considerations regarding this document.

Authors' Addresses 💌

The author is the Internet Architecture Board 🏛️ EMail: iab@iab.org

IAB Membership at time this document was completed:

  • Harald Alvestrand
  • Ran Atkinson
  • Rob Austein
  • Fred Baker
  • Leslie Daigle
  • Steve Deering
  • Sally Floyd
  • Ted Hardie
  • Geoff Huston
  • Charlie Kaufman
  • James Kempf
  • Eric Rescorla
  • Mike St. Johns

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. 💜

📦 where this page comes from