rfc2757.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   connections to continue on, say, a wireless WAN. This type of agility
   also requires Mobile IP [RFC2002].

1.2 Assumptions about the Radio Link

   The system architecture described above assumes at most one wireless
   link (perhaps comprising more than one wireless hop).  However, this
   is not enough to characterize a wireless link.  Additional
   considerations are:

      -  What are the error characteristics of the wireless medium?  The
         link may present a higher BER than a wireline network due to
         burst errors and disconnections. The techniques below usually
         do not address all the types of errors. Accordingly, a complete
         solution should combine the best of all the proposals.
         Nevertheless, in this document we are more concerned with (and
         give preference to solving) the most typical case: (1) higher
         BER due to random errors (which implies longer and more
         variable delays due to link-layer error corrections and
         retransmissions) rather than (2) an interruption in service due
         to a handoff or a disconnection.  The latter are also important
         and we do include relevant proposals in this survey.

      -  Is the wireless service datagram oriented, or is it a virtual
         circuit?  Currently, switched virtual circuits are more common,
         but packet networks are starting to appear, for example,
         Metricom's Starmode [CB96], CDPD [CDPD] and General Packet
         Radio Service (GPRS) [GPRS],[BW97] in GSM.

      -  What kind of reliability does the link provide? Wireless
         services typically retransmit a packet (frame) until it has
         been acknowledged by the target. They may allow the user to
         turn off this behavior. For example, GSM allows RLP [RLP]
         (Radio Link Protocol)  to be turned off.  Metricom has a
         similar "lightweight" mode. In GSM RLP, a frame is
         retransmitted until the maximum number of retransmissions
         (protocol parameter) is reached. What happens when this limit
         is reached is determined by the telecom operator:  the physical
         link connection is either disconnected or a link reset is
         enforced where the sequence numbers are resynchronized and the
         transmit and receive buffers are flushed resulting in lost
         data. Some wireless services, like CDMA IS95-RLP [CDMA,
         Karn93], limit the latency on the wireless link by
         retransmitting a frame only a couple of times. This decreases
         the residual frame error rate significantly, but does not
         provide fully reliable link service.



Montenegro, et al.           Informational                      [Page 6]

RFC 2757                   Long Thin Networks               January 2000


      -  Does the mobile device transmit and receive at the same time?
         Doing so increases the cost of the electronics on the mobile
         device. Typically, this is not the case. We assume in this
         document that mobile devices do not transmit and receive
         simultaneously.

      -  Does the mobile device directly address more than one peer on
         the wireless link? Packets to each different peer may traverse
         spatially distinct wireless paths. Accordingly, the path to
         each peer may exhibit very different characteristics.  Quite
         commonly, the mobile device addresses only one peer (the
         intermediate node) at any given point in time.  When this is
         not the case, techniques such as Channel-State Dependent Packet
         Scheduling come into play (see the section "Packet Scheduling"
         below).

2 Should it be IP or Not?

   The first decision is whether to use IP as the underlying network
   protocol or not. In particular, some data protocols evolved from
   wireless telephony are not always -- though at times they may be --
   layered on top of IP [MOWGLI, WAP]. These proposals are based on the
   concept of proxies that provide adaptation services between the
   wireless and wireline segments.

   This is a reasonable model for mobile devices that always communicate
   through the proxy. However, we expect many wireless mobile devices to
   utilize wireline networks whenever they are available. This model
   closely follows current laptop usage patterns: devices typically
   utilize LANs, and only resort to dial-up access when "out of the
   office."

   For these devices, an architecture that assumes IP is the best
   approach, because it will be required for communications that do not
   traverse the intermediate node (for example, upon reconnection to a
   W-LAN or a 10BaseT network at the office).

2.1 Underlying Network Error Characteristics

   Using IP as the underlying network protocol requires a certain (low)
   level of link robustness that is expected of wireless links.

   IP, and the protocols that are carried in IP packets, are protected
   end-to-end by checksums that are relatively weak [Stevens94,
   Paxson97] (and, in some cases, optional). For much of the Internet,
   these checksums are sufficient; in wireless environments, the error
   characteristics of the raw wireless link are much less robust than
   the rest of the end-to-end path.  Hence for paths that include



Montenegro, et al.           Informational                      [Page 7]

RFC 2757                   Long Thin Networks               January 2000


   wireless links, exclusively relying on end-to-end mechanisms to
   detect and correct transmission errors is undesirable. These should
   be complemented by local link-level mechanisms. Otherwise, damaged IP
   packets are propagated through the network only to be discarded at
   the destination host. For example, intermediate routers are required
   to check the IP header checksum, but not the UDP or TCP checksums.
   Accordingly, when the payload of an IP packet is corrupted, this is
   not detected until the packet arrives at its ultimate destination.

   A better approach is to use link-layer mechanisms such as FEC,
   retransmissions, and so on in order to improve the characteristics of
   the wireless link and present a much more reliable service to IP.
   This approach has been taken by CDPD, Ricochet and CDMA.

   This approach is roughly analogous to the successful deployment of
   Point-to-Point Protocol (PPP), with robust framing and 16-bit
   checksumming, on wireline networks as a replacement for the Serial
   Line Interface Protocol (SLIP), with only a single framing byte and
   no checksumming.

   [AGS98] recommends the use of FEC in satellite environments.

   Notice that the link-layer could adapt its frame size to the
   prevalent BER.  It would perform its own fragmentation and reassembly
   so that IP could still enjoy a large enough MTU size [LS98].

   A common concern for using IP as a transport is the header overhead
   it implies. Typically, the underlying link-layer appears as PPP
   [RFC1661] to the IP layer above. This allows for header compression
   schemes [IPHC, IPHC-RTP, IPHC-PPP] which greatly alleviate the
   problem.

2.2 Non-IP Alternatives

   A number of non-IP alternatives aimed at wireless environments have
   been proposed. One representative proposal is discussed here.

2.2.1 WAP

   The Wireless Application Protocol (WAP) specifies an application
   framework and network protocols for wireless devices such as mobile
   telephones, pagers, and PDAs [WAP]. The architecture requires a proxy
   between the mobile device and the server. The WAP protocol stack is
   layered over a datagram transport service.  Such a service is
   provided by most wireless networks; for example, IS-136, GSM
   SMS/USSD, and UDP in IP networks like CDPD and GSM GPRS. The core of





Montenegro, et al.           Informational                      [Page 8]

RFC 2757                   Long Thin Networks               January 2000


   the WAP protocols is a binary HTTP/1.1 protocol with additional
   features such as header caching between requests and a shared state
   between client and server.

2.2.2 Deploying Non-IP Alternatives

   IP is such a fundamental element of the Internet that non-IP
   alternatives face substantial obstacles to deployment, because they
   do not exploit the IP infrastructure. Any non-IP alternative that is
   used to provide gatewayed access to the Internet must map between IP
   addresses and non-IP addresses, must terminate IP-level security at a
   gateway, and cannot use IP-oriented discovery protocols (Dynamic Host
   Configuration Protocol, Domain Name Services, Lightweight Directory
   Access Protocol, Service Location Protocol, etc.) without translation
   at a gateway.

   A further complexity occurs when a device supports both wireless and
   wireline operation. If the device uses IP for wireless operation,
   uninterrupted operation when the device is connected to a wireline
   network is possible (using Mobile IP). If a non-IP alternative is
   used, this switchover is more difficult to accomplish.

   Non-IP alternatives face the burden of proof that IP is so ill-suited
   to a wireless environment that it is not a viable technology.

2.3 IP-based Considerations

   Given its worldwide deployment, IP is an obvious choice for the
   underlying network technology. Optimizations implemented at this
   level benefit traditional Internet application protocols as well as
   new ones layered on top of IP or UDP.

2.3.1 Choosing the MTU [Stevens94, RFC1144]

   In slow networks, the time required to transmit the largest possible
   packet may be considerable.  Interactive response time should not
   exceed the well-known human factors limit of 100 to 200 ms. This
   should be considered the maximum time budget to (1) send a packet and
   (2) obtain a response. In most networking stack implementations, (1)
   is highly dependent on the maximum transmission unit (MTU). In the
   worst case, a small packet from an interactive application may have
   to wait for a large packet from a bulk transfer application before
   being sent. Hence, a good rule of thumb is to choose an MTU such that
   its transmission time is less than (or not much larger than) 200 ms.







Montenegro, et al.           Informational                      [Page 9]

RFC 2757                   Long Thin Networks               January 2000


   Of course, compression and type-of-service queuing (whereby
   interactive data packets are given a higher priority) may alleviate
   this problem. In particular, the latter may reduce the average wait
   time to about half the MTU's transmission time.

2.3.2 Path MTU Discovery [RFC1191]

   Path MTU discovery benefits any protocol built on top of IP. It
   allows a sender to determine what the maximum end-to-end transmission
   unit is to a given destination. Without Path MTU discovery, the
   default IPv4 MTU size is 576. The benefits of using a larger MTU are:

      -  Smaller ratio of header overhead to data

      -  Allows TCP to grow its congestion window faster, since it
         increases in units of segments.

   Of course, for a given BER, a larger MTU has a correspondingly larger
   probability of error within any given segment. The BER may be reduced
   using lower level techniques like FEC and link-layer retransmissions.
   The issue is that now delays may become a problem due to the
   additional retransmissions, and the fact that packet transmission
   time increases with a larger MTU.

   Recommendation: Path MTU discovery is recommended. [AGS98] already
   recommends its use in satellite environments.

2.3.3 Non-TCP Proposals

   Other proposals assume an underlying IP datagram service, and
   implement an optimized transport either directly on top of IP
   [NETBLT] or on top of UDP [MNCP]. Not relying on TCP is a bold move,
   given the wealth of experience and research related to it.  It could
   be argued that the Internet has not collapsed because its main
   protocol, TCP, is very careful in how it uses the network, and
   generally treats it as a black box assuming all packet losses are due
   to congestion and prudently backing off. This avoids further
   congestion.

   However, in the wireless medium, packet losses may also be due to
   corruption due to high BER, fading, and so on. Here, the right
   approach is to try harder, instead of backing off. Alternative
   transport protocols are:

      -  NETBLT [NETBLT, RFC1986, RFC1030]

      -  MNCP [MNCP]




Montenegro, et al.           Informational                     [Page 10]

RFC 2757                   Long Thin Networks               January 2000


      -  ESRO [RFC2188]

      -  RDP [RFC908, RFC1151]

      -  VMTP [VMTP]

3 The Case for TCP

   This is one of the most hotly debated issues in the wireless arena.
   Here are some arguments against it: