Xem mẫu

implementing an end-to-end connection, WP-TCP behaves like any other TCP application, establishing a connection directly with the origin server. This is illustrated in Figure 18-9. Wireless client Upper Layers WP-TCP IP IP Router Origin server Upper Layers TCP IP Wireless Bearer Wireless Bearer Wired Interface Wireless Bearer Figure 18-9 The end-to-end approach The decision to implement the end-to-end approach over the split-TCP approach is usually determined by service, server, and hardware provisioning or the specific needs of the application layer. WP-TCP optimizations As noted previously, certain scenarios exist on a wireless network that make a purely TCP connection less desirable. Such scenarios include: Ê Frequent packet loss Ê Smaller window sizes Ê Long periods of silence or connection loss due to exponential back-off retransmission mechanisms Ê Redundant transmission Ê Periods of disconnection due to lack of coverage 676 TCP/IP Tutorial and Technical Overview The profiling of TCP for WP-TCP sought to optimize the protocol to compensate for these scenarios. Specifically, eight optimizations were included in WP-TCP. These are: Ê Large window size: Built in to TCP is the use of the Bandwidth Delay Product (BDP), calculated from the available bandwidth and the round-trip time, to calculate the minimum window size. It also calculates the maximum window size using the smallest value of the send or receive buffers. WP-TCP can opt to use the maximum window size, relying on the congestion control mechanisms built into TCP to regulate the data as needed. The WP-TCP specification indicates that implementation of this optimization is recommended, but not required. Ê The window scale option: Entities that opt to use the large window size are required to also implement the window scale option defined by RFC 1323. If an entity does not support the large window size optimization, implementation of the window scale optimization is optional. Ê Round-trip time measurement: Also defined in RFC 1323, round-trip time measurement (RTTM) is recommended for use by any entity that implements window sizes larger than 64 K. This also requires the use of the time stamp option. Ê Large initial window: The standard TCP implementation includes an initial window up to two segments in size. However, WP-TCP employs an extension defined in RFC 2414 that allows WP-TCP to send an initial window of three or four segments. This is limited to 4380 bytes. Implementation of this optimization is optional. Ê Path MTU discovery: WP-TCP now supports the procedures, defined in RFCs 1191 and 1981, used to discover the maximum transmission unit (MTU) of any given path. This allows WP-TCP to optimize the amount of data sent in each packet to avoid fragmentation or dropped packets. Implementation of this optimization is recommended, but not required. Ê MTU larger than the default IP MTU: If an entity cannot support path MTU discover (for example, if some of the routers in the path do not support the needed ICMP messages), a WP-TCP implementation can assume a value exceeding the default IPv4 or IPv6 values. However, the value assumed must not exceed 1500 bytes, and must reflect the maximum segment size negotiated when establishing the TCP connection. Ê Selective acknowledgement: The fast recover algorithm, defined in RFC 2581, tends to be less efficient when attempting to recover from multiple losses in a single window. This scenario is very likely on wireless connections, and therefore, an alternative to the fast recover algorithm was implemented. Selective acknowledgement (SACK) was defined in RFC 2018 Chapter 18. Wireless Application Protocol 677 and allows WPT-TCP to send acknowledgements selectively, indicating what data needs to be retransmitted. Implementation of this optimization is required. Ê Explicit congestion notification (ECN): Defined in RFC 2481, ECN allows a WP-TCP receiver to notify the sender of the data of congestion in the network. This allows the sender to reduce it’s congestion window. Implementation of this optimization is optional. 18.9.3 Wireless Control Message Protocol (WCMP) The Wireless Control Message Protocol (WCMP) very closes mirrors the functionality of the Internet Control Message Protocol (ICMP) defined in RFCs 792 and 2463. Defined in the OMA WAP-202-WCMP-20010624-a specification, it is used by the WDP to provide ICMP-like capability when using wireless bearers that do not support IP. Specifically, WCMP is used to report problems occurring when processing datagrams. Errors reported by WCMP messages can be broken into six types, some of which can be further divided into codes. These are listed in Table 18-2. Table 18-2 WCMP types and codes WCMP message Destination unreachable Communication administratively prohibited Address unreachable Port unreachable Parameter problem Erroneous header field Message too big Reassembly failure Reassembly time exceeded Buffer overflow Echo request Echo reply WCMP type 51 54 60 61 178 179 WCMP code 1 3 4 0 0 1 2 0 0 678 TCP/IP Tutorial and Technical Overview WCMP message structure The message structure of WCMP messages varies based on the type of wireless bearer used by the originator or the message, as well as the type of the WCAMP message. However, every WCMP does adhere to a general format, as defined in Figure 18-10. Bit/Octet 0 1 2 3 4 5 6 7 1 2 3-n Figure 18-10 Type of control message Code of control message Data fields for WCMP (0...n octets) General WCMP message structure 18.9.4 Wireless Transaction Protocol (WTP) The Wireless Transaction Protocol, defined in the OMA WAP-224-WTP-20010710-a specification, provides a mechanism especially designed for WAP terminals with limited resources over networks and with low to medium bandwidth. This technology allows more subscribers on the same network due to reduced bandwidth utilization. WTP provides unreliable and reliable data transfer based on the request/reply paradigm. Unlike TCP, there is no connection setup and tear down. Compared to TCP, where a SYN and ACK flow is started before the first data is transmitted, WTP carries data in the first packet of the protocol exchange. Additionally, WTP employs a message-oriented model, as opposed to TCP’s stream-oriented implementation. WTP classes of operation There are three classes of operation, numbering zero through two. Class 0 Class 0 is defined by the OMA specification as “unconfirmed invoke message with no result message.” This is a datagram that can be sent within the context of an existing WSP session (see 18.9.5, “Wireless Session Protocol (WSP)” on page 682). However, it is not intended to be a primary method of sending Chapter 18. Wireless Application Protocol 679 datagrams. For that functionality, use WDP instead. The sequence of events in a Class 0 transaction is as follows: 1. An initiator sends an invoke message to the responder. After the message has been sent, the initiator’s role in the transaction has ended. No retransmissions are sent of the message. 2. The responder receives the invoke message. No response is sent acknowledging receipt of the invoke message. After the message has been received, the transaction is complete. Because there are no retransmissions or replies, this type of transaction is considered stateless and cannot be aborted. An additional illustration of a Class 0 transaction can be found in Figure 18-12 on page 685). Class 1 Class 1 is defined as “confirmed invoke message with no result message.” This is used for reliable data push (see 18.6, “WAP push architecture” on page 664), where no response from the destination is expected, though the transaction is still termed a reliable datagram service. The sequence of events in a Class 1 transaction is as follows: 1. An initiator sends an invoke message to the responder. 2. The responder receives the invoke message and returns an acknowledgement (but not a result message). If the initiator does not receive an acknowledgement, the invoke message is retransmitted. The transaction remains in an active state until the acknowledgement arrives at the initiator. Upon receipt of the acknowledgement, the Initiator considers the transaction to have ended. The Class 1 transaction can be aborted at any point during the sequence of events. Class 2 Class 2 is defined as “confirmed invoke message with one confirmed result message.” In this class, one single request produces a single reply. This comprises the typical request/response interaction model most widely employed by applications. The sequence of events in a Class 2 transaction is as follows: 1. An initiator sends an invoke message to the responder. 2. The responder might send back an acknowledgement to this message. This happens if the responder is not able to send back a result message immediately. 3. The responder sends back a result message. If no acknowledgment had been previously sent to the initiator, this result message implicitly acknowledges the receipt of the invoke message. If the initiator receives no acknowledgement or result message, it retransmits the invoke message. 680 TCP/IP Tutorial and Technical Overview ... - tailieumienphi.vn
nguon tai.lieu . vn