Internet Draft Fei Peng draft-fpeng-wecn-03.txt Beijing University of posts and telecomm. Jian Ma Nokia Research Center August 1999 An Effective way for Enhancement of TCP Performance in Wireless and Mobile Networks Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft Internet-Drafts is working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts is draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract TCP congestion control has been developed on the assumption that congestion in the network to be the only cause for packet loss. Thus, it drops its transmit window upon detecting a packet loss. In the presence of high erro rates and intermittent connective characteristic of wireless link, these results in an unnecessary reduction in link bandwidth utilization for packet losses are not mainly due to congestion. This paper provides an effective way to improve TCP performance in wireless and mobile networks. Current ECN proposal used in traditional wired networks with the purpose of avoiding unnecessary packet losses can obtain separation of loss recovery from congestion control if packet losses are disabled to initiate source window reduction. However, to implement ECN, complex and inconsistent buffer management in the networks is required. Since packet losses due to Fei and Jain Experimental [Page 1] Draft-fpeng-wecn An Effective WECN Scheme August 1999 buffer overflow are not allowed to invoke congestion control if apply ECN into wireless environment, this may cause performance deterioration when ECN encounters buffer overflow in such case for the failure of initiation of congestion control. In this draft, we propose to add Wireless-ECN just upon the first packet loss occurs. In this way, it strongly achieves separation of congestion control and loss recovery mechanism by quickly informing the sender that a loss happened because of reasons related to network congestion. The unnecessary window reduction caused by lost packets due to link errors is avoided. When ECN meet buffer overflow in wireless and mobile networks, the addition of Wireless-ECN can represent congestion losses to initiate window reduction in time and improve ECN performance. Specially, to prevent unnecessary packet losses due to buffer overflow, it is most recommended to cooperate WECN with ECN or a better congestion avoidance mechanism than ECN to improve TCP performance in wireless and mobile networks. 2. Conventions used in this document "WECN" indicates Wireless-ECN. "WECN-Echo flag" indicates Wireless- ECN-Echo flag. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [ ]. 3. Introduction Congestion control is one of the key mechanisms to accommodate the increasingly diverse range of services and types of traffic in the Internet. Initially the Internet was intended to support best-effort service, and the TCP congestion control method that was actually implemented has been developed on the assumption that the network would be treated as a black box. This means that the end nodes do not exercise control by directly ascertaining the state of routers and transmission line, but rather regulate the traffic by inferring the network load indirectly from packet loss and response time fluctuations. In wired networks, this may not induce serious problems as packet losses are mainly due to congestion. However, in the presence of high error rates and intermittent connective characteristic of wireless links, this reliance on packet drops as the indication of congestion causes a significant degradation in TCP performance, for TCP reacts to packet loss as it would in the wired environment: it drops its retransmit window size before retransmiting packets, initiates congestion control or avoidance mechanisms and resets its retransmission timer, thereby result in an unnecessary Fei and Jain Experimental [Page 2] Draft-fpeng-wecn An Effective WECN Scheme August 1999 reduction in the link bandwidth utilization, which causing poor throughput and very high interactive delays. Recently, several schemes have been proposed to alleviate the effects of non-congestion-related losses on TCP performance over networks that have wireless or similar high-loss links. One of the researches concerns on improvement of transport underlying protocol stacks. For example, there have been several proposals for reliable link-layer protocols as forward error correction (FEC) and retransmission of lost packets in response to automatic repeat request (ARQ) messages. However, it is the main worry about link-layer protocols that an adverse effect on certain transport-layer protocols such as TCP is very possible. Another solution of network layer protocol called Snoop protocol is proposed to cache packets at the base station and perform local retransmissions across the wireless link. Like link-layer solutions, the snoop approach could also suffer from not being able to completely shield the sender from wireless losses. Several schemes modified at transport layer have been proposed to alleviate the effects of non-congestion-related losses on transport performance. The indirect-TCP is one of the first protocols to distinguish different losses by splitting a TCP connection between a fixed and mobile host into two sepatate connections at the base station, a more optimized wireless link-specific protocol tuned for better performance can be used over a one-hop wireless link. The advantage of the split connection approach is that it achieves a separation of flow and congestion control of the wireless link from that of the fixed network. However, there are some drawbacks of this approach such as loss of semantics, application re-linking and software overhead, etc. And there is no need to sacrifice the semantics of acknowledgments in order to achieve possible good performance. As lost packets can be simply divided into congestion-related losses and non-congestion-related losses, an ELN protocols can be used to differentiate the packet loss by adding an explicit loss notification option to TCP acknowledgments when a packet is dropped on the wireless link. Future cumulative acknowledgments corresponding to each lost packet must be always marked to identify that a non- congestion-related loss has occurred, then the sender may perform retransmissions without invoking the associated congestion-control procedures. In practice, this algorithm brings burden to the implementation nodes for judgment is required for each dropped packets and each lost packet due to transmission errors needs marking otherwise it will invoke congestion control. Additionally, it might be difficult to identify which packets are lost due to errors on lossy link, for example, it may be hard to determine the connection that a corrupted packet belongs to since the header could itself be Fei and Jain Experimental [Page 3] Draft-fpeng-wecn An Effective WECN Scheme August 1999 corrupted. This paper provides a mechanism called Wireless-ECN (WECN) used in wireless and mobile networks. Like ELN, it is a mechanism by which the reason for the loss of a packet can be communicated to the TCP sender. In particular, it provides a way by which senders can be informed that a loss happened because of reasons related to network congestion, so that sender congestion control can be decoupled from retransmissions for it reduce the congestion window without the consideration of packet losses. Since it is no need to reduce the congestion window more than once in a round trip time, the burden to the implementation is greatly released for judgment is not required for each dropped packets due to congestion. Additionally, it is very easy to identify which packets are lost due to buffer overflow. 4. Motivation Currently, a scheme concerning adding an explicit congestion notification (ECN) to TCP acknowledgment option through detecting incipient congestion in the network is proposed by IETF. Upon receiving this ECN message, the sender reduces its congestion window whenever loss occurs. With the purpose of preventing unnecessary packet drops, it gives a part separation of congestion control and packet losses and makes TCP basing its congestion control not solely on packet losses. However, when ECN mechanism is being used, it makes the sense to add at the same time mechanisms to monitor the average queue size. Many current networks with routers whose main function is to route packets to the networks have no provision for the detection of incipient congestion before the queue overflows. Even with this, during periods where the average queue size exceeds an upper threshold, packet-marking rate can not catch up with its passing rate, and therefore routers drop packets rather than set the ECN in packet header. It may be a deterrent in such case if packet losses are completely kept from initiating congestion control. Over small time scales (e.g., one or two round trip times), the response of TCP to ECN can be less conservative than its response to a dropped packet as an indication of congestion. Unlike Tahoe and Reno implementations of TCP, using ECN notification which does not indicate a queue overflow have to modify TCP window flow control mechanism, i.e., the source updates its window once every two round-trip times. In spite of all these difficulties, ECN is likely to be adopted gradually, So accommodating migration is essential and it is also important to provide a method to apply ECN to wireless and mobile environment. In the following section, we provide a mechanism called Wireless-ECN (WECN) used in wireless and mobile networks. It provides a way by which senders can be informed that a loss happened because of reasons Fei and Jain Experimental [Page 4] Draft-fpeng-wecn An Effective WECN Scheme August 1999 related to network congestion, so that sender congestion control can be decoupled from retransmissions for it reduce the congestion window without the consideration of packet losses. Since it is arranged to mark a data packet with an explicit wireless congestion notification (WECN) immediately after a packet loss has occurred due to a buffer overflow, it ensures that Wireless-ECN notification can be added without worrying about slow marking rate for dropping packets give the buffer time to vacate some space to hold and transmit new data. With Wireless-ECN, the complexity and inconsistency of buffer management and more consevative TCP congestion control over a short- scale period in ECN mechanism is avoided. When apply ECN into wireless and mobile networks, it is not required that packet losses to initiate congestion control. WECN at this time can represents congestion losses to invoke window reduction in time and improve ECN performance. So, Wireless-ECN provides a simple and effective way to cooperate ECN into environment. In particular, Considering WECN message is set not later than threshold duplicate ACKs, it is hoped that it would achieve higher performance than ECN even with more packet losses because WECN provides a more timely reaction to loss retransmission than reactions based on drop detection via duplicate ACKs or timeout when ECN is used. 5. Assumptions In this section, we describe some of the important assumptions that guided the design choices in this proposal. (1) It is one of the premises of WECN mechanism that all the end nodes in the experiment are WECN capable. Otherwise, congestion control would be invoked in response to packet loss whenever it is due to congestion or tranmit errors. (2) It is assumed that each node in the network can add WECN bit in the packets to indicate congestion once packet losses occur. (3) We also assume that the transport is capable and willing to participate in WECN in each transmitting packet. (4) With the above assumption, implementing WECN need not having to resort to "islands" of WECN-capable and non-WECN-capable environments. (5) Asymmetric routing is likely to be a normal occurrence in the Internet. The path (sequence of links and routers) followed by the acknowledgment packets in the reverse direction. 6. Wireless Explicit Congestion Notification in IP Upon the first lost packet due to buffer overflow in the intermediate router, Wireless-ECN notification is added in the header of following passing packet for dropping packets give the buffer time to vacate some space to hold and transmit new data. This ensures that the Fei and Jain Experimental [Page 5] Draft-fpeng-wecn An Effective WECN Scheme August 1999 Wireless-ECN notification can inevitably be added even with multiple packet losses and no need of mechanisms in the router to monitor the average queue size. The request for the Wireless-ECN to be added as quickly as possible after a packet loss occurs due to congestion is to make certain to alleviate network congestion in time. It is requested that each node in the network can add Wireless-ECN signal to indicate congestion once a packet loss occurs. If multiple packet losses occur in a congestion window, multiple Wireless-ECN messages are to be set in a node. It is also allowed to set Wireless- ECN bit in the following packets belonging to the same congestion window in the successive passing routers. As it must take a round- trip time for the first added Wireless-ECN to reach to the sender, and also for the condition and buffer occupancy in each network node varies greatly, not only one Wireless-ECN are set in a transmission window during a round-trip time. Some Wireless-ECN set may belong to different transmitting network nodes and some may belong to the same node. Moreover, once the Wireless-ECN is added in one router, the following routers may not erase the Wireless-ECN bit in arriving packets to maintain the Wireless-ECN compliance in the network. As TCP receiver must set Wireless-ECN bit in TCP header in response to each IP packet with Wireless-ECN bit added, the TCP source, however, may receive multiple Wireless-ECN packets in a congestion window. Since the main function of Wireless-ECN is to reduce the congestion window only once in a transmission window in the event of network congestion, this multiple Wireless-ECN messages also provide robustness against the possibility of a dropped Wireless-ECN packet in the bi-directional transmitting paths. To comply with current proposed ECN mechanism in IETF draft, we obey the suggestion of keeping congestion experienced information in the regular headers of an IP packet since processing the regular headers in IP packets is more efficient than processing the header information in IP options and denote it as W-CE bit to differentiate that of CE bit used for ECN. According to this, we use 'W-CE packet' to indicate a packet that has the W-CE bit set. Since the Wireless- ECN-Echo flag set in the TCP header which will directly cause window reduction at the source side is determined by W-CE bit set in the IP header, to initiate different reduction of window size as ECN does, we choose bit 5 instead of bit 6 and bit 7 which is designated as the ECT bit an the CE bit of ECN packet in the IPv4 TOS octet to indicate the congestion packet losses in the intermediate routers. So, the use of Wireless-ECN field as specified in this document cannot be guaranteed to be backwards compatible all past uses of this bit. But it provides compatibility with ECN mechanism. 7. Cogestion Control Support from the Transport Protocol 7.1. TCP initialization Fei and Jain Experimental [Page 6] Draft-fpeng-wecn An Effective WECN Scheme August 1999 In the TCP connection setup phase, the source and destination TCPs exchange information about their desire and/or capability to use WECN. Subsequent to the completion of this negotiation indicates to the network that the transport is capable and willing to participate in WECN for each transmitting packet. When a node sends a TCP SYN packet, it may set the WECN-Echo flag in the TCP header as an indication that the sending TCP is ECN-Capable, rather than as an indication of congestion or of response to congestion. More precisely, a SYN packet with WECN-Echo flags set indicates that the TCP implementation transmitting the SYN packet will participate in WECN as both a sender and receiver. When a node sends a SYN-ACK packet, it may set WECN-Echo flag, the sending TCP correctly interprets a receiver's reflection of it own flags in the Reserved field as an indication that the receiver is ECN capable. 7.2. The TCP Sender Though our proposed Wireless-ECN mechanism can not avoid unnecessary packet drops for short or delay-sensitive TCP connections as ECN can, it has the effect on independence of TCP of packet loss as the indication of congestion. As TCP use Wireless-ECN message to invoke congestion control, whenever a packet loss occurs, only retransmission mechanism is used at that time which does not affect TCP data flow rate. This is very useful in wireless and mobile networks for the network itself has the function of distinguishing different source of packet losses. By informing the sender with Wireless-ECN packets whenever the congestion loss occurs, packet losses due to transmission errors could not reduce TCP flow control window, which results in significant performance improvement. The TCP congestion window can only be reduced by Wireless-ECN message, which is set due to congestion losses. The additional requirement for the TCP source to react to multiple Wireless-ECN packets is that it should not repeat the reduction of the congestion window; since the packet was probably dropped before the source reduced its window in response to the ECN. TCP should react to an ECN at most once per round-trip time. The sender would react to the subsequent ECN only after the outstanding data before the sender entered into loss recovery phase upon receiving the first W-CE bit have all been acknowledged. Like ECN, another change for TCP is a negotiation phase during setup to determine if both end nodes are WECN-capable. TCP follows existing algorithms for sending data packets in response Fei and Jain Experimental [Page 7] Draft-fpeng-wecn An Effective WECN Scheme August 1999 to incoming ACKs. Multiple duplicate acknowledgements or retransmit timeouts only in charge of loss retransmission and is separated from window reduction. 7.3. The TCP Receiver When TCP receives a W-CE data packet at the destination end-system, the TCP data receiver sets the ECN-Echo flag in the TCP header of the subsequent ACK packet. According to W-CE bit settings of Wireless-ECN packet, the bit 7 in the reserved field of the TCP header are designated as Wireless-ECN-Echo flag. If any of the received data packets are W-CE packets with bit 5 setting, then the returning ACK has the Wireless-ECN-Echo flag set. As only one Wireless-ECN is required to be added in a router, the frequency of Wireless-ECN to be set in a congestion window will not exceed the number of total network nodes where packets must travel across. This could relieve the burden of providing interface facility between IP and TCP at the receiver side. To provide robustness against the possibility of a dropped ACK packet carring a Wireless-ECN-Echo flag, the TCP receiver must set the WECN- Echo flag in a series of ACK packets. The TCP receiver uses the CWR (Congestion Window Reduced) flag at the bit 8 of reserved field of TCP header to determine when to stop setting the WECN-Echo flag. 8. Retransmission Support from the Transport Protocol In contrast to Fast Retransmit algotithm in Reno, Tahoe TCP uses retransmit timers to detect lost packets All transmitted data is acknowledged by the receiver, and a lost packet is signaled by the expiration of a timer at the transmitter even with the arrival of duplicate acknowledgements Mutiple lost packets in a congestion window are recovered by multiple backoff of Retransmission Timeout Instead of modifying TCP behavior of detecting packet losses basing on timeout, WECN quicken the recovery phase of lost papckets by reducing the backoff of the timeout value in our simulator, that is, if a WECN message is received in a congestion window, the Retransmit Timeout set for the following packet losses in the same window will not be doubled. We then discuss the implications of WECN for Reno and New-Reno TCP versions. With our Wireless-ECN consideration, TCP react to packet loss without reduction of transmission window. When three duplicate ACKs inform the sender about packet loss, only retransmission is invoked. And Fei and Jain Experimental [Page 8] Draft-fpeng-wecn An Effective WECN Scheme August 1999 since the sender response only the first ECN in a widow, the congestion window reduces once even with multiple packets lost in a window. So, Reno TCP with Wireless-ECN need not afraid to wait for a retransmit time-out when multiple packets are dropped from a single window of data. High TCP performance would be obtained since the congestion window is only reduced once while retransmiting lost packets. Large congestion window also ensures the arrival of adequate threshold duplicate ACKs to trigger lost packet retransmission. The New-Reno TCP includes a small change to the Reno algorithm at the sender that eliminate the wait of Reno for a retransmit timer when multiple packets are lost from a window because it also only reduce congestion window once during loss recovery phase. To do this, partial ACKs do not take TCP out of Fast Recovery in New-Reno as Reno formally does, while WECN in Reno maintain congestion window by not response to the following WECNs in a window. So, New-Reno TCP with our WECN mechanism includes a small change to the New-Reno algorithm at the sender that eliminates the reliance of New-Reno on the threshold duplicate ACKs to invoke loss recovery. If the ACK has the WECN bit set, it can ensure that the packet with the sequence number in ACK has been lost. Using WECN to notify the reduction of congestion window can avoid complex treatment of partial ACKs in New- Reno. 9. Cooperate ECN into Wireless networks Current ECN mechanism is proposed in traditional wired environment to alleviate network congestion. Because of complexity of network conditions and the nature of feedback congestion control mechanism, congestion losses will not be completely averted. So, there exist a wide range of ECN conditions such as an ECN followed by another ECN, a Fast Retransmit, or a Retransmit Timeout; a Retransmit Timeout or a Fast Retransmit followed by an ECN. So, it is also required that TCP follows existing algorithm for sending data packets and reducing congestion window in response to incoming ACKs, multiple duplicate acknowledgements, or retransmit timouts when ECN is used. To put ECN into wireless and mobile networks, we have to suggest that TCP congestion window reduction can not be initiated by packet losses. The dropping packets due to congestion may be an adequate deterrent factor affecting network performance if congestion control is not initiated by packet losses due to buffer overflow in time. With the addition of Wireless-ECN, when some packet losses due to congestion come first before ECN messages arrive in a round-trip time, the Wireless-ECN signals added just upon the first packet loss caused by congestion will come in time to initiate general congestion control. And also, TCP only reacts to once and generally the earliest Fei and Jain Experimental [Page 9] Draft-fpeng-wecn An Effective WECN Scheme August 1999 one of Wireless-ECN or ECN ACK every round-trip time. The problem of unnecessary reduction of window size by packet losse irrelavent to congestion is solved for only wireless-ECN or ECN is interpreted by the source TCP as a new instance of congestion. 10. Security Considerations One disadvantages of Wireless-ECN mechanism is that Wireless-ECN message could be dropped by the network before reaching the TCP source. If the assumed source of data loss is not congestion, loss of Wireless-ECN will result in the failure of congestion control for that flow and a resulting increase in congestion in the network, ultimately resulting in subsequent packets dropped for that flow as the average queue size increased at the congested gateway. Since Wireless-ECN is added upon packet losses caused by congestion, subsequent packets dropped in the next congestion window may lead to another successive try to add WECN? With the possibility of additionally setting Wireless-ECN bit because of the previous lost WECN, it does not show performance problems from dropped Wireless-ECN message. In addition, the number of dropped WECN message should be small in the network since mulitiple WECN messages set immediately following each dropped packet provide robustness against the possibility of a dropped WECN packet in the bi-directional transmitting paths. In addition, dropping packets give the buffer time to vacate some space to hold and slow down data transmission, this ensures that the Wireless-ECN notification can be added even with multiple packet losses for transmiting rate would not exceed marking rate. The compliance of WECN in the network which ensures that once WECN is added in one router, the following routers may not erase the WECN bit in arriving packets also implicit the security of WECN. In spite of all these properties, we still give the security mechanism of WECN, we set a threshold to indicate when WECN should not be added, that is, when the buffer occupacy reduced below the threshold and there is no packet losses due to buffer overflow occures, WECN bit is kept from setting otherwise it is added continuously following the first WECN set immediately after buffer overflow. Considering WECN leads at least half reduction of congestion window size, we assume the threshold needed will not be loweer than fifty percent of buffer occupacy and it is better for the threshold set not higher than eighty percent of buffer size to ensure enough WECN generated. Since the threshold set for WECN is to determine when to stop adding it, it has little relationship with buffer management and is simple to implement. Additonally, WECN can also use the existing threshold set for ECN or other congestion avoidance mechanism if these mechanism are supported in the routers at the moment. Fei and Jain Experimental [Page 10] Draft-fpeng-wecn An Effective WECN Scheme August 1999 11. Support from ATM networks The investigation of WECN in this paper concerns only TCP and IP networks, we now consider a scenario of TCP traffic where part of or all of the path might consist of ATM networks. For ECN, the threshold set in ATM switch buffer to indicate congestion before buffer overflow can not get accessible way to inform the TCP connections of congestion, the only viable mechanism is for the ATM network to drop TCP or IP packets, either inside or at the boundaries of the ATM network. At the boundary of the ATM network where frame segmentation and reassembly occur, IP level of WECN mechanism could immediately add WECN to indicate congestion upon dropped TCP packet and invoke WECN mechanism for packets from WECN source. 12. Conclusions and Future Works With the incremental deployment of IETF proposed ECN in both end- systems and in routers, there exist many inconsistencies in the network and end-systems. For example, some routers may drop packets using the same RED policies for congestion detection while other routers set the CE bit for equivalent level of congestion. Some routers update its window once every two round-trip times while other sources increase the congestion window additional every round-trip time after equivalent threshold packets in the last window had the ECN bit set. Since active queue management is another complex research area in IETF, we change the mechanism of setting CE bit basing on the average queue length exceeding a threshold and propose to add Wireless-ECN just upon the first packet loss due to buffer overflow occurs. By doing this, inconsistent threshold judgment may not happen and no RED algorithm is required in the routers. The reduction of congestion window upon receiving the first Wireless-ECN prevents the discordance of different number of threshold ECNs chosen by end-systems with the IETF ECN usage. With all these consistency in the networks and end- systems, our mechanism not only improves TCP performance in wireless and mobile networks but provide a compatible way to enhance ECN performance across wireless pathes as well for it realizes distinguish different source of packet losses. The simulation in our project shows that WECN mechanism would give even higher throuput than ECN and ECN with WECN scheme because it hasten the rate of loss recovery phase which mainly due to congestion. Though in our simulation, we only utilize it in Tahoe TCP, it may obtain advantages if apply WECN in Reno TCP and further to New Reno TCP. Fei and Jain Experimental [Page 11] Draft-fpeng-wecn An Effective WECN Scheme August 1999 In other cases, though Wireless-ECN achieve quick retransmit lost packets mainly due to buffer overflow, sometimes the retransmission is invoked by non-congestion related reasons and because the loss of WECN though rarely occur, to find a better retransmission algorithm is also important for the drawbacks in the current Fast Retransmission and Recovery algorithm. To further analyze the benefits of Wireless-ECN for TCP and for ECN, continuous simulations must execute in the future works, which contains congestion in both directions, two-way traffic performance, and with multiple congested gateways. 13. Acknowledgments We would like to appreciate Beijing University of posts and telecommunicaitons for offering great advocacy of our research on this mechanism. We also thank Nokia coporation for supporting this idea with an applying of patent. And I (first author) will particularly mention my professor (Mrs. Cheng Shiduan) for the encouragement of my work. 14. References FEI, P., JIAN, M. "Overload control method for a packet-switched network", Patent Application NC 18254, June 1999. 2 FEI, P., Jian, M., etc. "TCP Performance Enhancements in Wireless and Mobile Networks", International Conference on Communication Technology (ICCT'98), Oct,1998, pp.S46-07-1:S46-07-5. 3 K. K. Ramakrishnan, Sally Floyd, "A proposal to add Explicit Congestion Notification (ECN) to IP", Internet Draft-kksjf- ecn-03.txt, Oct, 1998. 4 Sally Floyd, "TCP and Explicit Congestion Notification", Computer Communication Review, V.24 N.5, October 1994, p.10-23. 15. Author's Addresses Fei Peng Beijing University of Posts and Telecomm. Phone: 010-62282007 Email: fpeng@bupt.edu.cn Fei and Jain Experimental [Page 12]