doc: Add RFC documents

1 files changed, 3363 insertions, 0 deletions

diff --git a/doc/rfc/rfc3819.txt b/doc/rfc/rfc3819.txt
new file mode 100644
index 0000000..b4a5e8b
--- /dev/null
+++ b/doc/rfc/rfc3819.txt
@@ -0,0 +1,3363 @@
+
+
+
+
+
+
+Network Working Group                                       P. Karn, Ed.
+Request for Comments: 3819                                      Qualcomm
+BCP: 89                                                       C. Bormann
+Category: Best Current Practice                  Universitaet Bremen TZI
+                                                            G. Fairhurst
+                                                  University of Aberdeen
+                                                             D. Grossman
+                                                          Motorola, Inc.
+                                                               R. Ludwig
+                                                       Ericsson Research
+                                                              J. Mahdavi
+                                                                  Novell
+                                                           G. Montenegro
+                                   Sun Microsystems Laboratories, Europe
+                                                                J. Touch
+                                                                 USC/ISI
+                                                                 L. Wood
+                                                           Cisco Systems
+                                                               July 2004
+
+
+                Advice for Internet Subnetwork Designers
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document provides advice to the designers of digital
+   communication equipment, link-layer protocols, and packet-switched
+   local networks (collectively referred to as subnetworks), who wish to
+   support the Internet protocols but may be unfamiliar with the
+   Internet architecture and the implications of their design choices on
+   the performance and efficiency of the Internet.
+
+
+
+
+
+
+
+
+
+
+Karn, et al.             Best Current Practice                  [Page 1]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+Table of Contents
+
+   1.  Introduction and Overview. . . . . . . . . . . . . . . . . . .  2
+   2.  Maximum Transmission Units (MTUs) and IP Fragmentation . . . .  4
+       2.1.  Choosing the MTU in Slow Networks. . . . . . . . . . . .  6
+   3.  Framing on Connection-Oriented Subnetworks . . . . . . . . . .  7
+   4.  Connection-Oriented Subnetworks. . . . . . . . . . . . . . . .  9
+   5.  Broadcasting and Discovery . . . . . . . . . . . . . . . . . . 10
+   6.  Multicasting . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   7.  Bandwidth on Demand (BoD) Subnets. . . . . . . . . . . . . . . 13
+   8.  Reliability and Error Control. . . . . . . . . . . . . . . . . 14
+       8.1.  TCP vs Link-Layer Retransmission . . . . . . . . . . . . 14
+       8.2.  Recovery from Subnetwork Outages . . . . . . . . . . . . 17
+       8.3.  CRCs, Checksums and Error Detection. . . . . . . . . . . 18
+       8.4.  How TCP Works. . . . . . . . . . . . . . . . . . . . . . 20
+       8.5.  TCP Performance Characteristics. . . . . . . . . . . . . 22
+             8.5.1.  The Formulae . . . . . . . . . . . . . . . . . . 22
+             8.5.2.  Assumptions. . . . . . . . . . . . . . . . . . . 23
+             8.5.3.  Analysis of Link-Layer Effects on TCP
+                     Performance. . . . . . . . . . . . . . . . . . . 24
+   9.  Quality-of-Service (QoS) Considerations. . . . . . . . . . . . 26
+   10. Fairness vs Performance. . . . . . . . . . . . . . . . . . . . 29
+   11. Delay Characteristics. . . . . . . . . . . . . . . . . . . . . 30
+   12. Bandwidth Asymmetries. . . . . . . . . . . . . . . . . . . . . 31
+   13. Buffering, Flow and Congestion Control . . . . . . . . . . . . 31
+   14. Compression. . . . . . . . . . . . . . . . . . . . . . . . . . 34
+   15. Packet Reordering. . . . . . . . . . . . . . . . . . . . . . . 36
+   16. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
+   17. Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
+   18. Security Considerations. . . . . . . . . . . . . . . . . . . . 41
+   19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44
+   20. Informative References . . . . . . . . . . . . . . . . . . . . 45
+   21. Contributors' Addresses. . . . . . . . . . . . . . . . . . . . 57
+   22. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 58
+   23. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 60
+
+1.  Introduction and Overview
+
+   IP, the Internet Protocol [RFC791] [RFC2460], is the core protocol of
+   the Internet.  IP defines a simple "connectionless" packet-switched
+   network.  The success of the Internet is largely attributed to IP's
+   simplicity, the "end-to-end principle" [SRC81] on which the Internet
+   is based, and the resulting ease of carrying IP on a wide variety of
+   subnetworks, not necessarily designed with IP in mind.  A subnetwork
+   refers to any network operating immediately below the IP layer to
+   connect two or more systems using IP (i.e., end hosts or routers).
+   In its simplest form, this may be a direct connection between the IP
+   systems (e.g., using a length of cable or a wireless medium).
+
+
+
+Karn, et al.             Best Current Practice                  [Page 2]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   This document defines a subnetwork as a layer 2 network, which is a
+   network that does not rely upon the services of IP routers to forward
+   packets between parts of the subnetwork.  However, IP routers may
+   bridge frames at Layer 2 between parts of a subnetwork.  Sometimes,
+   it is convenient to aggregate a group of such subnetworks into a
+   single logical subnetwork.  IP routing protocols (e.g., OSPF, IS-IS,
+   and PIM) can be configured to support this aggregation, but typically
+   present a layer-3 subnetwork rather than a layer-2 subnetwork.  This
+   may also result in a specific packet passing several times over the
+   same layer-2 subnetwork via an intermediate layer-3 gateway (router).
+   Because that aggregation requires layer-3 components, issues thereof
+   are beyond the scope of this document.
+
+   However, while many subnetworks carry IP, they do not necessarily do
+   so with maximum efficiency, minimum complexity, or cost, nor do they
+   implement certain features to efficiently support newer Internet
+   features of increasing importance, such as multicasting or quality of
+   service.
+
+   With the explosive growth of the Internet, IP packets comprise an
+   increasingly large fraction of the traffic carried by the world's
+   telecommunications networks.  It therefore makes sense to optimize
+   both existing and new subnetwork technologies for IP as much as
+   possible.
+
+   Optimizing a subnetwork for IP involves three complementary
+   considerations:
+
+   1.  Providing functionality sufficient to carry IP.
+
+   2.  Eliminating unnecessary functions that increase cost or
+       complexity.
+
+   3.  Choosing subnetwork parameters that maximize the performance of
+       the Internet protocols.
+
+   Because IP is so simple, consideration 2 is more of an issue than
+   consideration 1.  That is to say, subnetwork designers make many more
+   errors of commission than errors of omission.  However, certain
+   enhancements to Internet features, such as multicasting and quality-
+   of-service, benefit significantly from support given by the
+   underlying subnetworks beyond that necessary to carry "traditional"
+   unicast, best-effort IP.
+
+
+
+
+
+
+
+
+Karn, et al.             Best Current Practice                  [Page 3]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   A major consideration in the efficient design of any layered
+   communication network is the appropriate layer(s) in which to
+   implement a given function.  This issue was first addressed in the
+   seminal paper, "End-to-End Arguments in System Design" [SRC81].  That
+   paper argued that many functions can be implemented properly *only*
+   on an end-to-end basis, i.e., at the highest protocol layers, outside
+   the subnetwork.  These functions include ensuring the reliable
+   delivery of data and the use of cryptography to provide
+   confidentiality and message integrity.
+
+   Such functions cannot be provided solely by the concatenation of
+   hop-by-hop services; duplicating these functions at the lower
+   protocol layers (i.e., within the subnetwork) can be needlessly
+   redundant or even harmful to cost and performance.
+
+   However, partial duplication of functionality in a lower layer can
+   *sometimes* be justified by performance, security, or availability
+   considerations.  Examples include link-layer retransmission to
+   improve the performance of an unusually lossy channel, e.g., mobile
+   radio, link-level encryption intended to thwart traffic analysis, and
+   redundant transmission links to improve availability, increase
+   throughput, or to guarantee performance for certain classes of
+   traffic.  Duplication of protocol functions should be done only with
+   an understanding of system-level implications, including possible
+   interactions with higher-layer mechanisms.
+
+   The original architecture of the Internet was influenced by the
+   end-to-end principle [SRC81], and has been, in our view, part of the
+   reason for the Internet's success.
+
+   The remainder of this document discusses the various subnetwork
+   design issues that the authors consider relevant to efficient IP
+   support.
+
+2.  Maximum Transmission Units (MTUs) and IP Fragmentation
+
+   IPv4 packets (datagrams) vary in size, from 20 bytes (the size of the
+   IPv4 header alone) to a maximum of 65535 bytes.  Subnetworks need not
+   support maximum-sized (64KB) IP packets, as IP provides a scheme that
+   breaks packets that are too large for a given subnetwork into
+   fragments that travel as independent IP packets and are reassembled
+   at the destination.  The maximum packet size supported by a
+   subnetwork is known as its Maximum Transmission Unit (MTU).
+
+   Subnetworks may, but are not required to, indicate the length of each
+   packet they carry.  One example is Ethernet with the widely used DIX
+   [DIX82] (not IEEE 802.3 [IEEE8023]) header, which lacks a length
+
+
+
+
+Karn, et al.             Best Current Practice                  [Page 4]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   field to indicate the true data length when the packet is padded to a
+   minimum of 60 bytes.  This is not a problem for uncompressed IP
+   because each IP packet carries its own length field.
+
+   If optional header compression [RFC1144] [RFC2507] [RFC2508]
+   [RFC3095] is used, however, it is required that the link framing
+   indicate frame length because that is needed for the reconstruction
+   of the original header.
+
+   In IP version 4 (the version now in widespread use), fragmentation
+   can occur at either the sending host or in an intermediate router,
+   and fragments can be further fragmented at subsequent routers if
+   necessary.
+
+   In IP version 6 [RFC2460], fragmentation can occur only at the
+   sending host; it cannot occur in a router (called "router
+   fragmentation" in this document).
+
+   Both IPv4 and IPv6 provide a "path MTU discovery" procedure [RFC1191]
+   [RFC1435] [RFC1981] that allows the sending host to avoid
+   fragmentation by discovering the minimum MTU along a given path and
+   reduce its packet sizes accordingly.  This procedure is optional in
+   IPv4 and IPv6.
+
+   Path MTU discovery is widely deployed, but it sometimes encounters
+   problems.  Some routers fail to generate the ICMP messages that
+   convey path MTU information to the sender, and sometimes the ICMP
+   messages are blocked by overly restrictive firewalls.  The result can
+   be a "Path MTU Black Hole" [RFC2923] [RFC1435].
+
+   The Path MTU Discovery procedure, the persistence of path MTU black
+   holes, and the deletion of router fragmentation in IPv6 reflect a
+   consensus of the Internet technical community that router
+   fragmentation is best avoided.  This requires that subnetworks
+   support MTUs that are "reasonably" large.  All IPv4 end hosts are
+   required to accept and reassemble IP packets of size 576 bytes
+   [RFC791], but such a small value would clearly be inefficient.
+   Because IPv6 omits fragmentation by routers, [RFC2460] specifies a
+   larger minimum MTU of 1280 bytes.  Any subnetwork with an internal
+   packet payload smaller than 1280 bytes must implement a mechanism
+   that performs fragmentation/reassembly of IP packets to/from
+   subnetwork frames if it is to support IPv6.
+
+   If a subnetwork cannot directly support a "reasonable" MTU with
+   native framing mechanisms, it should internally fragment.  That is,
+   it should transparently break IP packets into internal data elements
+   and reassemble them at the other end of the subnetwork.
+
+
+
+
+Karn, et al.             Best Current Practice                  [Page 5]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   This leaves the question of what is a "reasonable" MTU.  Ethernet (10
+   and 100 Mb/s) has an MTU of 1500 bytes, and because of the ubiquity
+   of Ethernet few Internet paths currently have MTUs larger than this
+   value.  This severely limits the utility of larger MTUs provided by
+   other subnetworks.  Meanwhile, larger MTUs are increasingly desirable
+   on high-speed subnetworks to reduce the per-packet processing
+   overhead in host computers, and implementers are encouraged to
+   provide them even though they may not be usable when Ethernet is also
+   in the path.
+
+   Various "tunneling" schemes, such as GRE [RFC2784] or IP Security in
+   tunnel mode [RFC2406], treat IP as a subnetwork for IP.  Since
+   tunneling adds header overhead, it can trigger fragmentation, even
+   when the same physical subnetworks (e.g., Ethernet) are used on both
+   sides of the host performing IPsec encapsulation.  Tunneling has made
+   it more difficult to avoid router fragmentation and has increased the
+   incidence of path MTU black holes [RFC2401] [RFC2923].  Larger
+   subnetwork MTUs may help to alleviate this problem.
+
+2.1.  Choosing the MTU in Slow Networks
+
+   In slow networks, the largest possible packet may take a considerable
+   amount of time to send.  This is known as channelisation or
+   serialisation delay.  Total end-to-end interactive response time
+   should not exceed the well-known human factors limit of 100 to 200
+   ms.  This includes all sources of delay: electromagnetic propagation
+   delay, queuing delay, serialisation delay, and the store-and-forward
+   time, i.e., the time to transmit a packet at link speed.
+
+   At low link speeds, store-and-forward delays can dominate total
+   end-to-end delay; these are in turn directly influenced by the
+   maximum transmission unit (MTU) size.  Even when an interactive
+   packet is given a higher queuing priority, it may have to wait for a
+   large bulk transfer packet to finish transmission.  This worst-case
+   wait can be set by an appropriate choice of MTU.
+
+   For example, if the MTU is set to 1500 bytes, then an MTU-sized
+   packet will take about 8 milliseconds to send on a T1 (1.536 Mb/s)
+   link.  But if the link speed is 19.2kb/s, then the transmission time
+   becomes 625 ms -- well above our 100-200ms limit.  A 256-byte MTU
+   would lower this delay to a little over 100 ms.  However, care should
+   be taken not to lower the MTU excessively, as this will increase
+   header overhead and trigger frequent router fragmentation (if Path
+   MTU discovery is not in use).  This is likely to be the case with
+   multicast, where Path MTU discovery is ineffective.
+
+   One way to limit delay for interactive traffic without imposing a
+   small MTU is to give priority to this traffic and to preempt (abort)
+
+
+
+Karn, et al.             Best Current Practice                  [Page 6]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   the transmission of a lower-priority packet when a higher priority
+   packet arrives in the queue.  However, the link resources used to
+   send the aborted packet are lost, and overall throughput will
+   decrease.
+
+   Another way to limit delay is to implement a link-level multiplexing
+   scheme that allows several packets to be in progress simultaneously,
+   with transmission priority given to segments of higher-priority IP
+   packets.  For links using the Point-To-Point Protocol (PPP)
+   [RFC1661], multi-class multilink [RFC2686] [RFC2687] [RFC2689]
+   provides such a facility.
+
+   ATM (asynchronous transfer mode), where SNDUs are fragmented and
+   interleaved across smaller 53-byte ATM cells, is another example of
+   this technique.  However, ATM is generally used on high-speed links
+   where the store-and-forward delays are already minimal, and it
+   introduces significant (~9%) increases in overhead due to the
+   addition of 5-byte cell overhead to each 48-byte ATM cell.
+
+   A third example is the Data-Over-Cable Service Interface
+   Specification (DOCSIS) with typical upstream bandwidths of 2.56 Mb/s
+   or 5.12 Mb/s.  To reduce the impact of a 1500-byte MTU in DOCSIS 1.0
+   [DOCSIS1], a data link layer fragmentation mechanism is specified in
+   DOCSIS 1.1 [DOCSIS2].  To accommodate the installed base, DOCSIS 1.1
+   must be backward compatible with DOCSIS 1.0 cable modems, which
+   generally do not support fragmentation.  Under the co-existence of
+   DOCSIS 1.0 and DOCSIS 1.1, the unfragmented large data packets from
+   DOCSIS 1.0 cable modems may affect the quality of service for voice
+   packets from DOCSIS 1.1 cable modems.  In this case, it has been
+   shown in [DOCSIS3] that the use of bandwidth allocation algorithms
+   can mitigate this effect.
+
+   To summarize, there is a fundamental tradeoff between efficiency and
+   latency in the design of a subnetwork, and the designer should keep
+   this tradeoff in mind.
+
+3.  Framing on Connection-Oriented Subnetworks
+
+   IP requires that subnetworks mark the beginning and end of each
+   variable-length, asynchronous IP packet.  Some examples of links and
+   subnetworks that do not provide this as an intrinsic feature include:
+
+   1.  leased lines carrying a synchronous bit stream;
+
+   2.  ISDN B-channels carrying a synchronous octet stream;
+
+   3.  dialup telephone modems carrying an asynchronous octet stream;
+
+
+
+
+Karn, et al.             Best Current Practice                  [Page 7]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+       and
+
+   4.  Asynchronous Transfer Mode (ATM) networks carrying an
+       asynchronous stream of fixed-sized "cells".
+
+   The Internet community has defined packet framing methods for all
+   these subnetworks.  The Point-To-Point Protocol (PPP) [RFC1661],
+   which uses a variant of HDLC, is applicable to bit synchronous,
+   octet-synchronous, and octet asynchronous links (i.e., examples 1-3
+   above).  PPP is one preferred framing method for IP, since a large
+   number of systems interoperate with PPP.  ATM has its own framing
+   methods, described in [RFC2684] [RFC2364].
+
+   At high speeds, a subnetwork should provide a framed interface
+   capable of carrying asynchronous, variable-length IP datagrams.  The
+   maximum packet size supported by this interface is discussed above in
+   the MTU/Fragmentation section.  The subnetwork may implement this
+   facility in any convenient manner.
+
+   IP packet boundaries need not coincide with any framing or
+   synchronization mechanisms internal to the subnetwork.  When the
+   subnetwork implements variable sized data units, the most
+   straightforward approach is to place exactly one IP packet into each
+   subnetwork data unit (SNDU), and to rely on the subnetwork's existing
+   ability to delimit SNDUs to also delimit IP packets.  A good example
+   is Ethernet.  However, some subnetworks have SNDUs of one or more
+   fixed sizes, as dictated by switching, forward error correction
+   and/or interleaving considerations.  Examples of such subnetworks
+   include ATM, with a single cell payload size of 48 octets plus a 5-
+   octet header, and IS-95 digital cellular, with two "rate sets" of
+   four fixed frame sizes each that may be selected on 20 millisecond
+   boundaries.
+
+   Because IP packets are of variable length, they may not necessarily
+   fit into an integer multiple of fixed-sized SNDUs.  An "adaptation
+   layer" is needed to convert IP packets into SNDUs while marking the
+   boundary between each IP packet in some manner.
+
+   There are several approaches to this problem.  The first is to encode
+   each IP packet into one or more SNDUs with no SNDU containing pieces
+   of more than one IP packet, and to pad out the last SNDU of the
+   packet as needed.  Bits in a control header added to each SNDU
+   indicate where the data segment belongs in the IP packet.  If the
+   subnetwork provides in-order, at-most-once delivery, the header can
+   be as simple as a pair of bits indicating whether the SNDU is the
+   first and/or the last in the IP packet.  Alternatively, for
+   subnetworks that do not reorder the fragments of an SNDU, only the
+   last SNDU of the packet could be marked, as this would implicitly
+
+
+
+Karn, et al.             Best Current Practice                  [Page 8]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   indicate the next SNDU as the first in a new IP packet.  The AAL5
+   (ATM Adaptation Layer 5) scheme used with ATM is an example of this
+   approach, though it adds other features, including a payload length
+   field and a payload CRC.
+
+   In AAL5, the ATM User-User Indication, which is encoded in the
+   Payload Type field of an ATM cell, indicates the last cell of a
+   packet.  The packet trailer is located at the end of the SNDU and
+   contains the packet length and a CRC.
+
+   Another framing technique is to insert per-segment overhead to
+   indicate the presence of a segment option.  When present, the option
+   carries a pointer to the end of the packet.  This differs from AAL5
+   in that it permits another packet to follow within the same segment.
+   MPEG-2 Transport Streams [EN301192] [ISO13818] support this style of
+   fragmentation, and may either use padding (limiting each MPEG
+   transport stream packet to carry only part of one IP packet), or
+   allow a second IP packet to start in the same Transport Stream packet
+   (no padding).
+
+   A third approach is to insert a special flag sequence into the data
+   stream between each IP packet, and to pack the resulting data stream
+   into SNDUs without regard to SNDU boundaries.  This may have
+   implications when frames are lost.  The flag sequence can also pad
+   unused space at the end of an SNDU.  If the special flag appears in
+   the user data, it is escaped to an alternate sequence (usually larger
+   than a flag) to avoid being misinterpreted as a flag.  The HDLC-based
+   framing schemes used in PPP are all examples of this approach.
+
+   All three adaptation schemes introduce overhead; how much depends on
+   the distribution of IP packet sizes, the size(s) of the SNDUs, and in
+   the HDLC-like approaches, the content of the IP packet (since flag-
+   like sequences occurring in the packet must be escaped, which expands
+   them).  The designer must also weigh implementation complexity and
+   performance in the choice and design of an adaptation layer.
+
+4.  Connection-Oriented Subnetworks
+
+   IP has no notion of a "connection"; it is a purely connectionless
+   protocol.  When a connection is required by an application, it is
+   usually provided by TCP [RFC793], the Transmission Control Protocol,
+   running atop IP on an end-to-end basis.
+
+   Connection-oriented subnetworks can be (and are widely) used to carry
+   IP, but often with considerable complexity.  Subnetworks consisting
+   of few nodes can simply open a permanent connection between each pair
+   of nodes.  This is frequently done with ATM.  However, the number of
+   connections increases as the square of the number of nodes, so this
+
+
+
+Karn, et al.             Best Current Practice                  [Page 9]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   is clearly impractical for large subnetworks.  A "shim" layer between
+   IP and the subnetwork is therefore required to manage connections.
+   This is one of the most common functions of a Subnetwork Dependent
+   Convergence Function (SNDCF) sublayer between IP and a subnetwork.
+
+   SNDCFs typically open subnetwork connections as needed when an IP
+   packet is queued for transmission and close them after an idle
+   timeout.  There is no relation between subnetwork connections and any
+   connections that may exist at higher layers (e.g., TCP).
+
+   Because Internet traffic is typically bursty and transaction-
+   oriented, it is often difficult to pick an optimal idle timeout.  If
+   the timeout is too short, subnetwork connections are opened and
+   closed rapidly, possibly over-stressing the subnetwork connection
+   management system (especially if it was designed for voice traffic
+   call holding times).  If the timeout is too long, subnetwork
+   connections are idle much of the time, wasting any resources
+   dedicated to them by the subnetwork.
+
+   Purely connectionless subnets (such as Ethernet), which have no state
+   and dynamically share resources, are optimal for supporting best-
+   effort IP, which is stateless and dynamically shares resources.
+   Connection-oriented packet networks (such as ATM and Frame Relay),
+   which have state and dynamically share resources, are less optimal,
+   since best-effort IP does not benefit from the overhead of creating
+   and maintaining state.  Connection-oriented circuit-switched networks
+   (including the PSTN and ISDN) have state and statically allocate
+   resources for a call, and thus require state creation and maintenance
+   overhead, but do not benefit from the efficiencies of statistical
+   multiplexing sharing of capacity inherent in IP.
+
+   In any event, if an SNDCF that opens and closes subnet connections is
+   used to support IP, care should be taken to make sure that connection
+   processing in the subnet can keep up with relatively short holding
+   times.
+
+5.  Broadcasting and Discovery
+
+   Subnetworks fall into two categories: point-to-point and shared.  A
+   point-to-point subnet has exactly two endpoint components (hosts or
+   routers); a shared link has more than two endpoint components, using
+   either an inherently broadcast medium (e.g., Ethernet, radio) or a
+   switching layer hidden from the network layer (e.g., switched
+   Ethernet, Myrinet [MYR95], ATM).  Switched subnetworks handle
+   broadcast by copying broadcast packets, providing each interface that
+   supports one, or more, systems (hosts or routers) with a copy of each
+   packet.
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 10]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   Several Internet protocols for IPv4 make use of broadcast
+   capabilities, including link-layer address lookup (ARP), auto-
+   configuration (RARP, BOOTP, DHCP), and routing (RIP).
+
+   A lack of broadcast capability can impede the performance of these
+   protocols, or render them inoperable (e.g., DHCP).  ARP-like link
+   address lookup can be provided by a centralized database, but at the
+   expense of potentially higher response latency and the need for nodes
+   to have explicit knowledge of the ARP server address.  Shared links
+   should support native, link-layer subnet broadcast.
+
+   A corresponding set of IPv6 protocols uses multicasting (see next
+   section) instead of broadcasting to provide similar functions with
+   improved scaling in large networks.
+
+6.  Multicasting
+
+   The Internet model includes "multicasting", where IP packets are sent
+   to all the members of a multicast group [RFC1112] [RFC3376]
+   [RFC2710].  Multicast is an option in IPv4, but a standard feature of
+   IPv6.  IPv4 multicast is currently used by multimedia,
+   teleconferencing, gaming, and file distribution (web, peer-to-peer
+   sharing) applications, as well as by some key network and host
+   protocols (e.g., RIPv2, OSPF, NTP).  IPv6 additionally relies on
+   multicast for network configuration (DHCP-like autoconfiguration) and
+   link-layer address discovery [RFC2461] (replacing ARP).  In the case
+   of IPv6, this can allow autoconfiguration and address discovery to
+   span across routers, whereas the IPv4 broadcast-based services cannot
+   without ad-hoc router support [RFC1812].
+
+   Multicast-enabled IP routers organize each multicast group into a
+   spanning tree, and route multicast packets by making copies of each
+   multicast packet and forwarding the copies to each output interface
+   that includes at least one downstream member of the multicast group.
+
+   Multicasting is considerably more efficient when a subnetwork
+   explicitly supports it.  For example, a router relaying a multicast
+   packet onto an Ethernet segment need send only one copy of the
+   packet, no matter how many members of the multicast group are
+   connected to the segment.  Without native multicast support, routers
+   and switches on shared links would need to use broadcast with
+   software filters, such that every multicast packet sent incurs
+   software overhead for every node on the subnetwork, even if a node is
+   not a member of the multicast group.  Alternately, the router would
+   transmit a separate copy to every member of the multicast group on
+   the segment, as is done on multicast-incapable switched subnets.
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 11]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   Subnetworks using shared channels (e.g., radio LANs, Ethernets) are
+   especially suitable for native multicasting, and their designers
+   should make every effort to support it.  This involves designating a
+   section of the subnetwork's own address space for multicasting.  On
+   these networks, multicast is basically broadcast on the medium, with
+   Layer-2 receiver filters.
+
+   Subnet interfaces also need to be designed to accept packets
+   addressed to some number of multicast addresses, in addition to the
+   unicast packets specifically addressed to them.  The number of
+   multicast addresses that needs to be supported by a host depends on
+   the requirements of the associated host; at least several dozen will
+   meet most current needs.
+
+   On low-speed networks, the multicast address recognition function may
+   be readily implemented in host software, but on high-speed networks,
+   it should be implemented in subnetwork hardware.  This hardware need
+   not be complete; for example, many Ethernet interfaces implement a
+   "hashing" function where the IP layer receives all of the multicast
+   (and unicast) traffic to which the associated host subscribes, plus
+   some small fraction of multicast traffic to which the host does not
+   subscribe.  Host/router software then has to discard the unwanted
+   packets that pass the Layer-2 multicast address filter [RFC1112].
+
+   There does not need to be a one-to-one mapping between a Layer-2
+   multicast address and an IP multicast address.  An address overlap
+   may significantly degrade the filtering capability of a receiver's
+   hardware multicast address filter.  A subnetwork supporting only
+   broadcast should use this service for multicast and must rely on
+   software filtering.
+
+   Switched subnetworks must also provide a mechanism for copying
+   multicast packets to ensure the packets reach at least all members of
+   a multicast group.  One option is to "flood" multicast packets in the
+   same manner as broadcast.  This can lead to unnecessary transmissions
+   on some subnetwork links (notably non-multicast-aware Ethernet
+   switches).  Some subnetworks therefore allow multicast filter tables
+   to control which links receive packets belonging to a specific group.
+   To configure this automatically requires access to Layer-3 group
+   membership information (e.g., IGMP [RFC3376], or MLD [RFC2710]).
+   Various implementation options currently exist to provide a subnet
+   node with a list of mappings of multicast addresses to
+   ports/interfaces.  These employ a range of approaches, including
+   signaling from end hosts (e.g., IEEE 802 GARP/GMRP [802.1p]),
+   signaling from switches (e.g., CGMP [CGMP] and RGMP [RFC3488]),
+   interception and proxy of IP group membership packets (e.g., IGMP/MLD
+   Proxy [MAGMA-PROXY]), and enabling Layer-2 devices to
+   snoop/inspect/peek into forwarded Layer-3 protocol headers (e.g.,
+
+
+
+Karn, et al.             Best Current Practice                 [Page 12]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   IGMP, MLD, PIM) so that they may infer Layer-3 multicast group
+   membership [MAGMA-SNOOP].  These approaches differ in their
+   complexity, flexibility, and ability to support new protocols.
+
+7.  Bandwidth on Demand (BoD) Subnets
+
+   Some subnets allow a number of subnet nodes to share a channel
+   efficiently by assigning transmission opportunities dynamically.
+   Transmission opportunities are requested by a subnet node when it has
+   packets to send.  The subnet schedules and grants transmission
+   opportunities sufficient to allow the transmitting subnet node to
+   send one or more packets (or packet fragments).  We call these
+   subnets Bandwidth on Demand (BoD) subnets.  Examples of BoD subnets
+   include Demand Assignment Multiple Access (DAMA) satellite and
+   terrestrial wireless networks, IEEE 802.11 point coordination
+   function (PCF) mode, and DOCSIS.  A connection-oriented network (such
+   as the PSTN, ATM or Frame Relay) reserves resources on a much longer
+   timescale, and is therefore not a BoD subnet in our taxonomy.
+
+   The design parameters for BoD are similar to those in connection-
+   oriented subnetworks, although the implementations may vary
+   significantly.  In BoD, the user typically requests access to the
+   shared channel for some duration.  Access may be allocated for a
+   period of time at a specific rate, for a certain number of packets,
+   or until the user releases the channel.  Access may be coordinated
+   through a central management entity or with a distributed algorithm
+   amongst the users.  Examples of the resource that may be shared
+   include a terrestrial wireless hop, an upstream channel in a cable
+   television system, a satellite uplink, and an end-to-end satellite
+   channel.
+
+   Long-delay BoD subnets pose problems similar to connection-oriented
+   subnets in anticipating traffic.  While connection-oriented subnets
+   hold idle channels open expecting new data to arrive, BoD subnets
+   request channel access based on buffer occupancy (or expected buffer
+   occupancy) on the sending port.  Poor performance will likely result
+   if the sender does not anticipate additional traffic arriving at that
+   port during the time it takes to grant a transmission request.  It is
+   recommended that the algorithm have the capability to extend a hold
+   on the channel for data that has arrived after the original request
+   was generated (this may be done by piggybacking new requests on user
+   data).
+
+   There is a wide variety of BoD protocols available.  However, there
+   has been relatively little comprehensive research on the interactions
+   between BoD mechanisms and Internet protocol performance.  Research
+   on some specific mechanisms is available (e.g., [AR02]).  One item
+   that has been studied is TCP's retransmission timer [KY02].  BoD
+
+
+
+Karn, et al.             Best Current Practice                 [Page 13]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   systems can cause spurious timeouts when adjusting from a relatively
+   high data rate, to a relatively low data rate.  In this case, TCP's
+   transmitted data takes longer to get through the network than
+   predicted by the TCP sender's computed retransmission timeout.
+   Therefore, the TCP sender is prone to resending a segment
+   prematurely.
+
+8.  Reliability and Error Control
+
+   In the Internet architecture, the ultimate responsibility for error
+   recovery is at the end points [SRC81].  The Internet may occasionally
+   drop, corrupt, duplicate, or reorder packets, and the transport
+   protocol (e.g., TCP) or application (e.g., if UDP is used as the
+   transport protocol) must recover from these errors on an end-to-end
+   basis [RFC3155].  Error recovery in the subnetwork is therefore
+   justifiable only to the extent that it can enhance overall
+   performance.  It is important to recognize that a subnetwork can go
+   too far in attempting to provide error recovery services in the
+   Internet environment.  Subnet reliability should be "lightweight",
+   i.e., it only has to be "good enough", *not* perfect.
+
+   In this section, we discuss how to analyze characteristics of a
+   subnetwork to determine what is "good enough".  The discussion below
+   focuses on TCP, which is the most widely-used transport protocol in
+   the Internet.  It is widely believed (and is a stated goal within the
+   IETF) that non-TCP transport protocols should attempt to be "TCP-
+   friendly" and have many of the same performance characteristics.
+   Thus, the discussion below should be applicable, even to portions of
+   the Internet where TCP may not be the predominant protocol.
+
+8.1.  TCP vs Link-Layer Retransmission
+
+   Error recovery involves the generation and transmission of redundant
+   information computed from user data.  Depending on how much redundant
+   information is sent and how it is generated, the receiver can use it
+   to reliably detect transmission errors, correct up to some maximum
+   number of transmission errors, or both.  The general approach is
+   known as Error Control Coding, or ECC.
+
+   The use of ECC to detect transmission errors so that retransmissions
+   (hopefully without errors) can be requested is widely known as "ARQ"
+   (Automatic Repeat Request).
+
+   When enough ECC information is available to permit the receiver to
+   correct some transmission errors without a retransmission, the
+   approach is known as Forward Error Correction (FEC).  Due to the
+   greater complexity of the required ECC and the need to tailor its
+   design to the characteristics of a specific modem and channel, FEC
+
+
+
+Karn, et al.             Best Current Practice                 [Page 14]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   has traditionally been implemented in special-purpose hardware
+   integral to a modem.  This effectively makes it part of the physical
+   layer.
+
+   Unlike ARQ, FEC was rarely used for telecommunications outside of
+   space links prior to the 1990s.  It is now nearly universal in
+   telephone, cable and DSL modems, digital satellite links, and digital
+   mobile telephones.  FEC is also heavily used in optical and magnetic
+   storage where "retransmissions" are not possible.
+
+   Some systems use hybrid combinations of ARQ layered atop FEC; V.90
+   dialup modems (in the upstream direction) with V.42 error control are
+   one example.  Most errors are corrected by the trellis (FEC) code
+   within the V.90 modem, and most remaining errors are detected and
+   corrected by the ARQ mechanisms in V.42.
+
+   Work is now underway to apply FEC above the physical layer, primarily
+   in connection with reliable multicasting [RFC3048] [RFC3450-RFC3453]
+   where conventional ARQ mechanisms are inefficient or difficult to
+   implement.  However, in this discussion, we will assume that if FEC
+   is present, it is implemented within the physical layer.
+
+   Depending on the layer in which it is implemented, error control can
+   operate on an end-to-end basis or over a shorter span, such as a
+   single link.  TCP is the most important example of an end-to-end
+   protocol that uses an ARQ strategy.
+
+   Many link-layer protocols use ARQ, usually some flavor of HDLC
+   [ISO3309].  Examples include the X.25 link layer, the AX.25 protocol
+   used in amateur packet radio, 802.11 wireless LANs, and the reliable
+   link layer specified in IEEE 802.2.
+
+   Only end-to-end error recovery can ensure reliable service to the
+   application (see Section 8).  However, some subnetworks (e.g., many
+   wireless links) also have link-layer error recovery as a performance
+   enhancement [RFC3366].  For example, many cellular links have small
+   physical frame sizes (< 100 bytes) and relatively high frame loss
+   rates.  Relying solely on end-to-end error recovery can clearly yield
+   a performance degradation, as retransmissions across the end-to-end
+   path take much longer to be received than when link layer
+   retransmissions are used.  Thus, link-layer error recovery can often
+   increase end-to-end performance.  As a result, link-layer and end-
+   to-end recovery often co-exist; this can lead to the possibility of
+   inefficient interactions between the two layers of ARQ protocols.
+
+   This inter-layer "competition" might lead to the following wasteful
+   situation.  When the link layer retransmits (parts of) a packet, the
+   link latency momentarily increases.  Since TCP bases its
+
+
+
+Karn, et al.             Best Current Practice                 [Page 15]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   retransmission timeout on prior measurements of total end-to-end
+   latency, including that of the link in question, this sudden increase
+   in latency may trigger an unnecessary retransmission by TCP of a
+   packet that the link layer is still retransmitting.  Such spurious
+   end-to-end retransmissions generate unnecessary load and reduce end-
+   to-end throughput.  As a result, the link layer may even have
+   multiple copies of the same packet in the same link queue at the same
+   time.  In general, one could say the competing error recovery is
+   caused by an inner control loop (link-layer error recovery) reacting
+   to the same signal as an outer control loop (end-to-end error
+   recovery) without any coordination between the loops.  Note that this
+   is solely an efficiency issue; TCP continues to provide reliable
+   end-to-end delivery over such links.
+
+   This raises the question of how persistent a link-layer sender should
+   be in performing retransmission [RFC3366].  We define the link-layer
+   (LL) ARQ persistency as the maximum time that a particular link will
+   spend trying to transfer a packet before it can be discarded.  This
+   deliberately simplified definition says nothing about the maximum
+   number of retransmissions, retransmission strategies, queue sizes,
+   queuing disciplines, transmission delays, or the like.  The reason we
+   use the term LL ARQ persistency, instead of a term such as "maximum
+   link-layer packet holding time," is that the definition closely
+   relates to link-layer error recovery.  For example, on links that
+   implement straightforward error recovery strategies, LL ARQ
+   persistency will often correspond to a maximum number of
+   retransmissions permitted per link-layer frame.
+
+   For link layers that do not or cannot differentiate between flows
+   (e.g., due to network layer encryption), the LL ARQ persistency
+   should be small.  This avoids any harmful effects or performance
+   degradation resulting from indiscriminate high persistence.  A
+   detailed discussion of these issues is provided in [RFC3366].
+
+   However, when a link layer can identify individual flows and apply
+   ARQ selectively [LKJK02], then the link ARQ persistency should be
+   high for a flow using reliable unicast transport protocols (e.g.,
+   TCP) and must be low for all other flows.  Setting the link ARQ
+   persistency larger than the largest link outage allows TCP to rapidly
+   restore transmission without needing to wait for a retransmission
+   time out.  This generally improves TCP performance in the face of
+   transient outages.  However, excessively high persistence may be
+   disadvantageous; a practical upper limit of 30-60 seconds may be
+   desirable.  Implementation of such schemes remains a research issue.
+   (See also the following section "Recovery from Subnetwork Outages").
+
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 16]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   Many subnetwork designers have opportunities to reduce the
+   probability of packet loss, e.g., with FEC, ARQ, and interleaving, at
+   the cost of increased delay.  TCP performance improves with
+   decreasing loss but worsens with increasing end-to-end delay, so it
+   is important to find the proper balance through analysis and
+   simulation.
+
+8.2.  Recovery from Subnetwork Outages
+
+   Some types of subnetworks, particularly mobile radio, are subject to
+   frequent temporary outages.  For example, an active cellular data
+   user may drive or walk into an area (such as a tunnel) that is out of
+   range of any base station.  No packets will be delivered successfully
+   until the user returns to an area with coverage.
+
+   The Internet protocols currently provide no standard way for a
+   subnetwork to explicitly notify an upper layer protocol (e.g., TCP)
+   that it is experiencing an outage rather than severe congestion.
+
+   Under these circumstances TCP will, after each unsuccessful
+   retransmission, wait even longer before trying again; this is its
+   "exponential back-off" algorithm.  Furthermore, TCP will not discover
+   that the subnetwork outage has ended until its next retransmission
+   attempt.  If TCP has backed off, this may take some time.  This can
+   lead to extremely poor TCP performance over such subnetworks.
+
+   It is therefore highly desirable that a subnetwork subject to outages
+   does not silently discard packets during an outage.  Ideally, the
+   subnetwork should define an interface to the next higher layer (i.e.,
+   IP) that allows it to refuse packets during an outage, and to
+   automatically ask IP for new packets when it is again able to deliver
+   them.  If it cannot do this, then the subnetwork should hold onto at
+   least some of the packets it accepts during an outage and attempt to
+   deliver them when the outage ends.  When packets are discarded, IP
+   should be notified so that the appropriate ICMP messages can be sent.
+
+   Note that it is *not* necessary to completely avoid dropping packets
+   during an outage.  The purpose of holding onto a packet during an
+   outage, either in the subnetwork or at the IP layer, is so that its
+   eventual delivery will implicitly notify TCP that the subnetwork is
+   again operational.  This is to enhance performance, not to ensure
+   reliability -- reliability, as discussed earlier, can only be ensured
+   on an end-to-end basis.
+
+   Only a few packets per TCP connection, including ACKs, need be held
+   in this way to cause the TCP sender to recover from the additional
+   losses once the flow resumes [RFC3366].
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 17]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   Because it would be a layering violation (and possibly a performance
+   hit) for IP or a subnetwork layer to look at TCP headers (which would
+   in any event be impossible if IPsec encryption [RFC2401] is in use),
+   it would be reasonable for the IP or subnetwork layers to choose, as
+   a design parameter, some small number of packets that will be
+   retained during an outage.
+
+8.3.  CRCs, Checksums and Error Detection
+
+   The TCP [RFC793], UDP [RFC768], ICMP, and IPv4 [RFC791] protocols all
+   use the same simple 16-bit 1's complement checksum algorithm
+   [RFC1071] to detect corrupted packets.  The IPv4 header checksum
+   protects only the IPv4 header, while the TCP, ICMP, and UDP checksums
+   provide end-to-end error detection for both the transport pseudo
+   header (including network and transport layer information) and the
+   transport payload data.  Protection of the data is optional for
+   applications using UDP [RFC768] for IPv4, but is required for IPv6.
+
+   The Internet checksum is not very strong from a coding theory
+   standpoint, but it is easy to compute in software, and various
+   proposals to replace the Internet checksums with stronger checksums
+   have failed.  However, it is known that undetected errors can and do
+   occur in packets received by end hosts [SP2000].
+
+   To reduce processing costs, IPv6 has no IP header checksum.  The
+   destination host detects "important" errors in the IP header, such as
+   the delivery of the packet to the wrong destination.  This is done by
+   including the IP source and destination addresses (pseudo header) in
+   the computation of the checksum in the TCP or UDP header, a practice
+   already performed in IPv4.  Errors in other IPv6 header fields may go
+   undetected within the network; this was considered a reasonable price
+   to pay for a considerable reduction in the processing required by
+   each router, and it was assumed that subnetworks would use a strong
+   link CRC.
+
+   One way to provide additional protection for an IPv4 or IPv6 header
+   is by the authentication and packet integrity services of the IP
+   Security (IPsec) protocol [RFC2401].  However, this may not be a
+   choice available to the subnetwork designer.
+
+   Most subnetworks implement error detection just above the physical
+   layer.  Packets corrupted in transmission are detected and discarded
+   before delivery to the IP layer.  A 16-bit cyclic redundancy check
+   (CRC) is usually the minimum for error detection.  This is
+   significantly more robust against most patterns of errors than the
+   16-bit Internet checksum.  Note that the error detection properties
+   of a specific CRC code diminish with increasing frame size.  The
+   Point-to-Point Protocol [RFC1662] requires support of a 16-bit CRC
+
+
+
+Karn, et al.             Best Current Practice                 [Page 18]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   for each link frame, with a 32-bit CRC as an option.  (PPP is often
+   used in conjunction with a dialup modem, which provides its own error
+   control).  Other subnetworks, including 802.3/Ethernet, AAL5/ATM,
+   FDDI, Token Ring, and PPP over SONET/SDH all use a 32-bit CRC.  Many
+   subnetworks can also use other mechanisms to enhance the error
+   detection capability of the link CRC (e.g., FEC in dialup modems,
+   mobile radio and satellite channels).
+
+   Any new subnetwork designed to carry IP should therefore provide
+   error detection for each IP packet that is at least as strong as the
+   32-bit CRC specified in [ISO3309].  While this will achieve a very
+   low undetected packet error rate due to transmission errors, it will
+   not (and need not) achieve a very low packet loss rate as the
+   Internet protocols are better suited to dealing with lost packets
+   than to dealing with corrupted packets [SRC81].
+
+   Packet corruption may be, and is, also caused by bugs in host and
+   router hardware and software.  Even if every subnetwork implemented
+   strong error detection, it is still essential that end-to-end
+   checksums are used at the receiving end host [SP2000].
+
+   Designers of complex subnetworks consisting of internal links and
+   packet switches should consider implementing error detection on an
+   edge-to-edge basis to cover an entire SNDU (or IP packet).  A CRC
+   would be generated at the entry point to the subnetwork and checked
+   at the exit endpoint.  This may be used instead of, or in combination
+   with, error detection at the interface to each physical link.  An
+   edge-to-edge check has the significant advantage of protecting
+   against errors introduced anywhere within the subnetwork, not just
+   within its transmission links.  Examples of this approach include the
+   way in which the Ethernet CRC-32 is handled by LAN bridges [802.1D].
+   ATM AAL5 [ITU-I363] also uses an edge-to-edge CRC-32.
+
+   Some specific applications may be tolerant of residual errors in the
+   data they exchange, but removal of the link CRC may expose the
+   network to an undesirable increase in undetected errors in the IP and
+   transport headers.  Applications may also require a high level of
+   error protection for control information exchanged by protocols
+   acting above the transport layer.  One example is a voice codec,
+   which is robust against bit errors in the speech samples.  For such
+   mechanisms to work, the receiving application must be able to
+   tolerate receiving corrupted data.  This also requires that an
+   application uses a mechanism to signal that payload corruption is
+   permitted and to indicate the coverage (headers and data) required to
+   be protected by the subnetwork CRC.  The UDP-Lite protocol [RFC3828]
+   is the first Internet standards track transport protocol supporting
+   partial payload protection.  Receipt of corrupt data by arbitrary
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 19]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   application protocols carries a serious danger that a subnet delivers
+   data with errors that remain undetected by the application and hence
+   corrupt the communicated data [SRC81].
+
+8.4.  How TCP Works
+
+   One of TCP's functions is end-host based congestion control for the
+   Internet.  This is a critical part of the overall stability of the
+   Internet, so it is important that link-layer designers understand
+   TCP's congestion control algorithms.
+
+   TCP assumes that, at the most abstract level, the network consists of
+   links and queues.  Queues provide output-buffering on links that are
+   momentarily oversubscribed.  They smooth instantaneous traffic bursts
+   to fit the link bandwidth.  When demand exceeds link capacity long
+   enough to fill the queue, packets must be dropped.  The traditional
+   action of dropping the most recent packet ("tail dropping") is no
+   longer recommended [RFC2309] [RFC2914], but it is still widely
+   practiced.
+
+   TCP uses sequence numbering and acknowledgments (ACKs) on an
+   end-to-end basis to provide reliable, sequenced delivery.  TCP ACKs
+   are cumulative, i.e., each implicitly ACKs every segment received so
+   far.  If a packet with an unexpected sequence number is received, the
+   ACK field in the packets returned by the receiver will cease to
+   advance.  Using an optional enhancement, TCP can send selective
+   acknowledgments (SACKs) [RFC2018] to indicate which segments have
+   arrived at the receiver.
+
+   Since the most common cause of packet loss is congestion, TCP treats
+   packet loss as an indication of potential Internet congestion along
+   the path between TCP end hosts.  This happens automatically, and the
+   subnetwork need not know anything about IP or TCP.  A subnetwork node
+   simply drops packets whenever it must, though some packet-dropping
+   strategies (e.g., RED) are more fair to competing flows than others.
+
+   TCP recovers from packet losses in two different ways.  The most
+   important mechanism is the retransmission timeout.  If an ACK fails
+   to arrive after a certain period of time, TCP retransmits the oldest
+   unacked packet.  Taking this as a hint that the network is congested,
+   TCP waits for the retransmission to be ACKed before it continues, and
+   it gradually increases the number of packets in flight as long as a
+   timeout does not occur again.
+
+   A retransmission timeout can impose a significant performance
+   penalty, as the sender is idle during the timeout interval and
+   restarts with a congestion window of one TCP segment following the
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 20]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   timeout.  To allow faster recovery from the occasional lost packet in
+   a bulk transfer, an alternate scheme, known as "fast recovery", was
+   introduced [RFC2581] [RFC2582] [RFC2914] [TCPF98].
+
+   Fast recovery relies on the fact that when a single packet is lost in
+   a bulk transfer, the receiver continues to return ACKs to subsequent
+   data packets that do not actually acknowledge any newly-received
+   data.  These are known as "duplicate acknowledgments" or "dupacks".
+   The sending TCP can use dupacks as a hint that a packet has been lost
+   and retransmit it without waiting for a timeout.  Dupacks effectively
+   constitute a negative acknowledgment (NAK) for the packet sequence
+   number in the acknowledgment field.  TCP waits until a certain number
+   of dupacks (currently 3) are seen prior to assuming a loss has
+   occurred; this helps avoid an unnecessary retransmission during
+   out-of-sequence delivery.
+
+   A technique called "Explicit Congestion Notification" (ECN) [RFC3168]
+   allows routers to directly signal congestion to hosts without
+   dropping packets.  This is done by setting a bit in the IP header.
+   Since ECN support is likely to remain optional, the lack of an ECN
+   bit must *never* be interpreted as a lack of congestion.  Thus, for
+   the foreseeable future, TCP must interpret a lost packet as a signal
+   of congestion.
+
+   The TCP "congestion avoidance" [RFC2581] algorithm maintains a
+   congestion window (cwnd) controlling the amount of data TCP may have
+   in flight at any moment.  Reducing cwnd reduces the overall bandwidth
+   obtained by the connection; similarly, raising cwnd increases
+   performance, up to the limit of the available capacity.
+
+   TCP probes for available network capacity by initially setting cwnd
+   to one or two packets and then increasing cwnd by one packet for each
+   ACK returned from the receiver.  This is TCP's "slow start"
+   mechanism.  When a packet loss is detected (or congestion is signaled
+   by other mechanisms), cwnd is reset to one and the slow start process
+   is repeated until cwnd reaches one half of its previous setting
+   before the reset.  Cwnd continues to increase past this point, but at
+   a much slower rate than before.  If no further losses occur, cwnd
+   will ultimately reach the window size advertised by the receiver.
+
+   This is an "Additive Increase, Multiplicative Decrease" (AIMD)
+   algorithm.  The steep decrease of cwnd in response to congestion
+   provides for network stability; the AIMD algorithm also provides for
+   fairness between long running TCP connections sharing the same path.
+
+
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 21]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+8.5.  TCP Performance Characteristics
+
+   Caveat
+
+   Here we present a current "state-of-the-art" understanding of TCP
+   performance.  This analysis attempts to characterize the performance
+   of TCP connections over links of varying characteristics.
+
+   Link designers may wish to use the techniques in this section to
+   predict what performance TCP/IP may achieve over a new link-layer
+   design.  Such analysis is encouraged.  Because this is a relatively
+   new analysis, and the theory is based on single-stream TCP
+   connections under "ideal" conditions, it should be recognized that
+   the results of such analysis may differ from actual performance in
+   the Internet.  That being said, we have done our best to provide the
+   designers with helpful information to get an accurate picture of the
+   capabilities and limitations of TCP under various conditions.
+
+8.5.1.  The Formulae
+
+   The performance of TCP's AIMD Congestion Avoidance algorithm has been
+   extensively analyzed.  The current best formula for the performance
+   of the specific algorithms used by Reno TCP (i.e., the TCP specified
+   in [RFC2581]) is given by Padhye, et al. [PFTK98].  This formula is:
+
+                                         MSS
+           BW = --------------------------------------------------------
+                RTT*sqrt(1.33*p) + RTO*p*[1+32*p^2]*min[1,3*sqrt(.75*p)]
+
+   where
+
+           BW   is the maximum TCP throughout achievable by an
+                individual TCP flow
+           MSS  is the TCP segment size being used by the connection
+           RTT  is the end-to-end round trip time of the TCP connection
+           RTO  is the packet timeout (based on RTT)
+           p    is the packet loss rate for the path
+                (i.e., .01 if there is 1% packet loss)
+
+   Note that the speed of the links making up the Internet path does not
+   explicitly appear in this formula.  Attempting to send faster than
+   the slowest link in the path causes the queue to grow at the
+   transmitter driving the bottleneck.  This increases the RTT, which in
+   turn reduces the achievable throughput.
+
+   This is currently considered to be the best approximate formula for
+   Reno TCP performance.  A further simplification of this formula is
+   generally made by assuming that RTO is approximately 5*RTT.
+
+
+
+Karn, et al.             Best Current Practice                 [Page 22]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   TCP is constantly being improved.  A simpler formula, which gives an
+   upper bound on the performance of any AIMD algorithm which is likely
+   to be implemented in TCP in the future, was derived by Ott, et al.
+   [MSMO97].
+
+                     MSS   1
+           BW = C    --- -------
+                     RTT sqrt(p)
+
+   where C is 0.93.
+
+8.5.2.  Assumptions
+
+   Both formulae assume that the TCP Receiver Window is not limiting the
+   performance of the connection.  Because the receiver window is
+   entirely determined by end-hosts, we assume that hosts will maximize
+   the announced receiver window to maximize their network performance.
+
+   Both of these formulae allow BW to become infinite if there is no
+   loss.  However, an Internet path will drop packets at bottlenecked
+   queues if the load is too high.  Thus, a completely lossless TCP/IP
+   network can never occur (unless the network is being underutilized).
+
+   The RTT used is the arithmetic average, including queuing delays.
+
+   The formulae are for a single TCP connection.  If a path carries many
+   TCP connections, each will follow the formulae above independently.
+
+   The formulae assume long-running TCP connections.  For connections
+   that are extremely short (<10 packets) and don't lose any packets,
+   performance is driven by the TCP slow-start algorithm.  For
+   connections of medium length, where on average only a few segments
+   are lost, single connection performance will actually be slightly
+   better than given by the formulae above.
+
+   The difference between the simple and complex formulae above is that
+   the complex formula includes the effects of TCP retransmission
+   timeouts.  For very low levels of packet loss (significantly less
+   than 1%), timeouts are unlikely to occur, and the formulae lead to
+   very similar results.  At higher packet losses (1% and above), the
+   complex formula gives a more accurate estimate of performance (which
+   will always be significantly lower than the result from the simple
+   formula).
+
+   Note that these formulae break down as p approaches 100%.
+
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 23]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+8.5.3.  Analysis of Link-Layer Effects on TCP Performance
+
+   Consider the following example:
+
+   A designer invents a new wireless link layer which, on average, loses
+   1% of IP packets.  The link layer supports packets of up to 1040
+   bytes, and has a one-way delay of 20 msec.
+
+   If this link were to be used on an Internet path with a round trip
+   time greater than 80ms, the upper bound may be computed by:
+
+   For MSS, use 1000 bytes to exclude the 40 bytes of minimum IPv4 and
+   TCP headers.
+
+   For RTT, use 120 msec (80 msec for the Internet part, plus 20 msec
+   each way for the new wireless link).
+
+   For p, use .01.  For C, assume 1.
+
+   The simple formula gives:
+
+      BW = (1000 * 8 bits) / (.120 sec * sqrt(.01)) = 666 kbit/sec
+
+   The more complex formula gives:
+
+      BW = 402.9 kbit/sec
+
+   If this were a 2 Mb/s wireless LAN, the designers might be somewhat
+   disappointed.
+
+   Some observations on performance:
+
+   1.  We have assumed that the packet losses on the link layer are
+       interpreted as congestion by TCP.  This is a "fact of life" that
+       must be accepted.
+
+   2.  The equations for TCP performance are all expressed in terms of
+       packet loss, but many subnetwork designers think in terms of
+       bit-error ratio.  *If* channel bit errors are independent, then
+       the probability of a packet being corrupted is:
+
+         p = 1 - ([1 - BER]^[FRAME_SIZE*8])
+
+       Here we assume FRAME_SIZE is in bytes and "^" represents
+       exponentiation.  It includes the user data and all headers
+       (TCP,IP and subnetwork).  (Note: this analysis assumes the
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 24]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+       subnetwork does not perform ARQ or transparent fragmentation
+       [RFC3366].)  If the inequality
+
+         BER * [FRAME_SIZE*8] << 1
+
+       holds, the packet loss probability p can be approximated by:
+
+         p = BER * [FRAME_SIZE*8]
+
+       These equations can be used to apply BER to the performance
+       equations above.
+
+       Note that FRAME_SIZE can vary from one packet to the next.  Small
+       packets (such as TCP acks) generally have a smaller probability
+       of packet error than, say, a TCP packet carrying one MSS (maximum
+       segment size) of user data.  A flow of small TCP acks can be
+       expected to be slightly more reliable than a stream of larger TCP
+       data segments.
+
+       It bears repeating that the above analysis assumes that bit
+       errors are statistically independent.  Because this is not true
+       for many real links, our computation of p is actually an upper
+       bound, not the exact probability of packet loss.
+
+       There are many reasons why bit errors are not independent on real
+       links.  Many radio links are affected by propagation fading or by
+       interference that lasts over many bit times.  Also, links with
+       Forward Error Correction (FEC) generally have very non-uniform
+       bit error distributions that depend on the type of FEC, but in
+       general the uncorrected errors tend to occur in bursts even when
+       channel symbol errors are independent.  In all such cases, our
+       computation of p from BER can only place an upper limit on the
+       packet loss rate.
+
+       If the distribution of errors under the FEC scheme is known, one
+       could apply the same type of analysis as above, using the correct
+       distribution function for the BER.  It is more likely in these
+       FEC cases, however, that empirical methods are needed to
+       determine the actual packet loss rate.
+
+   3.  Note that the packet size plays an important role.  If the
+       subnetwork loss characteristics are such that large packets have
+       the same probability of loss as smaller packets, then larger
+       packets will yield improved performance.
+
+
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 25]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   4.  We have chosen a specific RTT that might occur on a wide-area
+       Internet path within the USA.  It is important to recognize that
+       a variety of RTT values are experienced in the Internet.
+
+       For example, RTTs are typically less than 10 msec in a wired LAN
+       environment when communicating with a local host.  International
+       connections may have RTTs of 200 msec or more.  Modems and other
+       low-capacity links can add considerable delay due to their long
+       packet transmission (serialisation) times.
+
+       Links over geostationary repeater satellites have one-way speed-
+       of-light delays of around 250ms, a minimum of 125ms propagation
+       delay up to the satellite and 125ms down.  The RTT of an end-to-
+       end TCP connection that includes such a link can be expected to
+       be greater than 250ms.
+
+       Queues on heavily-congested links may back up, increasing RTTs.
+       Finally, virtual private networks (VPNs) and other forms of
+       encryption and tunneling can add significant end-to-end delay to
+       network connections.
+
+9.  Quality-of-Service (QoS) considerations
+
+   It is generally recognized that specific service guarantees are
+   needed to support real-time multimedia, toll-quality telephony, and
+   other performance-critical applications.  The provision of such
+   Quality of Service guarantees in the Internet is an active area of
+   research and standardization.  The IETF has not converged on a single
+   service model, set of services, or single mechanism that will offer
+   useful guarantees to applications and be scalable to the Internet.
+   Indeed, the IETF does not have a single definition of Quality of
+   Service.  [RFC2990] represents a current understanding of the
+   challenges in architecting QoS for the Internet.
+
+   There are presently two architectural approaches to providing
+   mechanisms for QoS support in the Internet.
+
+   IP Integrated Services (Intserv) [RFC1633] provides fine-grained
+   service guarantees to individual flows.  Flows are identified by a
+   flow specification (flowspec), which creates a stateful association
+   between individual packets by matching fields in the packet header.
+   Capacity is reserved for the flow, and appropriate traffic
+   conditioning and scheduling is installed in routers along the path.
+   The ReSerVation Protocol (RSVP) [RFC2205] [RFC2210] is usually, but
+   need not necessarily be, used to install the flow QoS state.  Intserv
+   defines two services, in addition to the Default (best effort)
+   service.
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 26]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   1.  Guaranteed Service (GS) [RFC2212] offers hard upper bounds on
+       delay to flows that conform to a traffic specification (TSpec).
+       It uses a fluid-flow model to relate the TSpec and reserved
+       bandwidth (RSpec) to variable delay.  Non-conforming packets are
+       forwarded on a best-effort basis.
+
+   2.  Controlled Load Service (CLS) [RFC2211] offers delay and packet
+       loss equivalent to that of an unloaded network to flows that
+       conform to a TSpec, but no hard bounds.  Non-conforming packets
+       are forwarded on a best-effort basis.
+
+   Intserv requires installation of state information in every
+   participating router.  Performance guarantees cannot be made unless
+   this state is present in every router along the path.  This, along
+   with RSVP processing and the need for usage-based accounting, is
+   believed to have scalability problems, particularly in the core of
+   the Internet [RFC2208].
+
+   IP Differentiated Services (Diffserv) [RFC2475] provides a "toolkit"
+   offering coarse-grained controls to aggregates of flows.  Diffserv in
+   itself does *not* provide QoS guarantees, but can be used to
+   construct services with QoS guarantees across a Diffserv domain.
+   Diffserv attempts to address the scaling issues associated with
+   Intserv by requiring state awareness only at the edge of a Diffserv
+   domain.  At the edge, packets are classified into flows, and the
+   flows are conditioned (marked, policed, or shaped) to a traffic
+   conditioning specification (TCS).  A Diffserv Codepoint (DSCP),
+   identifying a per-hop behavior (PHB), is set in each packet header.
+   The DSCP is carried in the DS-field, subsuming six bits of the former
+   Type-of-Service (ToS) byte [RFC791] of the IP header [RFC2474].   The
+   PHB denotes the forwarding behavior to be applied to the packet in
+   each node in the Diffserv domain.  Although there is a "recommended"
+   DSCP associated with each PHB, the mappings from DSCPs to PHBs are
+   defined by the DS-domain.  In fact, there can be several DSCPs
+   associated with the same PHB.  Diffserv presently defines three PHBs.
+
+   1.  The class selector PHB [RFC2474] replaces the IP precedence field
+       of the former ToS byte.  It offers relative forwarding
+       priorities.
+
+   2.  The Expedited Forwarding (EF) PHB [RFC3246] [RFC3248] guarantees
+       that packets will have a well-defined minimum departure rate
+       which, if not exceeded, ensures that the associated queues are
+       short or empty.  EF is intended to support services that offer
+       tightly-bounded loss, delay, and delay jitter.
+
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 27]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   3.  The Assured Forwarding (AF) PHB group [RFC2597] offers different
+       levels of forwarding assurance for each aggregated flow of
+       packets.  Each AF group is independently allocated forwarding
+       resources.  Packets are marked with one of three drop
+       precedences; those with the highest drop precedence are dropped
+       with lower probability than those marked with the lowest drop
+       precedence.  DSCPs are recommended for four independent AF
+       groups, although a DS domain can have more or fewer AF groups.
+
+   Ongoing work in the IETF is addressing ways to support Intserv with
+   Diffserv.  There is some belief (e.g., as expressed in [RFC2990])
+   that such an approach will allow individual flows to receive service
+   guarantees and scale to the global Internet.
+
+   The QoS guarantees that can be offered by the IP layer are a product
+   of two factors:
+
+   1.  the concatenation of the QoS guarantees offered by the subnets
+       along the path of a flow.  This implies that a subnet may wish to
+       offer multiple services (with different QoS guarantees) to the IP
+       layer, which can then determine which flows use which subnet
+       service.  To put it another way, forwarding behavior in the
+       subnet needs to be "clued" by the forwarding behavior (service or
+       PHB) at the IP layer, and
+
+   2.  the operation of a set of cooperating mechanisms, such as
+       bandwidth reservation and admission control, policy management,
+       traffic classification, traffic conditioning (marking, policing
+       and/or shaping), selective discard, queuing, and scheduling.
+       Note that support for QoS in subnets may require similar
+       mechanisms, especially when these subnets are general topology
+       subnets (e.g., ATM, frame relay, or MPLS) or shared media
+       subnets.
+
+   Many subnetwork designers face inherent tradeoffs between delay,
+   throughput, reliability, and cost.  Other subnetworks have parameters
+   that manage bandwidth, internal connection state, and the like.
+   Therefore, the following subnetwork capabilities may be desirable,
+   although some might be trivial or moot if the subnet is a dedicated
+   point-to-point link.
+
+   1.  The subnetwork should have the ability to reserve bandwidth for a
+       connection or flow and schedule packets accordingly.
+
+   2.  Bandwidth reservations should be based on a one- or two-token
+       bucket model, depending on whether the service is intended to
+       support constant-rate or bursty traffic.
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 28]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   3.  If a connection or flow does not use its reserved bandwidth at a
+       given time, the unused bandwidth should be available for other
+       flows.
+
+   4.  Packets in excess of a connection or flow's agreed rate should be
+       forwarded as best-effort or discarded, depending on the service
+       offered by the subnet to the IP layer.
+
+   5.  If a subnet contains error control mechanisms (retransmission
+       and/or FEC), it should be possible for the IP layer to influence
+       the inherent tradeoffs between uncorrected errors, packet losses,
+       and delay.  These capabilities at the subnet/IP layer service
+       boundary correspond to selection of more or less error control
+       and/or to selection of particular error control mechanisms within
+       the subnetwork.
+
+   6.  The subnet layer should know, and be able to inform the IP layer,
+       how much fixed delay and delay jitter it offers for a flow or
+       connection.  If the Intserv model is used, the delay jitter
+       component may be best expressed in terms of the TSpec/RSpec model
+       described in [RFC2212].
+
+   7.  Support of the Diffserv class selectors [RFC2474] suggests that
+       the subnet might consider mechanisms that support priorities.
+
+10.  Fairness vs Performance
+
+   Subnetwork designers should be aware of the tradeoffs between
+   fairness and efficiency inherent in many transmission scheduling
+   algorithms.  For example, many local area networks use contention
+   protocols to resolve access to a shared transmission channel.  These
+   protocols represent overhead.  While limiting the amount of data that
+   a subnet node may transmit per contention cycle helps assure timely
+   access to the channel for each subnet node, it also increases
+   contention overhead per unit of data sent.
+
+   In some mobile radio networks, capacity is limited by interference,
+   which in turn depends on average transmitter power.  Some receivers
+   may require considerably more transmitter power (generating more
+   interference and consuming more channel capacity) than others.
+
+   In each case, the scheduling algorithm designer must balance
+   competing objectives: providing a fair share of capacity to each
+   subnet node while maximizing the total capacity of the network.  One
+   approach for balancing performance and fairness is outlined in
+   [ES00].
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 29]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+11.  Delay Characteristics
+
+   The TCP sender bases its retransmission timeout (RTO) on measurements
+   of the round trip delay experienced by previous packets.  This allows
+   TCP to adapt automatically to the very wide range of delays found on
+   the Internet.  The recommended algorithms are described in [RFC2988].
+   Evaluations of TCP's retransmission timer can be found in [AP99] and
+   [LS00].
+
+   These algorithms model the delay along an Internet path as a
+   normally-distributed random variable with a slowly-varying mean and
+   standard deviation.  TCP estimates these two parameters by
+   exponentially smoothing individual delay measurements, and it sets
+   the RTO to the estimated mean delay plus some fixed number of
+   standard deviations.  (The algorithm actually uses mean deviation as
+   an approximation to standard deviation, because it is easier to
+   compute.)
+
+   The goal is to compute an RTO that is small enough to detect and
+   recover from packet losses while minimizing unnecessary ("spurious")
+   retransmissions when packets are unexpectedly delayed but not lost.
+   Although these goals conflict, the algorithm works well when the
+   delay variance along the Internet path is low, or the packet loss
+   rate is low.
+
+   If the path delay variance is high, TCP sets an RTO that is much
+   larger than the mean of the measured delays.  If the packet loss rate
+   is low, the large RTO is of little consequence, as timeouts occur
+   only rarely.  Conversely, if the path delay variance is low, then TCP
+   recovers quickly from lost packets; again, the algorithm works well.
+   However, when delay variance and the packet loss rate are both high,
+   these algorithms perform poorly, especially when the mean delay is
+   also high.
+
+   Because TCP uses returning acknowledgments as a "clock" to time the
+   transmission of additional data, excessively high delays (even if the
+   delay variance is low) also affect TCP's ability to fully utilize a
+   high-speed transmission pipe.  It also slows the recovery of lost
+   packets, even when delay variance is small.
+
+   Subnetwork designers should therefore minimize all three parameters
+   (delay, delay variance, and packet loss) as much as possible.
+
+   In many subnetworks, these parameters are inherently in conflict.
+   For example, on a mobile radio channel, the subnetwork designer can
+   use retransmission (ARQ) and/or forward error correction (FEC) to
+   trade off delay, delay variance, and packet loss in an effort to
+   improve TCP performance.  While ARQ increases delay variance, FEC
+
+
+
+Karn, et al.             Best Current Practice                 [Page 30]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   does not.  However, FEC (especially when combined with interleaving)
+   often increases mean delay, even on good channels where ARQ
+   retransmissions are not needed and ARQ would not increase either the
+   delay or the delay variance.
+
+   The tradeoffs among these error control mechanisms and their
+   interactions with TCP can be quite complex, and are the subject of
+   much ongoing research.  We therefore recommend that subnetwork
+   designers provide as much flexibility as possible in the
+   implementation of these mechanisms, and provide access to them as
+   discussed above in the section on Quality of Service.
+
+12.  Bandwidth Asymmetries
+
+   Some subnetworks may provide asymmetric bandwidth (or may cause TCP
+   packet flows to experience asymmetry in the capacity) and the
+   Internet protocol suite will generally still work fine.  However,
+   there is a case when such a scenario reduces TCP performance.  Since
+   TCP data segments are "clocked" out by returning acknowledgments, TCP
+   senders are limited by the rate at which ACKs can be returned
+   [BPK98].  Therefore, when the ratio of the available capacity of the
+   Internet path carrying the data to the bandwidth of the return path
+   of the acknowledgments is too large, the slow return of the ACKs
+   directly impacts performance.  Since ACKs are generally smaller than
+   data segments, TCP can tolerate some asymmetry, but as a general
+   rule, designers of subnetworks should be aware that subnetworks with
+   significant asymmetry can result in reduced performance, unless
+   issues are taken to mitigate this [RFC3449].
+
+   Several strategies have been identified for reducing the impact of
+   asymmetry of the network path between two TCP end hosts, e.g.,
+   [RFC3449].  These techniques attempt to reduce the number of ACKs
+   transmitted over the return path (low bandwidth channel) by changes
+   at the end host(s), and/or by modification of subnetwork packet
+   forwarding.  While these solutions may mitigate the performance
+   issues caused by asymmetric subnetworks, they do have associated cost
+   and may have other implications.  A fuller discussion of strategies
+   and their implications is provided in [RFC3449].
+
+13.  Buffering, flow and congestion control
+
+   Many subnets include multiple links with varying traffic demands and
+   possibly different transmission speeds.  At each link there must be a
+   queuing system, including buffering, scheduling, and a capability to
+   discard excess subnet packets.  These queues may also be part of a
+   subnet flow control or congestion control scheme.
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 31]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   For the purpose of this discussion, we talk about packets without
+   regard to whether they refer to a complete IP packet or a subnetwork
+   frame.  At each queue, a packet experiences a delay that depends on
+   competing traffic and the scheduling discipline, and is subjected to
+   a local discarding policy.
+
+   Some subnets may have flow or congestion control mechanisms in
+   addition to packet dropping.  Such mechanisms can operate on
+   components in the subnet layer, such as schedulers, shapers, or
+   discarders, and can affect the operation of IP forwarders at the
+   edges of the subnet.  However, with the exception of Explicit
+   Congestion Notification [RFC3168] (discussed below), IP has no way to
+   pass explicit congestion or flow control signals to TCP.
+
+   TCP traffic, especially aggregated TCP traffic, is bursty.  As a
+   result, instantaneous queue depths can vary dramatically, even in
+   nominally stable networks.  For optimal performance, packets should
+   be dropped in a controlled fashion, not just when buffer space is
+   unavailable.  How much buffer space should be supplied is still a
+   matter of debate, but as a rule of thumb, each node should have
+   enough buffering to hold one link_bandwidth*link_delay product's
+   worth of data for each TCP connection sharing the link.
+
+   This is often difficult to estimate, since it depends on parameters
+   beyond the subnetwork's control or knowledge.  Internet nodes
+   generally do not implement admission control policies, and cannot
+   limit the number of TCP connections that use them.  In general, it is
+   wise to err in favor of too much buffering rather than too little.
+   It may also be useful for subnets to incorporate mechanisms that
+   measure propagation delays to assist in buffer sizing calculations.
+
+   There is a rough consensus in the research community that active
+   queue management is important to improving fairness, link
+   utilization, and throughput [RFC2309].  Although there are questions
+   and concerns about the effectiveness of active queue management
+   (e.g., [MBDL99]), it is widely considered an improvement over tail-
+   drop discard policies.
+
+   One form of active queue management is the Random Early Detection
+   (RED) algorithm [RED93], a family of related algorithms.  In one
+   version of RED, an exponentially-weighted moving average of the queue
+   depth is maintained:
+
+      When this average queue depth is between a maximum threshold
+      max_th and a minimum threshold min_th, the probability of packets
+      that are dropped is proportional to the amount by which the
+      average queue depth exceeds min_th.
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 32]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+      When this average queue depth is equal to max_th, the drop
+      probability is equal to a configurable parameter max_p.
+
+      When this average queue depth is greater than max_th, packets are
+      always dropped.
+
+   Numerous variants on RED appear in the literature, and there are
+   other active queue management algorithms which claim various
+   advantages over RED [GM02].
+
+   With an active queue management algorithm, dropped packets become a
+   feedback signal to trigger more appropriate congestion behavior by
+   the TCPs in the end hosts.  Randomization of dropping tends to break
+   up the observed tendency of TCP windows belonging to different TCP
+   connections to become synchronized by correlated drops, and it also
+   imposes a degree of fairness on those connections that implement TCP
+   congestion avoidance properly.  Another important property of active
+   queue management algorithms is that they attempt to keep average
+   queue depths short while accommodating large short-term bursts.
+
+   Since TCP neither knows nor cares whether congestive packet loss
+   occurs at the IP layer or in a subnet, it may be advisable for
+   subnets that perform queuing and discarding to consider implementing
+   some form of active queue management.  This is especially true if
+   large aggregates of TCP connections are likely to share the same
+   queue.  However, active queue management may be less effective in the
+   case of many queues carrying smaller aggregates of TCP connections,
+   e.g., in an ATM switch that implements per-VC queuing.
+
+   Note that the performance of active queue management algorithms is
+   highly sensitive to settings of configurable parameters, and also to
+   factors such as RTT [MBB00] [FB00].
+
+   Some subnets, most notably ATM, perform segmentation and reassembly
+   at the subnetwork edges.  Care should be taken here in designing
+   discard policies.  If the subnet discards a fragment of an IP packet,
+   then the remaining fragments become an unproductive load on the
+   subnet that can markedly degrade end-to-end performance [RF95].
+   Subnetworks should therefore attempt to discard these extra fragments
+   whenever one of them must be discarded.  If the IP packet has already
+   been partially forwarded when discarding becomes necessary, then
+   every remaining fragment except the one marking the end of the IP
+   packet should also be discarded.  For ATM subnets, this specifically
+   means using Early Packet Discard and Partial Packet Discard [ATMFTM].
+
+   Some subnets include flow control mechanisms that effectively require
+   that the rate of traffic flows be shaped upon entry to the subnet.
+   One example of such a subnet mechanism is in the ATM Available Bit
+
+
+
+Karn, et al.             Best Current Practice                 [Page 33]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   rate (ABR) service category [ATMFTM].  Such flow control mechanisms
+   have the effect of making the subnet nearly lossless by pushing
+   congestion into the IP routers at the edges of the subnet.  In such a
+   case, adequate buffering and discard policies are needed in these
+   routers to deal with a subnet that appears to have varying bandwidth.
+   Whether there is a benefit in this kind of flow control is
+   controversial; there are numerous simulation and analytical studies
+   that go both ways.  It appears that some of the issues leading to
+   such different results include sensitivity to ABR parameters, use of
+   binary rather than explicit rate feedback, use (or not) of per-VC
+   queuing, and the specific ATM switch algorithms selected for the
+   study.  Anecdotally, some large networks that used IP over ABR to
+   carry TCP traffic have claimed it to be successful, but have
+   published no results.
+
+   Another possible approach to flow control in the subnet would be to
+   work with TCP Explicit Congestion Notification (ECN) semantics
+   [RFC3168] through utilizing explicit congestion indicators in subnet
+   frames.  Routers at the edges of the subnet, rather than shaping,
+   would set the explicit congestion bit in those IP packets that are
+   received in subnet frames that have an ECN indication.  Nodes in the
+   subnet would need to implement an active queue management protocol
+   that marks subnet frames instead of dropping them.
+
+   ECN is currently a proposed standard, but it is not yet widely
+   deployed.
+
+14.  Compression
+
+   Application data compression is a function that can usually be
+   omitted in the subnetwork.  The endpoints typically have more CPU and
+   memory resources to run a compression algorithm and a better
+   understanding of what is being compressed.  End-to-end compression
+   benefits every network element in the path, while subnetwork-layer
+   compression, by definition, benefits only a single subnetwork.
+
+   Data presented to the subnetwork layer may already be in a compressed
+   format (e.g., a JPEG file), compressed at the application layer
+   (e.g., the optional "gzip", "compress", and "deflate" compression in
+   HTTP/1.1 [RFC2616]), or compressed at the IP layer (the IP Payload
+   Compression Protocol [RFC3173] supports DEFLATE [RFC2394] and LZS
+   [RFC2395]).  Compression at the subnetwork edges is of no benefit for
+   any of these cases.
+
+   The subnetwork may also process data that has been encrypted by the
+   application (OpenPGP [RFC2440] or S/MIME [RFC2633]), just above TCP
+   (SSL, TLS [RFC2246]), or just above IP (IPsec ESP [RFC2406]).
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 34]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   Ciphers generate high-entropy bit streams lacking any patterns that
+   can be exploited by a compression algorithm.
+
+   However, much data is still transmitted uncompressed over the
+   Internet, so subnetwork compression may be beneficial.  Any
+   subnetwork compression algorithm must not expand uncompressible data,
+   e.g., data that has already been compressed or encrypted.
+
+   We make a strong recommendation that subnetworks operating at low
+   speed or with small MTUs compress IP and transport-level headers (TCP
+   and UDP) using several header compression schemes developed within
+   the IETF [RFC3150].  An uncompressed 40-byte TCP/IP header takes
+   about 33 milliseconds to send at 9600 bps.  "VJ" TCP/IP header
+   compression [RFC1144] compresses most headers to 3-5 bytes, reducing
+   transmission time to several milliseconds on dialup modem links.
+   This is especially beneficial for small, latency-sensitive packets in
+   interactive sessions.
+
+   Similarly, RTP compression schemes, such as CRTP [RFC2508] and ROHC
+   [RFC3095], compress most IP/UDP/RTP headers to 1-4 bytes.  The
+   resulting savings are especially significant when audio packets are
+   kept small to minimize store-and-forward latency.
+
+   Designers should consider the effect of the subnetwork error rate on
+   the performance of header compression.  TCP ordinarily recovers from
+   lost packets by retransmitting only those packets that were actually
+   lost; packets arriving correctly after a packet loss are kept on a
+   resequencing queue and do not need to be retransmitted.  In VJ TCP/IP
+   [RFC1144] header compression, however, the receiver cannot explicitly
+   notify a sender of data corruption and subsequent loss of
+   synchronization between compressor and decompressor.  It relies
+   instead on TCP retransmission to re-synchronize the decompressor.
+   After a packet is lost, the decompressor must discard every
+   subsequent packet, even if the subnetwork makes no further errors,
+   until the sending TCP retransmits to re-synchronize the decompressor.
+   This effect can substantially magnify the effect of subnetwork packet
+   losses if the sending TCP window is large, as it will often be on a
+   path with a large bandwidth*delay product [LRKOJ99].
+
+   Alternate header compression schemes, such as those described in
+   [RFC2507], include an explicit request for retransmission of an
+   uncompressed packet to allow decompressor resynchronization without
+   waiting for a TCP retransmission.  However, these schemes are not yet
+   in widespread use.
+
+   Both TCP header compression schemes do not compress widely-used TCP
+   options such as selective acknowledgements (SACK).  Both fail to
+   compress TCP traffic that makes use of explicit congestion
+
+
+
+Karn, et al.             Best Current Practice                 [Page 35]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   notification (ECN).  Work is under way in the IETF ROHC WG to address
+   these shortcomings in a ROHC header compression scheme for TCP
+   [RFC3095] [RFC3096].
+
+   The subnetwork error rate also is important for RTP header
+   compression.  CRTP uses delta encoding, so a packet loss on the link
+   causes uncertainty about the subsequent packets, which often must be
+   discarded until the decompressor has notified the compressor and the
+   compressor has sent re-synchronizing information.  This typically
+   takes slightly more than the end-to-end path round-trip time.  For
+   links that combine significant error rates with latencies that
+   require multiple packets to be in flight at a time, this leads to
+   significant error propagation, i.e., subsequent losses caused by an
+   initial loss.
+
+   For links that are both high-latency (multiple packets in flight from
+   a typical RTP stream) and error-prone, RTP ROHC provides a more
+   robust way of RTP header compression, at a cost of higher complexity
+   at the compressor and decompressor.  For example, within a talk
+   spurt, only extended losses of (depending on the mode chosen) 12-64
+   packets typically cause error propagation.
+
+15.  Packet Reordering
+
+   The Internet architecture does not guarantee that packets will arrive
+   in the same order in which they were originally transmitted;
+   transport protocols like TCP must take this into account.
+
+   However, reordering does come at a cost with TCP as it is currently
+   defined.  Because TCP returns a cumulative acknowledgment (ACK)
+   indicating the last in-order segment that has arrived, out-of-order
+   segments cause a TCP receiver to transmit a duplicate acknowledgment.
+   When the TCP sender notices three duplicate acknowledgments, it
+   assumes that a segment was dropped by the network and uses the fast
+   retransmit algorithm [Jac90] [RFC2581] to resend the segment.  In
+   addition, the congestion window is reduced by half, effectively
+   halving TCP's sending rate.  If a subnetwork reorders segments
+   significantly such that three duplicate ACKs are generated, the TCP
+   sender needlessly reduces the congestion window and performance
+   suffers.
+
+   Packet reordering frequently occurs in parts of the Internet, and it
+   seems to be difficult or impossible to eliminate [BPS99].  For this
+   reason, research on improving TCP's behavior in the face of packet
+   reordering [LK00] [BA02] has begun.
+
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 36]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   [BPS99] cites reasons why it may even be undesirable to eliminate
+   reordering.  There are situations where average packet latency can be
+   reduced, link efficiency can be increased, and/or reliability can be
+   improved if reordering is permitted.  Examples include certain high
+   speed switches within the Internet backbone and the parallel links
+   used over many Internet paths for load splitting and redundancy.
+
+   This suggests that subnetwork implementers should try to avoid packet
+   reordering whenever possible, but not if doing so compromises
+   efficiency, impairs reliability, or increases average packet delay.
+
+   Note that every header compression scheme currently standardized for
+   the Internet requires in-order packet delivery on the link between
+   compressor and decompressor.  PPP is frequently used to carry
+   compressed TCP/IP packets; since it was originally designed for
+   point-to-point and dialup links, it is assumed to provide in-order
+   delivery.  For this reason, subnetwork implementers who provide PPP
+   interfaces to VPNs and other more complex subnetworks, must also
+   maintain in-order delivery of PPP frames.
+
+16.  Mobility
+
+   Internet users are increasingly mobile.  Not only are many Internet
+   nodes laptop computers, but pocket organizers and mobile embedded
+   systems are also becoming nodes on the Internet.  These nodes may
+   connect to many different access points on the Internet over time,
+   and they expect this to be largely transparent to their activities.
+   Except when they are not connected to the Internet at all, and for
+   performance differences when they are connected, they expect that
+   everything will "just work" regardless of their current Internet
+   attachment point or local subnetwork technology.
+
+   Changing a host's Internet attachment point involves one or more of
+   the following steps.
+
+   First, if use of the local subnetwork is restricted, the user's
+   credentials must be verified and access granted.  There are many ways
+   to do this.  A trivial example would be an "Internet cafe" that
+   grants physical access to the subnetwork for a fee.  Subnetworks may
+   implement technical access controls of their own; one example is IEEE
+   802.11 Wireless Equivalent Privacy [IEEE80211].  It is common
+   practice for both cellular telephone and Internet service providers
+   (ISPs) to agree to serve one anothers' users; RADIUS [RFC2865] is the
+   standard method for ISPs to exchange authorization information.
+
+   Second, the host may have to be reconfigured with IP parameters
+   appropriate for the local subnetwork.  This usually includes setting
+   an IP address, default router, and domain name system (DNS) servers.
+
+
+
+Karn, et al.             Best Current Practice                 [Page 37]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   On multiple-access networks, the Dynamic Host Configuration Protocol
+   (DHCP) [RFC2131] is almost universally used for this purpose.  On PPP
+   links, these functions are performed by the IP Control Protocol
+   (IPCP) [RFC1332].
+
+   Third, traffic destined for the mobile host must be routed to its
+   current location.  This roaming function is the most common meaning
+   of the term "Internet mobility".
+
+   Internet mobility can be provided at any of several layers in the
+   Internet protocol stack, and there is ongoing debate as to which is
+   the most appropriate and efficient.  Mobility is already a feature of
+   certain application layer protocols; the Post Office Protocol (POP)
+   [RFC1939] and the Internet Message Access Protocol (IMAP) [RFC3501]
+   were created specifically to provide mobility in the receipt of
+   electronic mail.
+
+   Mobility can also be provided at the IP layer [RFC3344].  This
+   mechanism provides greater transparency, viz., IP addresses that
+   remain fixed as the nodes move, but at the cost of potentially
+   significant network overhead and increased delay because of the sub-
+   optimal network routing and tunneling involved.
+
+   Some subnetworks may provide internal mobility, transparent to IP, as
+   a feature of their own internal routing mechanisms.  To the extent
+   that these simplify routing at the IP layer, reduce the need for
+   mechanisms like Mobile IP, or exploit mechanisms unique to the
+   subnetwork, this is generally desirable.  This is especially true
+   when the subnetwork covers a relatively small geographic area and the
+   users move rapidly between the attachment points within that area.
+   Examples of internal mobility schemes include Ethernet switching and
+   intra-system handoff in cellular telephony.
+
+   However, if the subnetwork is physically large and connects to other
+   parts of the Internet at multiple geographic points, care should be
+   taken to optimize the wide-area routing of packets between nodes on
+   the external Internet and nodes on the subnet.  This is generally
+   done with "nearest exit" routing strategies.  Because a given
+   subnetwork may be unaware of the actual physical location of a
+   destination on another subnetwork, it simply routes packets bound for
+   the other subnetwork to the nearest router between the two.  This
+   implies some awareness of IP addressing and routing within the
+   subnetwork.  The subnetwork may wish to use IP routing internally for
+   wide area routing and restrict subnetwork-specific routing to
+   constrained geographic areas where the effects of suboptimal routing
+   are minimized.
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 38]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+17.  Routing
+
+   Subnetworks connecting more than two systems must provide their own
+   internal Layer-2 forwarding mechanisms, either implicitly (e.g.,
+   broadcast) or explicitly (e.g., switched).  Since routing is the
+   major function of the Internet layer, the question naturally arises
+   as to the interaction between routing at the Internet layer and
+   routing in the subnet, and proper division of function between the
+   two.
+
+   Layer-2 subnetworks can be point-to-point, connecting two systems, or
+   multipoint.  Multipoint subnetworks can be broadcast (e.g., shared
+   media or emulated) or non-broadcast.  Generally, IP considers
+   multipoint subnetworks as broadcast, with shared-medium Ethernet as
+   the canonical (and historical) example, and point-to-point
+   subnetworks as a degenerate case.  Non-broadcast subnetworks may
+   require additional mechanisms, e.g., above IP at the routing layer
+   [RFC2328].
+
+   IP is ignorant of the topology of the subnetwork layer.  In
+   particular, reconfiguration of subnetwork paths is not tracked by the
+   IP layer.  IP is only affected by whether it can send/receive packets
+   sent to the remotely connected systems via the subnetwork interface
+   (i.e., the reachability from one router to another).  IP further
+   considers that subnetworks are largely static -- that both their
+   membership and existence are stable at routing timescales (tens of
+   seconds); changes to these are considered re-provisioning, rather
+   than routing.
+
+   Routing functionality in a subnetwork is related to addressing in
+   that subnetwork.  Resolution of addresses on subnetwork links is
+   required for forwarding IP packets across links (e.g., ARP for IPv4,
+   or ND for IPv6).  There is unlikely to be direct interaction between
+   subnetwork routing and IP routing.  Where broadcast is provided or
+   explicitly emulated, address resolution can be used directly; where
+   not provided, the link layer routing may interface to a protocol for
+   resolution, e.g., to the Next-Hop Resolution Protocol [RFC2322] to
+   provide context-dependent address resolution capabilities.
+
+   Subnetwork routing can either complement or compete with IP routing.
+   It complements IP when a subnetwork encapsulates its internal
+   routing, and where the effects of that routing are not visible at the
+   IP layer.  However, if different paths in the subnetwork have
+   characteristics that affect IP routing, it can affect or even inhibit
+   the convergence of IP routing.
+
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 39]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   Routing protocols generally consider Layer-2 subnetworks, i.e., with
+   subnet masks and no intermediate IP hops, to have uniform routing
+   metrics to all members.  Routing can break when a link's
+   characteristics do not match the routing metric, in this case, e.g.,
+   when some member pairs have different path characteristics.  Consider
+   a virtual Ethernet subnetwork that includes both nearby (sub-
+   millisecond latency) and remote (100's of milliseconds away) systems.
+   Presenting that group as a single subnetwork means that some routing
+   protocols will assume that all pairs have the same delay, and that
+   that delay is small.  Because this is not the case, the routing
+   tables constructed may be suboptimal or may even fail to converge.
+
+   When a subnetwork is used for transit between a set of routers, it
+   conventionally provides the equivalent of a full mesh of point-to-
+   point links.  Simplicity of the internal subnet structure can be used
+   (e.g., via NHRP [RFC2332]) to reduce the size of address resolution
+   tables, but routing exchanges will continue to reflect the full mesh
+   they emulate.  In general, subnetworks should not be used as a
+   transit among a set of routers where routing protocols would break if
+   a full mesh of equivalent point-to-point links were used.
+
+   Some subnetworks have special features that allow the use of more
+   effective or responsive routing mechanisms that cannot be implemented
+   in IP because of its need for generality.  One example is the self-
+   learning bridge algorithm widely used in Ethernet networks.  Learning
+   bridges perform Layer-2 subnetwork forwarding, avoiding the need for
+   dynamic routing at each subnetwork hop.  Another is the "handoff"
+   mechanism in cellular telephone networks, particularly the "soft
+   handoff" scheme in IS-95 CDMA.
+
+   Subnetworks that cover large geographic areas or include links of
+   widely-varying capabilities should be avoided.  IP routing generally
+   considers all multipoint subnets equivalent to a local, shared-medium
+   link with uniform metrics between any pair of systems, and ignores
+   internal subnetwork topology.  Where a subnetwork diverges from that
+   assumption, it is the obligation of subnetwork designers to provide
+   compensating mechanisms.  Not doing so can affect the scalability and
+   convergence of IP routing, as noted above.
+
+   The subnetwork designer who decides to implement internal routing
+   should consider whether a custom routing algorithm is warranted, or
+   if an existing Internet routing algorithm or protocol may suffice.
+   The designer should consider whether this decision is to reduce the
+   address resolution table size (possible, but with additional protocol
+   support required), or is trying to reduce routing table complexity.
+   The latter may be better achieved by partitioning the subnetwork,
+   either physically or logically, and using network-layer protocols to
+   support partitioning (e.g., AS's in BGP).  Protocols and routing
+
+
+
+Karn, et al.             Best Current Practice                 [Page 40]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   algorithms can be notoriously subtle, complex, and difficult to
+   implement correctly.  Much work can be avoided if existing protocols
+   or implementations can be readily reused.
+
+18.  Security Considerations
+
+   Security has become a high priority in the design and operation of
+   the Internet.  The Internet is vast, and countless organizations and
+   individuals own and operate its various components.  A consensus has
+   emerged for what might be called a "security placement principle": a
+   security mechanism is most effective when it is placed as close as
+   possible to, and under the direct control of the owner of the asset
+   that it protects.
+
+   A corollary of this principle is that end-to-end security (e.g.,
+   confidentiality, authentication, integrity, and access control)
+   cannot be ensured with subnetwork security mechanisms.  Not only are
+   end-to-end security mechanisms much more closely associated with the
+   end-user assets they protect, they are also much more comprehensive.
+   For example, end-to-end security mechanisms cover gaps that can
+   appear when otherwise good subnetwork mechanisms are concatenated.
+   This is an important application of the end-to-end principle [SRC81].
+
+   Several security mechanisms that can be used end-to-end have already
+   been deployed in the Internet and are enjoying increasing use.  The
+   most important are the Secure Sockets Layer (SSL) [SSL2] [SSL3] and
+   TLS [RFC2246] primarily used to protect web commerce, Pretty Good
+   Privacy (PGP) [RFC1991] and S/MIME [RFCs-2630-2634], primarily used
+   to protect and authenticate email and software distributions, the
+   Secure Shell (SSH), used for secure remote access and file transfer,
+   and IPsec [RFC2401], a general purpose encryption and authentication
+   mechanism that sits just above IP and can be used by any IP
+   application.  (IPsec can actually be used either on an end-to-end
+   basis or between security gateways that do not include either or both
+   end systems.)
+
+   Nonetheless, end-to-end security mechanisms are not used as widely as
+   might be desired.  However, the group could not reach consensus on
+   whether subnetwork designers should be actively encouraged to
+   implement mechanisms to protect user data.
+
+   The clear consensus of the working group held that subnetwork
+   security mechanisms, especially when weak or incorrectly implemented
+   [BGW01], may actually be counterproductive.  The argument is that
+   subnetwork security mechanisms can lull end users into a false sense
+   of security, diminish the incentive to deploy effective end-to-end
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 41]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   mechanisms, and encourage "risky" uses of the Internet that would not
+   be made if users understood the inherent limits of subnetwork
+   security mechanisms.
+
+   The other point of view encourages subnetwork security on the
+   principle that it is better than the default situation, which all too
+   often is no security at all.  Users of especially vulnerable subnets
+   (such as consumers who have wireless home networks and/or shared
+   media Internet access) often have control over at most one endpoint
+   -- usually a client -- and therefore cannot enforce the use of end-
+   to-end mechanisms.  However, subnet security can be entirely adequate
+   for protecting low-valued assets against the most likely threats.  In
+   any event, subnet mechanisms do not preclude the use of end-to-end
+   mechanisms, which are typically used to protect highly-valued assets.
+   This viewpoint recognizes that many security policies implicitly
+   assume that the entire end-to-end path is composed of a series of
+   concatenated links that are nominally physically secured.  That is,
+   these policies assume that all endpoints of all links are trusted,
+   and that access to the physical medium by attackers is difficult.  To
+   meet the assumptions of such policies, explicit mechanisms are needed
+   for links (especially shared medium links) that lack physical
+   protection.  This, for example, is the rationale that underlies Wired
+   Equivalent Privacy (WEP) in the IEEE 802.11 [IEEE80211] wireless LAN
+   standard, and the Baseline Privacy Interface in the DOCSIS [DOCSIS1]
+   [DOCSIS2] data over cable television networks standards.
+
+   We therefore recommend that subnetwork designers who choose to
+   implement security mechanisms to protect user data be as candid as
+   possible with the details of such security mechanisms and the
+   inherent limits of even the most secure mechanisms when implemented
+   in a subnetwork rather than on an end-to-end basis.
+
+   In keeping with the "placement principle", a clear consensus exists
+   for another subnetwork security role: the protection of the
+   subnetwork itself.  Possible threats to subnetwork assets include
+   theft of service and denial of service; shared media subnets tend to
+   be especially vulnerable to such attacks.  In some cases, mechanisms
+   that protect subnet assets can also improve (but cannot ensure) end-
+   to-end security.
+
+   One security service can be provided by the subnetwork that will aid
+   in the solution of an overall Internet problem: subnetwork security
+   should provide a mechanism to authenticate the source of a subnetwork
+   frame.  This function is missing in some current protocols, e.g., the
+   use of ARP [RFC826] to associate an IPv4 address with a MAC address.
+   The IPv6 Neighbor Discovery (ND) [RFC2461] performs a similar
+   function.
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 42]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   There are well-known security flaws with this address resolution
+   mechanism [Wilbur89].  However, the inclusion of subnetwork frame
+   source authentication will permit a secure subnetwork address.
+
+   Another potential role for subnetwork security is to protect users
+   against traffic analysis, i.e., identifying the communicating parties
+   and determining their communication patterns and volumes even when
+   their actual contents are protected by strong end-to-end security
+   mechanisms.  Lower-layer security can be more effective against
+   traffic analysis due to its inherent ability to aggregate the
+   communications of multiple parties sharing the same physical
+   facilities while obscuring higher-layer protocol information that
+   indicates specific end points, such as IP addresses and TCP/UDP port
+   numbers.
+
+   However, traffic analysis is a notoriously subtle and difficult
+   threat to understand and defeat, far more so than threats to
+   confidentiality and integrity.  We therefore urge extreme care in the
+   design of subnetwork security mechanisms specifically intended to
+   thwart traffic analysis.
+
+   Subnetwork designers must keep in mind that design and implementation
+   for security is difficult [Schneier00].  [Schneier95] describes
+   protocols and algorithms which are considered well-understood and
+   believed to be sound.
+
+   Poor design process, subtle design errors and flawed implementation
+   can result in gaping vulnerabilities.  In recent years, a number of
+   subnet standards have had problems exposed.  The following are
+   examples of mistakes that have been made:
+
+   1.  Use of weak and untested algorithms [Crypto9912] [BGW01].  For a
+       variety of reasons, algorithms were chosen which had subtle
+       flaws, making them vulnerable to a variety of attacks.
+
+   2.  Use of "security by obscurity" [Schneier00] [Crypto9912].  One
+       common mistake is to assume that keeping cryptographic algorithms
+       secret makes them more secure.  This is intuitive, but wrong.
+       Full public disclosure early in the design process attracts peer
+       review by knowledgeable cryptographers.  Exposure of flaws by
+       this review far outweighs any imagined benefit from forcing
+       attackers to reverse engineer security algorithms.
+
+   3.  Inclusion of trapdoors [Schneier00] [Crypto9912].  Trapdoors are
+       flaws surreptitiously left in an algorithm to allow it to be
+       broken.  This might be done to recover lost keys or to permit
+       surreptitious access by governmental agencies.  Trapdoors can be
+       discovered and exploited by malicious attackers.
+
+
+
+Karn, et al.             Best Current Practice                 [Page 43]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   4.  Sending passwords or other identifying information as clear text.
+       For many years, analog cellular telephones could be cloned and
+       used to steal service.  The cloners merely eavesdropped on the
+       registration protocols that exchanged everything in clear text.
+
+   5.  Keys which are common to all systems on a subnet [BGW01].
+
+   6.  Incorrect use of a sound mechanism.  For example [BGW01], one
+       subnet standard includes an initialization vector which is poorly
+       designed and poorly specified.  A determined attacker can easily
+       recover multiple ciphertexts encrypted with the same key stream
+       and perform statistical attacks to decipher them.
+
+   7.  Identifying information sent in clear text that can be resolved
+       to an individual, identifiable device.  This creates a
+       vulnerability to attacks targeted to that device (or its owner).
+
+   8.  Inability to renew and revoke shared secret information.
+
+   9.  Insufficient key length.
+
+   10. Failure to address "man-in-the-middle" attacks, e.g., with mutual
+       authentication.
+
+   11. Failure to provide a form of replay detection, e.g., to prevent a
+       receiver from accepting packets from an attacker that simply
+       resends previously captured network traffic.
+
+   12. Failure to provide integrity mechanisms when providing
+       confidentiality schemes [Bel98].
+
+   This list is by no means comprehensive.  Design problems are
+   difficult to avoid, but expert review is generally invaluable in
+   avoiding problems.
+
+   In addition, well-designed security protocols can be compromised by
+   implementation defects.  Examples of such defects include use of
+   predictable pseudo-random numbers [RFC1750], vulnerability to buffer
+   overflow attacks due to unsafe use of certain I/O system calls
+   [WFBA2000], and inadvertent exposure of secret data.
+
+19.  Contributors
+
+   This document represents a consensus of the members of the IETF
+   Performance Implications of Link Characteristics (PILC) working
+   group.
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 44]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   This document would not have been possible without the contributions
+   of a great number of people in the Performance Implications of Link
+   Characteristics Working Group.  In particular, the following people
+   provided major contributions of text, editing, and advice on this
+   document: Mark Allman provided the final editing to complete this
+   document.  Carsten Bormann provided text on robust header
+   compression.  Gorry Fairhurst provided text on broadcast and
+   multicast issues, routing,  and many valuable comments on the entire
+   document.  Aaron Falk provided text on bandwidth on demand.  Dan
+   Grossman provided text on many facets of the document.  Reiner Ludwig
+   provided thorough document review and text on TCP vs. Link-Layer
+   Retransmission.  Jamshid Mahdavi provided text on TCP performance
+   calculations.  Saverio Mascolo provided feedback on the document.
+   Gabriel Montenegro provided feedback on the document.  Marie-Jose
+   Montpetit provided text on bandwidth on demand.  Joe Touch provided
+   text on multicast, broadcast, and routing, and Lloyd Wood provided
+   many valuable comments on versions of the document.
+
+20.  Informative References
+
+   References of the form RFCnnnn are Internet Request for Comments
+   (RFC) documents available online at www.rfc-editor.org.
+
+   [802.1D]      Information Technology Telecommunications and
+                 information exchange between systems Local and
+                 metropolitan area networks, Common specifications Media
+                 access control (MAC) bridges, IEEE 802.1D, 1998.  ISO
+                 15802-3.
+
+   [802.1p]      IEEE, 802.1p, Standard for Local and Metropolitan Area
+                 Networks - Supplement to Media Access Control (MAC)
+                 Bridges: Traffic Class Expediting and Multicast.
+
+   [AP99]        Allman, M. and V. Paxson, On Estimating End-to-End
+                 Network Path Properties, In Proceedings of ACM SIGCOMM
+                 99.
+
+   [AR02]        Acar, G. and C. Rosenberg, Weighted Fair Bandwidth-on-
+                 Demand (WFBoD) for Geo-Stationary Satellite Networks
+                 with On-Board Processing, Computer Networks, 39(1),
+                 2002.
+
+   [ATMFTM]      The ATM Forum, "Traffic Management Specification,
+                 Version 4.0", April 1996, document af-tm-0056.000.
+                 http://www.atmforum.com/
+
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 45]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   [BA02]        Blanton, E. and M. Allman, On Making TCP More Robust to
+                 Packet Reordering. ACM Computer Communication Review,
+                 32(1), January 2002.
+
+   [Bel98]       Bellovin, S., "Cryptography and the Internet", in
+                 Proceedings of CRYPTO '98, August 1998.
+                 http://www.research.att.com/~smb/papers/inet-crypto.pdf
+
+   [BGW01]       Borisov, N., Goldberg, I. and D. Wagner, "Intercepting
+                 Mobile Communications: The Insecurity of 802.11," In
+                 Proceedings of ACM MobiCom, July 2001.
+
+   [BPK98]       Balakrishnan, H., Padmanabhan, V. and R. Katz.  "The
+                 Effects of Asymmetry on TCP Performance."  ACM Mobile
+                 Networks and Applications (MONET), 1998.
+
+   [BPS99]       Bennet,, J.C.R., Partridge, C. and N. Shectman, "Packet
+                 Reordering is Not Pathological Network Behavior",
+                 IEEE/ACM Transactions on Networking, Vol. 7, No. 6,
+                 December 1999.
+
+   [CGMP]        Farinacci D., Tweedly A. and T. Speakman, "Cisco Group
+                 Management Protocol (CGMP)", 1996/1997.
+                 ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt
+
+   [Crypto9912]  Schneier, B., "European Cellular Encryption Algorithms"
+                 Crypto-Gram, December 15, 1999.
+                 http://www.counterpane.com
+
+   [DIX82]       Digital Equipment Corp, Intel Corp, Xerox Corp,
+                 Ethernet Local Area Network Specification Version 2.0,
+                 November 1982.
+
+   [DOCSIS1]     Data-Over-Cable Service Interface Specifications, Radio
+                 Frequency Interface Specification 1.0, SP-RFI-I05-
+                 991105, November 1999, Cable Television Laboratories,
+                 Inc.
+
+   [DOCSIS2]     Data-Over-Cable Service Interface Specifications, Radio
+                 Frequency Interface Specification 1.1, SP-RFIv1.1-I05-
+                 000714, July 2000, Cable Television Laboratories, Inc.
+
+   [DOCSIS3]     Lai, W.S., "DOCSIS-Based Cable Networks: Impact of
+                 Large Data Packets on Upstream Capacity", 14th ITC
+                 Specialists Seminar on Access Networks and Systems,
+                 Barcelona, Spain, April 25-27, 2001.
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 46]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   [EN301192]    ETSI, European Broadcasting Union, Digital Video
+                 Broadcasting (DVB); DVB Specification for Data
+                 Broadcasting, European Standard (Telecommunications
+                 Series)  EN 301 192 v1.2.1(1999-06).
+
+   [ES00]        Eckhardt, D. and P. Steenkiste, "Effort-limited Fair
+                 (ELF) Scheduling for Wireless Networks, Proceedings of
+                 IEEE Infocom 2000.
+
+   [FB00]        Firoiu V. and M. Borden, "A Study of Active Queue
+                 Management for Congestion Control" to appear in Infocom
+                 2000.
+
+   [GM02]        Grieco1, L. and S. Mascolo, "TCP Westwood and Easy RED
+                 to Improve Fairness in High-Speed Networks",
+                 Proceedings of the 7th International Workshop on
+                 Protocols for High-Speed Networks, April 2002.
+
+   [IEEE8023]    IEEE 802.3 CSMA/CD Access Method.
+                 http://standards.ieee.org/
+
+   [IEEE80211]   IEEE 802.11 Wireless LAN standard.
+                 http://standards.ieee.org/
+
+   [ISO3309]     ISO/IEC 3309:1991(E), "Information Technology -
+                 Telecommunications and information exchange between
+                 systems - High-level data link control (HDLC)
+                 procedures - Frame structure", International
+                 Organization For Standardization, Fourth edition 1991-
+                 06-01.
+
+   [ISO13818]    ISO/IEC, ISO/IEC 13818-1:2000(E)  Information
+                 Technology - Generic coding of moving pictures and
+                 associated audio information:  Systems, Second edition,
+                 2000-12-01 International Organization for
+                 Standardization and International Electrotechnical
+                 Commission.
+
+   [ITU-I363]    ITU-T I.363.5 B-ISDN ATM Adaptation Layer Specification
+                 Type AAL5, International Standards Organisation (ISO),
+                 1996.
+
+   [Jac90]       Jacobson, V., Modified TCP Congestion Avoidance
+                 Algorithm.  Email to the end2end-interest mailing list,
+                 April 1990.
+                 ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 47]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   [KY02]        Khafizov, F. and M. Yavuz, Running TCP Over IS-2000,
+                 Proceedings of IEEE ICC, 2002.
+
+   [LK00]        Ludwig, R. and R. H. Katz, "The Eifel Algorithm: Making
+                 TCP Robust Against Spurious Retransmissions", ACM
+                 Computer Communication Review, Vol. 30, No. 1, January
+                 2000.
+
+   [LKJK02]      Ludwig, R., Konrad, A., Joseph, A. D. and R. H. Katz,
+                 "Optimizing the End-to-End Performance of Reliable
+                 Flows over Wireless Links", Kluwer/ACM Wireless
+                 Networks Journal, Vol. 8, Nos. 2/3, pp. 289-299,
+                 March-May 2002.
+
+   [LRKOJ99]     Ludwig, R., Rathonyi, B., Konrad, A., Oden, K. and A.
+                 Joseph, Multi-Layer Tracing of TCP over a Reliable
+                 Wireless Link, pp. 144-154, In Proceedings of ACM
+                 SIGMETRICS 99.
+
+   [LS00]        Ludwig, R. and K. Sklower, The Eifel Retransmission
+                 Timer, ACM Computer Communication Review, Vol. 30, No.
+                 3, July 2000.
+
+   [MAGMA-PROXY] Fenner, B., He, H., Haberman, B. and H. Sandick,
+                 "IGMP/MLD-based Multicast Forwarding ("IGMP/MLD
+                 Proxying")", Work in Progress.
+
+   [MAGMA-SNOOP] Christensen, M., Kimball, K. and F. Solensky,
+                 "Considerations for IGMP and MLD Snooping Switches",
+                 Work in Progress.
+
+   [MBB00]       May, M., Bonald, T. and J-C. Bolot, "Analytic
+                 Evaluation of RED Performance", INFOCOM 2000.
+
+   [MBDL99]      May, M., Bolot, J., Diot, C. and B. Lyles, "Reasons not
+                 to deploy RED", Proc. of 7th. International Workshop on
+                 Quality of Service (IWQoS'99), June 1999.
+
+   [MSMO97]      Mathis, M., Semke, J., Mahdavi, J. and T. Ott, "The
+                 Macroscopic Behavior of the TCP Congestion Avoidance
+                 Algorithm", Computer Communication Review, Vol. 27,
+                 number 3, July 1997.
+
+   [MYR95]       Boden, N., Cohen, D., Felderman, R., Kulawik, A.,
+                 Seitz, C., et al.  MYRINET: A Gigabit per Second Local
+                 Area Network, IEEE-Micro, Vol. 15, No.1, February 1995,
+                 pp. 29-36.
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 48]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   [PFTK98]      Padhye, J., Firoiu, V., Towsley, D. and J. Kurose,
+                 "Modeling TCP Throughput: a Simple Model and its
+                 Empirical Validation", UMASS CMPSCI Tech Report TR98-
+                 008, Feb. 1998.
+
+   [RED93]       Floyd, S. and V. Jacobson, "Random Early Detection
+                 gateways for Congestion Avoidance", IEEE/ACM
+                 Transactions in Networking, Vol. 1 No. 4, August 1993.
+                 http://www.aciri.org/floyd/papers/red/red.html
+
+   [RF95]        Romanow, A. and S. Floyd, "Dynamics of TCP Traffic over
+                 ATM Networks".  IEEE Journal of Selected Areas in
+                 Communication, Vol.13 No.  4, May 1995, p. 633-641.
+
+   [RFC791]      Postel, J., "Internet Protocol", STD 5, RFC 791,
+                 September 1981.
+
+   [RFC793]      Postel, J., "Transmission Control Protocol", STD 7, RFC
+                 793, September 1981.
+
+   [RFC768]      Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+                 August 1980.
+
+   [RFC826]      Plummer, D.C., "Ethernet Address Resolution Protocol:
+                 Or converting network protocol addresses to 48-bit
+                 Ethernet address for transmission on Ethernet
+                 hardware", STD 37, RFC 826, November 1982.
+
+   [RFC1071]     Braden, R., Borman, D. and C. Partridge, "Computing the
+                 Internet checksum", RFC 1071, September 1988.
+
+   [RFC1112]     Deering, S., "Host Extensions for IP Multicasting", STD
+                 5, RFC 1112, August 1989.
+
+   [RFC1144]     Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
+                 Serial Links", RFC 1144, February 1990.
+
+   [RFC1191]     Mogul, J. and S. Deering, "Path MTU Discovery", RFC
+                 1191, November 1990.
+
+   [RFC1332]     McGregor, C., "The PPP Internet Protocol Control
+                 Protocol (IPCP)", RFC 1332, May 1992.
+
+   [RFC1435]     Knowles, S., "IESG Advice from Experience with Path MTU
+                 Discovery", RFC 1435, March 1993.
+
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 49]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   [RFC1633]     Braden, R., Clark, D. and S. Shenker, "Integrated
+                 Services in the Internet Architecture: an Overview",
+                 RFC 1633, June 1994.
+
+   [RFC1661]     Simpson, W., "The Point-to-Point Protocol (PPP)", STD
+                 51, RFC 1661, July 1994.
+
+   [RFC1662]     Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51,
+                 RFC 1662, July 1994.
+
+   [RFC1750]     Eastlake 3rd, D., Crocker, S. and J. Schiller,
+                 "Randomness Recommendations for Security", RFC 1750,
+                 December 1994.
+
+   [RFC1812]     Baker, F., Ed., "Requirements for IP Version 4
+                 Routers", RFC 1812, June 1995.
+
+   [RFC1939]     Myers, J. and M. Rose, "Post Office Protocol - Version
+                 3", STD 53, RFC 1939, May 1996.
+
+   [RFC1981]     McCann, J., Deering, S. and J. Mogul, "Path MTU
+                 Discovery for IP version 6", RFC 1981, August 1996.
+
+   [RFC1991]     Atkins, D., Stallings, W. and P. Zimmermann, "PGP
+                 Message Exchange Formats", RFC 1991, August 1996.
+
+   [RFC2018]     Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
+                 Selective Acknowledgement Options", RFC 2018, October
+                 1996.
+
+   [RFC2131]     Droms, R., "Dynamic Host Configuration Protocol", RFC
+                 2131, March 1997.
+
+   [RFC2205]     Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and
+                 S. Jamin, "Resource ReSerVation Protocol (RSVP) --
+                 Version 1 Functional Specification", RFC 2205,
+                 September 1997.
+
+   [RFC2208]     Mankin, A., Baker, F., Braden, B., Bradner, S., O`Dell,
+                 M., Romanow, A., Weinrib, A. and L. Zhang, "Resource
+                 ReSerVation Protocol (RSVP) -- Version 1 Applicability
+                 Statement Some Guidelines on Deployment", RFC 2208,
+                 September 1997.
+
+   [RFC2210]     Wroclawski, J., "The Use of RSVP with IETF Integrated
+                 Services", RFC 2210, September 1997.
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 50]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   [RFC2211]     Wroclawski, J., "Specification of the Controlled-Load
+                 Network Element Service", RFC 2211, September 1997.
+
+   [RFC2212]     Shenker, S., Partridge, C. and R. Guerin,
+                 "Specification of Guaranteed Quality of Service", RFC
+                 2212, September 1997.
+
+   [RFC2246]     Dierks, T. and C. Allen, "The TLS Protocol Version
+                 1.0", RFC 2246, January 1999.
+
+   [RFC2309]     Braden, B., Clark, D., Crowcroft, J., Davie, B.,
+                 Deering, S., Estrin, D., Floyd, S., Jacobson, V.,
+                 Minshall, G., Partridge, C., Peterson, L.,
+                 Ramakrishnan, K., Shenker, S., Wroclawski, J. and L.
+                 Zhang, "Recommendations on Queue Management and
+                 Congestion Avoidance in the Internet", RFC 2309, April
+                 1998.
+
+   [RFC2322]     van den Hout, K., Koopal, A. and R. van Mook,
+                 "Management of IP numbers by peg-dhcp", RFC 2322, 1
+                 April 1998.
+
+   [RFC2328]     Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
+                 1998.
+
+   [RFC2332]     Luciani, J., Katz, D., Piscitello, D., Cole, B. and N.
+                 Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)",
+                 RFC 2332, April 1998.
+
+   [RFC2364]     Gross, G., Kaycee, M., Li, A., Malis, A. and J.
+                 Stephens, "PPP Over AAL5", RFC 2364, July 1998.
+
+   [RFC2394]     Pereira, R., "IP Payload Compression Using DEFLATE",
+                 RFC 2394, December 1998.
+
+   [RFC2395]     Friend, R. and R. Monsour, "IP Payload Compression
+                 Using LZS", RFC 2395, December 1998.
+
+   [RFC2401]     Kent, S. and R. Atkinson, "Security Architecture for
+                 the Internet Protocol", RFC 2401, November 1998.
+
+   [RFC2406]     Kent, S. and R. Atkinson, "IP Encapsulating Security
+                 Payload (ESP)", RFC 2406, November 1998.
+
+   [RFC2440]     Callas, J., Donnerhacke, L., Finney, H. and R. Thayer,
+                 "OpenPGP Message Format", RFC 2440, November 1998.
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 51]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   [RFC2460]     Deering, S. and R. Hinden, "Internet Protocol, Version
+                 6 (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC2461]     Narten, T., Nordmark, E. and W. Simpson, "Neighbor
+                 Discovery for IP Version 6 (IPv6)", RFC 2461, December
+                 1998.
+
+   [RFC2474]     Nichols, K., Blake, S., Baker, F. and D. Black,
+                 "Definition of the Differentiated Services Field (DS
+                 Field) in the IPv4 and IPv6 Headers", RFC 2474,
+                 December 1998.
+
+   [RFC2475]     Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
+                 and W. Weiss, "An Architecture for Differentiated
+                 Services", RFC 2475, December 1998.
+
+   [RFC2507]     Degermark, M., Nordgren, B. and S. Pink, "IP Header
+                 Compression", RFC 2507, February 1999.
+
+   [RFC2508]     Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
+                 Headers for Low-Speed Serial Links", RFC 2508, February
+                 1999.
+
+   [RFC2581]     Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
+                 Control", RFC 2581, April 1999.
+
+   [RFC2582]     Floyd, S. and T. Henderson, "The NewReno Modification
+                 to TCP's Fast Recovery Algorithm", RFC 2582, April
+                 1999.
+
+   [RFC2597]     Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
+                 "Assured Forwarding PHB Group", RFC 2597, June 1999.
+
+   [RFC2616]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+                 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
+                 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2630]     Housley, R., "Cryptographic Message Syntax", RFC 2630,
+                 June 1999.
+
+   [RFC2631]     Rescorla, E., "Diffie-Hellman Key Agreement Method",
+                 RFC 2631, June 1999.
+
+   [RFC2632]     Ramsdell, B., Ed., "S/MIME Version 3 Certificate
+                 Handling", RFC 2632, June 1999.
+
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 52]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   [RFC2633]     Ramsdell, B., "S/MIME Version 3 Message Specification",
+                 RFC 2633, June 1999.
+
+   [RFC2634]     Hoffman, P., "Enhanced Security Services for S/MIME",
+                 RFC 2634, June 1999.
+
+   [RFC2684]     Grossman, D. and J. Heinanen, "Multiprotocol
+                 Encapsulation over ATM Adaptation Layer 5", RFC 2684,
+                 September 1999.
+
+   [RFC2686]     Bormann, C., "The Multi-Class Extension to Multi-Link
+                 PPP", RFC 2686, September 1999.
+
+   [RFC2687]     Bormann, C., "PPP in a Real-time Oriented HDLC-like
+                 Framing", RFC 2687, September 1999.
+
+   [RFC2689]     Bormann, C., "Providing Integrated Services over Low-
+                 bitrate Links", RFC 2689, September 1999.
+
+   [RFC2710]     Deering, S., Fenner, W. and B. Haberman, "Multicast
+                 Listener Discovery (MLD) for IPv6", RFC 2710, October
+                 1999.
+
+   [RFC2784]     Farinacci, D., Li, T., Hanks, S., Meyer, D. and P.
+                 Traina, "Generic Routing Encapsulation (GRE)", RFC
+                 2784, March 2000.
+
+   [RFC2865]     Rigney, C., Willens, S., Rubens, A. and W. Simpson,
+                 "Remote Authentication Dial In User Service (RADIUS)",
+                 RFC 2865, June 2000.
+
+   [RFC2914]     Floyd, S., "Congestion Control Principles", BCP 41, RFC
+                 2914, September 2000.
+
+   [RFC2923]     Lahey, K., "TCP Problems with Path MTU Discovery", RFC
+                 2923, September 2000.
+
+   [RFC2988]     Paxson, V. and M. Allman, "Computing TCP's
+                 Retransmission Timer", RFC 2988, November 2000.
+
+   [RFC2990]     Huston, G., "Next Steps for the IP QoS Architecture",
+                 RFC 2990, November 2000.
+
+   [RFC3048]     Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
+                 Floyd, S. and M. Luby, "Reliable Multicast Transport
+                 Building Blocks for One-to-Many Bulk-Data Transfer",
+                 RFC 3048, January 2001.
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 53]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   [RFC3095]     Bormann, C., Ed., Burmeister, C., Degermark, M.,
+                 Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R.,
+                 Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki,
+                 A., Svanbro, K., Wiebke, T., Yoshimura, T. and H.
+                 Zheng, "RObust Header Compression (ROHC):  Framework
+                 and four profiles: RTP, UDP, ESP, and uncompressed",
+                 RFC 3095, July 2001.
+
+   [RFC3096]     Degermark, M., Ed., "Requirements for robust IP/UDP/RTP
+                 header compression", RFC 3096, July 2001.
+
+   [RFC3150]     Dawkins, S., Montenegro, G., Kojo, M. and V. Magret,
+                 "End-to-end Performance Implications of Slow Links",
+                 BCP 48, RFC 3150, July 2001.
+
+   [RFC3155]     Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and
+                 N. Vaidya, "End-to-end Performance Implications of
+                 Links with Errors", BCP 50, RFC 3155, August 2001.
+
+   [RFC3168]     Ramakrishnan, K., Floyd, S. and D. Black, "The Addition
+                 of Explicit Congestion Notification (ECN) to IP", RFC
+                 3168, September 2001.
+
+   [RFC3173]     Shacham, A., Monsour, B., Pereira, R. and M. Thomas,
+                 "IP Payload Compression Protocol (IPComp)", RFC 3173,
+                 September 2001.
+
+   [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.
+
+   [RFC3248]     Armitage, G., Carpenter, B., Casati, A., Crowcroft, J.,
+                 Halpern, J., Kumar, B. and J. Schnizlein, "A Delay
+                 Bound alternative revision of RFC 2598", RFC 3248,
+                 March 2002.
+
+   [RFC3344]     Perkins, C., Ed., "IP Mobility Support for IPv4", RFC
+                 3344, August 2002.
+
+   [RFC3366]     Fairhurst, G. and L. Wood, "Advice to link designers on
+                 link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366,
+                 August 2002.
+
+
+
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 54]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   [RFC3376]     Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A.
+                 Thyagarajan, "Internet Group Management Protocol,
+                 Version 3", RFC 3376, October 2002.
+
+   [RFC3449]     Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M.
+                 Sooriyabandara, "TCP Performance Implications of
+                 Network Path Asymmetry", BCP 69, RFC 3449, December
+                 2002.
+
+   [RFC3450]     Luby, M., Gemmell, J., Vicisano, L., Rizzo, L. and J.
+                 Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
+                 Instantiation", RFC 3450, December 2002.
+
+   [RFC3451]     Luby, M., Gemmell, J., Vicisano, L., Rizzo, L.,
+                 Handley, M. and J. Crowcroft, "Layered Coding Transport
+                 (LCT) Building Block", RFC 3451, December 2002.
+
+   [RFC3452]     Luby, M., Vicisano, L., Gemmell, J., Rizzo, L.,
+                 Handley, M. and J. Crowcroft, "Forward Error Correction
+                 (FEC) Building Block", RFC 3452, December 2002.
+
+   [RFC3453]     Luby, M., Vicisano, L., Gemmell, J., Rizzo, L.,
+                 Handley, M. and J. Crowcroft, "The Use of Forward Error
+                 Correction (FEC) in Reliable Multicast", RFC 3453,
+                 December 2002.
+
+   [RFC3488]     Wu, I. and T. Eckert, "Cisco Systems Router-port Group
+                 Management Protocol (RGMP)", RFC 3488, February 2003.
+
+   [RFC3501]     Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
+                 VERSION 4rev1", RFC 3501, March 2003.
+
+   [RFC3828]     Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E.,
+                 Ed. and G. Fairhurst, Ed., "The User Datagram Protocol
+                 (UDP)-Lite Protocol", RFC 3828, June 2004.
+
+   [Schneier95]  Schneier, B., Applied Cryptography: Protocols,
+                 Algorithms and Source Code in C (John Wiley and Sons,
+                 October 1995).
+
+   [Schneier00]  Schneier, B., Secrets and Lies: Digital Security in a
+                 Networked World (John Wiley and Sons, August 2000).
+
+   [SP2000]      Stone, J. and C. Partridge, "When the CRC and TCP
+                 Checksum Disagree", ACM SIGCOMM, September 2000.
+                 http://www.acm.org/sigcomm/sigcomm2000/conf/
+                 paper/sigcomm2000-9-1.pdf
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 55]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   [SRC81]       Saltzer, J., Reed D. and D. Clark, "End-to-End
+                 Arguments in System Design".  Second International
+                 Conference on Distributed Computing Systems (April,
+                 1981) pages 509-512. Published with minor changes in
+                 ACM Transactions in Computer Systems 2, 4, November,
+                 1984, pages 277-288. Reprinted in Craig Partridge,
+                 editor Innovations in internetworking. Artech House,
+                 Norwood, MA, 1988, pages 195-206. ISBN 0-89006-337-0.
+
+   [SSL2]        Hickman, K., "The SSL Protocol", Netscape
+                 Communications Corp., Feb 9, 1995.
+
+   [SSL3]        Frier, A., Karlton, P. and P. Kocher, "The SSL 3.0
+                 Protocol", Netscape Communications Corp., Nov 18, 1996.
+
+   [TCPF98]      Lin, D. and H.T. Kung, "TCP Fast Recovery Strategies:
+                 Analysis and Improvements", IEEE Infocom, March 1998.
+                 http://www.eecs.harvard.edu/networking/papers/infocom-
+                 tcp-final-198.pdf
+
+   [WFBA2000]    Wagner, D., Foster, J., Brewer, E. and A. Aiken, "A
+                 First Step Toward Automated Detection of Buffer Overrun
+                 Vulnerabilities", Proceedings of NDSS2000.
+                 http://www.isoc.org/isoc/conferences/ndss/
+                 2000/proceedings/039.pdf
+
+   [Wilbur89]    Wilbur, Steve R., Jon Crowcroft, and Yuko Murayama.
+                 "MAC layer Security Measures in Local Area Networks",
+                 Local Area Network Security, Workshop LANSEC '89
+                 Proceedings, Springer-Verlag, April 1989, pp. 53-64.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 56]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+21. Contributors' Addresses
+
+   Aaron Falk
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina Del Rey, CA 90292
+
+   Phone: 310-448-9327
+   EMail: falk@isi.edu
+
+
+   Saverio Mascolo
+   Dipartimento di Elettrotecnica ed Elettronica,
+   Politecnico di Bari Via Orabona 4, 70125 Bari, Italy
+
+   Phone: +39 080 596 3621
+   EMail: mascolo@poliba.it
+   URL: http://www-dee.poliba.it/dee-web/Personale/mascolo.html
+
+
+   Marie-Jose Montpetit
+   MJMontpetit.com
+
+   EMail: marie@mjmontpetit.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 57]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+22.  Authors' Addresses
+
+   Phil Karn, Editor
+   Qualcomm 5775 Morehouse Drive
+   San Diego CA 92121
+
+   Phone: 858 587 1121
+   EMail: karn@qualcomm.com
+
+
+   Carsten Bormann
+   Universitaet Bremen TZI
+   Postfach 330440
+   D-28334 Bremen, Germany
+
+   Phone: +49 421 218 7024
+   Fax:   +49 421 218 7000
+   EMail: cabo@tzi.org
+
+
+   Godred (Gorry) Fairhurst
+   Department of Engineering, University of Aberdeen,
+   Aberdeen, AB24 3UE, United Kingdom
+
+   EMail: gorry@erg.abdn.ac.uk
+   URL: http://www.erg.abdn.ac.uk/users/gorry
+
+
+   Dan Grossman
+   Motorola, Inc.
+   111 Locke Drive
+   Marlboro, MA 01752
+
+   EMail: Dan.Grossman@motorola.com
+
+
+   Reiner Ludwig
+   Ericsson Research
+   Ericsson Allee
+   1 52134 Herzogenrath, Germany
+
+   Phone: +49 2407 575 719
+   EMail: Reiner.Ludwig@ericsson.com
+
+
+
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 58]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+   Jamshid Mahdavi
+   Novell, Inc.
+
+   EMail: jmahdavi@earthlink.net
+
+
+   Gabriel Montenegro
+   Sun Microsystems Laboratories, Europe
+   180, Avenue de l'Europe
+   38334 Saint Ismier CEDEX
+   France
+
+   EMail: gab@sun.com
+
+
+   Joe Touch
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey CA 90292
+
+   Phone: 310 448 9151
+   EMail: touch@isi.edu
+   URL: http://www.isi.edu/touch
+
+
+   Lloyd Wood
+   Cisco Systems
+   9 New Square Park, Bedfont Lakes
+   Feltham TW14 8HA
+   United Kingdom
+
+   Phone: +44 (0)20 8824 4236
+   EMail: lwood@cisco.com
+   URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 59]
+
+RFC 3819        Advice for Internet Subnetwork Designers       July 2004
+
+
+23.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+   INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed
+   to pertain to the implementation or use of the technology
+   described in this document or the extent to which any license
+   under such rights might or might not be available; nor does it
+   represent that it has made any independent effort to identify any
+   such rights.  Information on the procedures with respect to
+   rights in RFC documents can be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use
+   of such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository
+   at http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention
+   any copyrights, patents or patent applications, or other
+   proprietary rights that may cover technology that may be required
+   to implement this standard.  Please address the information to the
+   IETF at ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Karn, et al.             Best Current Practice                 [Page 60]
+