draft-iab-considerations-00.txt   draft-iab-considerations-01.txt 
skipping to change at page 1, line 40 skipping to change at page 1, line 40
This document suggests general architectural and policy questions to This document suggests general architectural and policy questions to
be addressed in our work in the IETF. We note that this document be addressed in our work in the IETF. We note that this document
contains questions to be addressed, as opposed to guidelines or contains questions to be addressed, as opposed to guidelines or
architectural principles to be followed. architectural principles to be followed.
1. Introduction 1. Introduction
This document suggests general architectural and policy questions to This document suggests general architectural and policy questions to
be addressed in our work in the IETF. This document contains be addressed in our work in the IETF. This document contains
questions to be addressed, as opposed to guidelines or architectural questions to be addressed, as opposed to guidelines or architectural
principles to be followed. This is somewhat similar to the "Security principles to be followed. These questions are somewhat similar to
Considerations" currently required in IETF documents [RFC2316]. the "Security Considerations" currently required in IETF documents
[RFC2316].
This document is motivated in part by concerns of a growing lack of This document is motivated in part by concerns of a growing lack of
coherence in the overall Internet architecture. We have moved from a coherence in the overall Internet architecture. We have moved from a
world of a single, coherent architecture designed by a small group of world of a single, coherent architecture designed by a small group of
people, to a world of a complex, intricate architecture to address a people, to a world of a complex, intricate architecture to address a
wide-spread and heterogeneous environment. Because individual pieces wide-spread and heterogeneous environment. Because individual pieces
of the architecture are often designed by sub-communities, with each of the architecture are often designed by sub-communities, with each
sub-community having its own set of interests, it is necessary to pay sub-community having its own set of interests, it is necessary to pay
increasing attention to how each piece fits into the larger picture, increasing attention to how each piece fits into the larger picture,
and to consider how each piece is chosen. For example, it is and to consider how each piece is chosen. For example, it is
skipping to change at page 4, line 29 skipping to change at page 4, line 29
potential benefits offered by each option? potential benefits offered by each option?
The Whole Picture vs. Building Blocks: The Whole Picture vs. Building Blocks:
* Have you considered the larger context, while appropriately * Have you considered the larger context, while appropriately
restricting your own design efforts to one part of the whole? restricting your own design efforts to one part of the whole?
* Are there parts of the overall solution that will have to be * Are there parts of the overall solution that will have to be
provided by other IETF Working Groups or by other standards bodies? provided by other IETF Working Groups or by other standards bodies?
Designing for Choice: Designing for Choice vs. Avoiding Unnecessary Complexity:
* Is the protocol designed for choice, to allow different players to * Is the protocol designed for choice, to allow different players to
express their preferences? express their preferences where appropriate? At the same time, does
the protocol avoid the "kitchen sink" approach of providing too many
options and too much choice?
Preserving Evolvability? Preserving Evolvability?
* Does the protocol protect the interests of the future, by * Does the protocol protect the interests of the future, by
preserving the evolvability of the Internet? Does the protocol preserving the evolvability of the Internet? Does the protocol
enable future developments? enable future developments?
Each of these questions is discussed in more depth in the rest of Each of these questions is discussed in more depth in the rest of
this paper. this paper.
skipping to change at page 8, line 38 skipping to change at page 8, line 42
verify that network elements are not erasing the CE codepoint, and verify that network elements are not erasing the CE codepoint, and
that data receivers are properly reporting to the sender the receipt that data receivers are properly reporting to the sender the receipt
of packets with the CE codepoint set, as required by the transport of packets with the CE codepoint set, as required by the transport
protocol." Supporting mechanisms for the ECN nonce are needed in the protocol." Supporting mechanisms for the ECN nonce are needed in the
transport protocol to ensure robustness of delivery of the ECN-based transport protocol to ensure robustness of delivery of the ECN-based
congestion indication. congestion indication.
In contrast, a more difficult and less clear-cut robustness issue for In contrast, a more difficult and less clear-cut robustness issue for
ECN concerns the differential treatment of packets in the network by ECN concerns the differential treatment of packets in the network by
middleboxes, based on the TCP header's ECN flags in a TCP SYN packet middleboxes, based on the TCP header's ECN flags in a TCP SYN packet
[F02]. The issue concerns "ECN-setup" SYN packets, that is, SYN [RFC3360]. The issue concerns "ECN-setup" SYN packets, that is, SYN
packets with ECN flags set in the TCP header to negotiate the use of packets with ECN flags set in the TCP header to negotiate the use of
ECN between the two TCP end-hosts. There exist firewalls in the ECN between the two TCP end-hosts. There exist firewalls in the
network that drop "ECN-setup" SYN packets, others that send TCP Reset network that drop "ECN-setup" SYN packets, others that send TCP Reset
messages, and yet others that zero ECN flags in TCP headers. None of messages, and yet others that zero ECN flags in TCP headers. None of
this was anticipated by the designers of ECN, and RFC 3168 added this was anticipated by the designers of ECN, and RFC 3168 added
optional mechanisms to permit the robust operation of TCP in the optional mechanisms to permit the robust operation of TCP in the
presence of firewalls that drop "ECN-setup" SYN packets. However, presence of firewalls that drop "ECN-setup" SYN packets. However,
ECN is still not robust to all possible scenarios of middleboxes ECN is still not robust to all possible scenarios of middleboxes
zeroing ECN flags in the TCP header. Up until now, transport zeroing ECN flags in the TCP header. Up until now, transport
protocols have been standardized independently from the mechanisms protocols have been standardized independently from the mechanisms
used by middleboxes to control the use of these protocols, and it is used by middleboxes to control the use of these protocols, and it is
still not clear what degree of robustness is required from transport still not clear what degree of robustness is required from transport
protocols in the presence of the unauthorized modification of protocols in the presence of the unauthorized modification of
transport headers in the network. These and similar issues are transport headers in the network. These and similar issues are
discussed in more detail in [F02]. discussed in more detail in [RFC3360].
8. Avoiding Tragedy of the Commons. 8. Avoiding Tragedy of the Commons.
Question: Is performance still robust if everyone is using the new Question: Is performance still robust if everyone is using the new
protocol? Are there other potential impacts of widespread deployment protocol? Are there other potential impacts of widespread deployment
that need to be considered? that need to be considered?
8.1. Case Study: End-to-end Congestion Control. 8.1. Case Study: End-to-end Congestion Control.
[RFC2914] discusses the potential for congestion collapse if flows [RFC2914] discusses the potential for congestion collapse if flows
skipping to change at page 9, line 45 skipping to change at page 9, line 49
and preventing them from spilling out into unrelated areas? and preventing them from spilling out into unrelated areas?
9.1. Discussion: balancing competing interests 9.1. Discussion: balancing competing interests
[CWSB02] discusses the role that competition between competing [CWSB02] discusses the role that competition between competing
interests plays in the evolution of the Internet, and takes the interests plays in the evolution of the Internet, and takes the
position that the role of Internet protocols is to design the playing position that the role of Internet protocols is to design the playing
field in this competition, rather than to pick the outcome. The IETF field in this competition, rather than to pick the outcome. The IETF
has long taken the position that it can only design the protocols, has long taken the position that it can only design the protocols,
and that often two competing approaches will be developed, with the and that often two competing approaches will be developed, with the
marketplace left to decide between them [A02]. 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 adult supervision is
sometimes helpful.)
An example cited in [CWSB02] of modularization in support of these An example cited in [CWSB02] of modularization in support of
competing interests is the decision to use codepoints in the IP competing interests is the decision to use codepoints in the IP
header to select QoS, rather than binding QoS to other properties header to select QoS, rather than binding QoS to other properties
such as port numbers. This separates the structural and economic such as port numbers. This separates the structural and economic
issues related to QoS from technical issues of protocols and port issues related to QoS from technical issues of protocols and port
numbers, and allows space for a wide range of structural and pricing numbers, and allows space for a wide range of structural and pricing
solutions to emerge. solutions to emerge.
10. Designing for Choice It has also been suggested that companies in some cases have an
incentive to add complexity to protocol design in order to make the
protocol more difficult to implement, as a way of increasing the
barrier for competition. Clearly if this were to occur, such a
protocol would not be protecting the interests of competing parties.
10. Designing for Choice vs. Avoiding Unnecessary Complexity:
Is the protocol designed for choice, to allow different players to Is the protocol designed for choice, to allow different players to
express their preferences? express their preferences where appropriate? At the same time, does
the protocol avoid the "kitchen sink" approach of providing too many
options and too much choice?
10.1. Discussion: the importance of choice 10.1. Discussion: the importance of choice
[CWSB02] suggests that "the fundamental design goal of the Internet [CWSB02] suggests that "the fundamental design goal of the Internet
is to hook computers together, and since computers are used for is to hook computers together, and since computers are used for
unpredictable and evolving purposes, making sure that the users are unpredictable and evolving purposes, making sure that the users are
not constrained in what they can do is doing nothing more than not constrained in what they can do is doing nothing more than
preserving the core design tenet of the Internet. In this context, preserving the core design tenet of the Internet. In this context,
user empowerment is a basic building block, and should be embedded user empowerment is a basic building block, and should be embedded
into all mechanism whenever possible." into all mechanism whenever possible."
skipping to change at page 10, line 33 skipping to change at page 10, line 48
user to select his SMTP server and his POP server" [CWSB02]. More user to select his SMTP server and his POP server" [CWSB02]. More
open-ended questions about choice concern the design of mechanisms open-ended questions about choice concern the design of mechanisms
that would enable the user to choose the path at the level of that would enable the user to choose the path at the level of
providers, or to allow users to choose third-party intermediaries providers, or to allow users to choose third-party intermediaries
such as web caches, or providers for Open Pluggable Edge Services such as web caches, or providers for Open Pluggable Edge Services
(OPES). [CWSB02] also notes that the issue of choice itself reflects (OPES). [CWSB02] also notes that the issue of choice itself reflects
competing interests. For example, ISPs would generally like to lock competing interests. For example, ISPs would generally like to lock
in customers, while customers would like to preserve their ability to in customers, while customers would like to preserve their ability to
change among providers. change among providers.
At the same time, we note that 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.
These dangers are discussed in [BMMWRO02], 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. [BMMWRO02] suggests that other highly
extensible protocols developed in the IETF might also benefit from
more coordination of extensions.
11. Weighing architectural benefits against architectural costs. 11. Weighing architectural benefits against architectural costs.
Questions: How do the architectural benefits of a proposed new Questions: How do the architectural benefits of a proposed new
protocol compare against the architectural costs, if any? Have the protocol compare against the architectural costs, if any? Have the
architectural costs been carefully considered? architectural costs been carefully considered?
When adding features, have the potential costs of feature-creep and When adding features, have the potential costs of feature-creep and
the N-way interactions among options been considered, as well as the the N-way interactions among options been considered, as well as the
potential benefits offered by each option? potential benefits offered by each option?
skipping to change at page 11, line 45 skipping to change at page 12, line 24
OPES solutions standardized in the IETF should be required to OPES solutions standardized in the IETF should be required to
address. address.
11.3. Case Study: Stresses on DNS. 11.3. Case Study: Stresses on DNS.
As an example, over and over again, we find people wanting to As an example, over and over again, we find people wanting to
overload the DNS with new services and functions. In each case, we overload the DNS with new services and functions. In each case, we
may ask whether or not it is feasible to add a particular feature, may ask whether or not it is feasible to add a particular feature,
and often the answer is yes. What we rarely ask is the impact of all and often the answer is yes. What we rarely ask is the impact of all
this added functionality on the provision of the original service. this added functionality on the provision of the original service.
[K02] considers many of the newer demands being placed upon the DNS, [K02] considers many of the newer demands being placed upon the DNS.
and [CA02] discusses the general dangers of functional overloading
and of unlimited protocol extensions.
12. Looking at the whole picture vs. making a building block. 12. Looking at the whole picture vs. making a building block.
For a complex protocol which interacts with protocols from other For a complex protocol which interacts with protocols from other
standards bodies as well as from other IETF working groups, it can be standards bodies as well as from other IETF working groups, it can be
necessary to keep in mind the overall picture while, at the same necessary to keep in mind the overall picture while, at the same
time, breaking out specific parts of the problem to be standardized time, breaking out specific parts of the problem to be standardized
in particular working groups. in particular working groups.
Question: Have you considered the larger context, while restricting Question: Have you considered the larger context, while restricting
skipping to change at page 14, line 28 skipping to change at page 14, line 47
17. Informative References 17. Informative References
[A02] Harald Alvestrand, "Re: How many standards or protocols...", [A02] Harald Alvestrand, "Re: How many standards or protocols...",
email to the ietf discussion mailing list, Message-id: email to the ietf discussion mailing list, Message-id:
<598204031.1018942481@localhost>, April 16, 2002. <598204031.1018942481@localhost>, April 16, 2002.
[ASSW02] T. Anderson, S. Shenker, I. Stoica, and D. Wetherall, [ASSW02] T. Anderson, S. Shenker, I. Stoica, and D. Wetherall,
"Towards More Robust Internet Protocols", February 2002. [No public "Towards More Robust Internet Protocols", February 2002. [No public
URL yet.] URL yet.]
[CA02] B. Carpenter and R. Austein, "Recent Changes in the [BMMWRO02] S. Bradner, A. Mankin, R. Mahy, D. Willis, B. Rosen, J.
Architectural Principles of the Internet", draft-iab-arch- Ott, "Change Process for the Session Initiation Protocol (SIP)",
changes-00.txt, work in progress, February 2002. draft-tsvarea-sipchange-02.txt, internet draft, work in progress, May
2002.
[CDT01] Policy Concerns Raised by Proposed OPES Working Group [CDT01] Policy Concerns Raised by Proposed OPES Working Group
Efforts, email to the IESG, from the Center for Democracy & Efforts, email to the IESG, from the Center for Democracy &
Technology, August 3, 2001. URL "http://www.imc.org/ietf- Technology, August 3, 2001. URL "http://www.imc.org/ietf-
openproxy/mail-archive/msg00828.html". openproxy/mail-archive/msg00828.html".
[Clark88] David D. Clark, The Design Philosophy of the DARPA Internet [Clark88] David D. Clark, The Design Philosophy of the DARPA Internet
Protocols, SIGCOMM 1988. Protocols, SIGCOMM 1988.
[CWSB02] Clark, D., Wroslawski, J., Sollins, K., and Braden, R., [CWSB02] Clark, D., Wroslawski, J., Sollins, K., and Braden, R.,
"Tussle in Cyberspace: Defining Tomorrow's Internet", draft, March "Tussle in Cyberspace: Defining Tomorrow's Internet", SIGCOMM 2002.
2002. To appear in SIGCOMM 2002. [No public URL yet.] URL "http://www.acm.org/sigcomm/sigcomm2002/adprog.html".
[F02] Floyd, S., "Inappropriate TCP Resets Considered Harmful",
draft-floyd-tcp-reset-03.txt, work in progress, April 2002.
[Evolvability] Floyd, S., "Papers on the Evolvability of the Internet [Evolvability] Floyd, S., "Papers on the Evolvability of the Internet
Infrastructure". Web Page, URL Infrastructure". Web Page, URL
"http://www.icir.org/floyd/evolution.html". "http://www.icir.org/floyd/evolution.html".
[K02] John C. Klensin, "Role of the Domain Name System", draft- [K02] John C. Klensin, "Role of the Domain Name System", draft-
klensin-dns-role-02.txt, internet-draft, work in progress, February klensin-dns-role-03.txt, internet-draft, work in progress, June 2002.
2002.
[Layering] Floyd, S., "References on Layering and the Internet [Layering] Floyd, S., "References on Layering and the Internet
Architecture", Web Page, URL "http://www.icir.org/floyd/layers.html". Architecture", Web Page, URL "http://www.icir.org/floyd/layers.html".
[Multiplexing] S. Floyd, "Multiplexing, TCP, and UDP: Pointers to the [Multiplexing] S. Floyd, "Multiplexing, TCP, and UDP: Pointers to the
Discussion", Web Page, URL "http://www.icir.org/floyd/tcp_mux.html". Discussion", Web Page, URL "http://www.icir.org/floyd/tcp_mux.html".
[M01] Tim Moors, A Critical Review of End-to-end Arguments in System [M01] Tim Moors, A Critical Review of End-to-end Arguments in System
Design, 2001. URL "http://uluru.poly.edu/~tmoors/". Design, 2001. URL "http://uluru.poly.edu/~tmoors/".
skipping to change at page 16, line 16 skipping to change at page 16, line 32
[RFC3205] K. Moore, "On the use of HTTP as a Substrate", RFC 3205, [RFC3205] K. Moore, "On the use of HTTP as a Substrate", RFC 3205,
February 2002. February 2002.
[RFC3234] B. Carpenter and S. Brim, "Middleboxes: Taxonomy and [RFC3234] B. Carpenter and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002. Issues", RFC 3234, February 2002.
[RFC3238] S. Floyd and L. Daigle, "IAB Architectural and Policy [RFC3238] S. Floyd and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238, Considerations for Open Pluggable Edge Services", RFC 3238,
Informational, January 2002. Informational, January 2002.
[SCWA99] TCP Congestion Control with a Misbehaving Receiver, ACM [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful",
Computer Communications Review, October 1999. RFC 3360, August 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 [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. In System Design", ACM Transactions on Computer Systems, V.2, N.4, p.
277-88. 1984. 277-88. 1984.
[T89] D. Tennenhouse, "Layered Multiplexing Considered Harmful", [T89] D. Tennenhouse, "Layered Multiplexing Considered Harmful",
Protocols for High-Speed Networks, 1989. Protocols for High-Speed Networks, 1989.
[UNSAF] L. Daigle, "IAB Considerations for UNilateral Self-Address [UNSAF] L. Daigle, "IAB Considerations for UNilateral Self-Address
Fixing (UNSAF)", draft-iab-unsaf-considerations-01.txt, internet- Fixing (UNSAF)", draft-iab-unsaf-considerations-02.txt, internet-
draft, work in progress, February 2002. draft, work in progress, June 2002.
18. Security Considerations 18. Security Considerations
This document does not propose any new protocols, and therefore does This document does not propose any new protocols, and therefore does
not involve any security considerations in that sense. However, not involve any security considerations in that sense. However,
throughout this document there are discussions of the privacy and throughout this document there are discussions of the privacy and
integrity issues and the architectural requirements created by those integrity issues and the architectural requirements created by those
issues. issues.
19. IANA Considerations 19. IANA Considerations
skipping to change at page 17, line 16 skipping to change at page 17, line 38
Leslie Daigle Leslie Daigle
Steve Deering Steve Deering
Sally Floyd Sally Floyd
Ted Hardie Ted Hardie
Geoff Huston Geoff Huston
Charlie Kaufman Charlie Kaufman
James Kempf James Kempf
Eric Rescorla Eric Rescorla
Mike St. Johns Mike St. Johns
This draft was created in May 2002. This draft was created in August 2002.
 End of changes. 17 change blocks. 
27 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/