Service (UNS) which will enable cross layer solutions while decoupling ULPs from .... Differentiated Services (DS) field (Type of Service field in. IPv4) of the IP ...
CL2009-2412
1
A Unified Notification Service Utilizing Explicit Wireless Degradation Notifications S. Fallon, P. Jacob, Y. Qiao and L. Murphy
Abstract— The dynamic characteristics of heterogeneous networks require cross layer solutions to optimize performance. Many cross layer solutions however, have tightly coupled Upper Layer Protocols (ULP) to lower layer performance metrics. Such an approach hinders the introduction of potential performance enhancements. In this paper we propose a Unified Notification Service (UNS) which will enable cross layer solutions while decoupling ULPs from lower layer performance metrics. UNS is designed as an open extensible framework to accommodate both existing and emerging notification plug-ins. UNS will also enable the integration of existing protocols to form new notification types. We illustrate how the general purpose solution provided by UNS can incorporate a new Wireless Degradation Notification (WDN) plug-in. We compare the performance of MAC layer retransmissions and Received Signal Strength (RSS) as network performance indicators, and illustrate that a retransmission based metric outperforms an RSS based approach. Index Terms— Cross-layer, SCTP, MAC Retransmissions
I. INTRODUCTION
H
ETEROGENEOUS networking has pushed protocols, which adhere rigidly to layer boundaries, to their performance limits. In [1] it is noted that standard congestion algorithms often perform in a suboptimal way resulting in low resource utilization. In earlier work [2][3] we presented results showing that excessive RTO for wireless paths causes standard SCTP to behave in a counterintuitive manner by significantly delaying path failover. While cross layer solutions may address such issues, the absence of a standardized approach is leading to the deployment of proprietary solutions which have tightly coupled ULPs to lower layer performance metrics. In this paper we propose a UNS which provides network components with a standardized notification mechanism for cross layer, transmission critical events. There are 2 significant areas of research for cross layer solutions (1) the selection of appropriate performance metrics used by ULP’s (2) the specification of actions for the ULP following the arrival of performance metrics. The focus of UNS is on (1). By abstracting the association between performance metrics and notification types UNS decouples ULPs from the implementation specifics of lower layer protocols. UNS is designed as an open extensible framework to accommodate both existing and emerging notification plugins. UNS will also enable the integration of existing protocols to form new notification types. Explicit Congestion Notification [4] has introduced alterations to IP and TCP specifically targeted at congestion notification. UNS can
easily integrate ECN as well as incorporating emerging notification types. Rate Control Protocol (RCP) [5] and Quick-Start [6] provide mechanisms by which end points can determine the capacity of a bottleneck link in an end to end association. Through UNS, RCP and Quick-Start may be provided with a standard “Bottleneck” notification indicating the link with the least capacity. The UNS architecture enables the easy integration of new notification plug-ins. Other potential notification types include; one way congestion notification, planned network maintenance notification and a Wireless Degradation Notification (WDN). This paper illustrates how the general purpose solution provided by UNS can incorporate a WDN plug-in. Through UNS, association endpoints are provided with explicit indications of wireless degradation. Results presented illustrate the importance of 802.11 MAC retransmissions over Received Signal Strength (RSS) as an indicator of wireless network performance. UNS enables a cross layer approach while decoupling ULPs from lower layer performance metrics. II. UNIFIED NOTIFICATION SERVICE Explicit notification mechanisms such as UNS can be implemented using notifications piggybacked with data traffic (in-band signaling) or using additional protocols (out-of-band signaling) [7]. For ease of deployment UNS utilizes an inband approach. Figure 1 outlines the UNS architectural components; a transport layer notification service responsible for notification coordination between peer endpoints, Notification Plug-Ins (NPIs) for the analysis of specific types of network degradation, performance metrics used by the Notification Performance Metrics (NPMs) to determine network conditions.
Figure 1. UNS System Components
CL2009-2412
2
We investigate the integration of UNS with SCTP [8] and IP. The SCTP packet format is easily extensible, consisting of a common header and chunks. The INIT and INIT ACK chunks which are used by SCTP to establish an association between peer end points contain mandatory and optional fields. We propose the introduction of an optional Type Length Value (TLV) field whose type is 32767. The TLV data element consists of a 32bit number where each bit set represents end point registration for a particular notification type. Using this TLV, end points can indicate their support for UNS as well as interest in multiple notification types. New chunks Unified Notification Service Echo (UNSE), field type 15 and a UNSE ACK, field type 16, will enable endpoints to inform their peers when notifications are indicated in received IP packets or by local analysis of NPM at the transport layer. Using the generic flag field the UNSE chunk will indicate the specific notification which has occurred using the same 32bit number sequence used in the INIT sequence. The value field will contain the parameters necessary for corrective action by the peer end point. Multiple notifications will result in multiple UNSE chunks. For IP we propose that association end points indicate their participation in UNS by setting the upper bit of the 8-bit IPv6 Differentiated Services (DS) field (Type of Service field in IPv4) of the IP packet header. The IP Options field is then populated to indicate the specific notification type(s) which are of interest. The Options field is variable in size and consists of a flag, class, number, length and data. The first 32 bits of data are set bitwise by the endpoints to request notification types. The next 32 bits of data are set by the router, based on lower layer NPM, to indicate to the UNS to generate a particular notification type. Additional bits may be used to communicate specific data for a notification to the end points. For example, a bottleneck notification would include the capacity of the bottleneck link. Figure 2 illustrates the UNS packet sequence for WDN.
Figure 2. UNS Packet Sequence
As part of the SCTP association establishment Endpoint 1 informs its peer Endpoint 2 that it is UNS enabled by utilizing the optional UNS TLV field with type 32767. In Figure 2 the second least significant bit is set to request WDN. Endpoint 2 responds with an INIT ACK with corresponding values thereby indicating its registration for WDN. Endpoint 2 generates IP packets; in the IP headers optional field the second least significant bit of the first 32 bits of data is set to request WDNs. Later when wireless degradation occurs, the access point sets the second least significant bit of
the second 32 bits of data in the optional field. When Endpoint 1 receives the IP packet it notifies Endpoint 2 using the SCTP UNSE Chunk. Endpoint 2 confirms the reception of the notification using the UNSE ACK chunk. III. WIRELESS DEGRADATION NOTIFICATION This section describes a WDN plug-in which, through UNS, explicitly informs association endpoints of wireless degradation. Our algorithms use RSS and the percentage of 802.11 MAC retransmissions to identify network degradation. Using experimental and simulated evaluations we illustrate how such algorithms trigger WDN events which can be used by ULP such as Mobile SCTP for path selection. A. Wireless Degradation Notification Algorithm For some time RSS has been used as a primary indicator of wireless performance. In recent years MAC layer retransmissions have also been suggested as a suitable performance indicator [3][9]. We compare the performance of these metrics for the WDN algorithm. We normalize the NPM on the scale 0, best performance, to 100, worst performance. We calculate the percentage of retransmitted packets per interval. For RSS the normal operating interval is from 10dbm to -90dbm. In order to smooth the occurrences of RSS and MAC retransmissions we implement an exponentially weighted moving average defined as follows: ysmooth k = ysmooth k −1 +α ( y − ysmooth k −1 ) (eq 1) The degree of weighing is expressed as a constant smoothing factor α, whose value is between 0 and 1. Finally we implement a switch decision by applying performance boundaries θ and σ to the value ysmoothk calculated for both percentage retransmissions and RSS. We evaluate the following switch conditions: ( Rtranssmooth k > θ ) (eq 2)
( RSSsmooth k > σ ) (eq 3) B. Experimental Dimensioning of Wireless Degradation An experimental test configuration was created which consisted of two Laptops configured with SCTPLIB [10] representing a Mobile Node (MN) and a back end server connected by a Linksys WRT54GL 802.11g access point. The client laptop used Wireshark with AIRPCAPs 802.11 plug-in for wireless packet capture. The client also used Netstumbler to record wireless signal strength. The MN started adjacent to the access point and then moved directly away. The test was repeated multiple times and a representative test was selected for further investigation. For the intervals 0-50, 51-100, 101150, 151-200, 201-250 and 251-280s the average RSS was 34, -60.92, -68.68, -70.5, -78.7 and -85.5 dBm respectively. For the corresponding period the average percentage retransmissions were 6%, 11%, 15%, 21%, 70% and 76%. Fig 3 illustrates the normalized values for both NPM. We see that RSS has generally linear performance degradation while the percentage retransmissions have significant performance degradation at approximately 200s. Using eq 1 we smooth both NPM with α values ranging from .025 to .25 in steps of .025. Fig 3 illustrates the smoothed values for the highest (.025) and lowest (.25) degree of smoothing.
CL2009-2412
3 During this period RSS degrades in a generally linear manner from -60dBm to -75dBM. The best performing tests, based on percentage retransmissions, α=.25 θ=.2 initiates a failover to the alternate path at 115 secs, a return to the primary at 128 and finally a final failover to the alternate at 184s. The results indicate that while RSS gives the general performance trend for the path, percentage retransmission gives a more specific indication of performance. The relevance of retransmissions as a performance metric has been highlighted in [3][9]. Many ULPs still utilize RSS as an indicator of path performance. UNS decouples such ULPs from specific lower layer NPM, enabling the notification plug-in to transparently implement performance enhancements.
Figure 3. Scaled and Smoothed Performance Metrics
The α values .025, .125 and .25 results in average standard deviation of 8.32, 1.92 and 1.09 for RSS and 8.05, 4.3 and 3.42 for percentage retransmissions. Using these values of α we evaluate various switch decisions for θ and σ .
Accumulated Data Transmitted (MBytes)
C. Simulated Evaluation of the WDN Algorithm In this section we use the results of the analytical study from Section B to analyze the optimal configuration of α , θ and σ. We create an NS2 [11] simulation which utilizes [12]. The network topology consists of an 802.11 primary path together with a 3G mobile alternate path. The alternate path was configured with 2MBit capacity and a 2.5% loss rate. We use the α values .025, .125 and .25 from the analytical study. For RSS, -85dBm is generally indicated as a point of significant performance degradation. The scaled RSS performance value corresponding to -85dBm is 93.75, therefore for RSS we evaluate σ values of .9, .8 and .7. For θ we evaluate the values .1, .2 and .3. Results indicate that α=.25 θ=.2, α=.125 θ=.2 and α= .125 θ=.3 had the best performance transmitting 10.26, 10.0 and 9.93 Mbytes respectively. The best performing RSS based strategy was α=.025, σ=.7 which transmitted 9.82Mbytes of data. Figure 4 illustrates the accumulated data transmitted for the 2 best performing tests for each performance metric for the period 100-180s. Before 100s all the tests have generally equivalent performance. 11 10 θ =.2 α=.2 5 9 θ =.2 α=.1 2 5 8 σ= .7
α = .0 25
7 σ=.7 α=.1 2 5 6 SCTP PMR=0
5 100
120
140
160
180
200
220
240
260
280
Test Time (Secs)
Figure 4. Accumulated Data Transmitted 100-180s
Figure 4 illustrates an improved performance of percentage retransmissions over RSS. We therefore suggest that retransmissions rather than RSS be used as the primary indicator of network performance. In Figure 3 we see a general increase in percentage retransmissions from 100-160s.
IV. CONCLUSIONS AND FUTURE WORK The technical challenges of heterogeneous networking have resulted in the deployment of cross layer solutions which have tightly coupled ULPs to lower layer performance metrics. The result of such tight coupling is two fold; it hinders the introduction of technical enhancements at the lower layers, vendors are deploying non standardized cross layer solutions. In this paper we propose UNS which enables cross layer interaction while decoupling ULPs from lower layer performance metrics. UNS is an extensible framework which can incorporate existing and emerging notification plug-ins. Results illustrate how a new WDN plug-in, using MAC layer retransmissions rather than RSS, as the primary indicator of network performance can be integrated into the UNS framework. Future work will analyze the performance of WDS in varying WLAN network conditions. It will also investigate the integration of UNS with other transport layer protocols and the deployment of additional notification plug-ins. REFERENCES [1]
“Open Research Issues in Internet Congestion Control”, Work in Progress draft-irtf-iccrg-welzl-congestion-control-open-research-05.txt [2] Fallon, S, Jacob, P, Qiao, Y, Murphy, L, “SCTP Switchover Performance Issues in WLAN Environments”, 5th IEEE Consumer Communications and Networking Conference (CCNC) 2008, Issue 1012 Jan. 2008 Pages 564 - 568 [3] Fallon, S, Jacob, P, Qiao, Y, Murphy, L, Hanley, A, “Using 802.11 MAC Retransmissions For Path Selection in Multi-homed Transport Layer Protocols”, to appear in proceedings of IEEE Globecomm 2009 [4] RFC 3168, “The Addition of Explicit Congestion Notification (ECN) to IP” September 2001 [5] Dukkipati, N, Kobayashi, M, Zhang-Shen, R, Mc Keown, N, "Processor Sharing Flows in the Internet", Proceedings of the International Workshop on QoS (IWQoS'05), June 2005. [6] RFC 4782, “Quick-Start for TCP and IP”, January 2007 [7] "Transport-layer Considerations for Explicit Cross-layer Indications", Work in Progress, draft-sarolahti-tsvwg-crosslayer-01.txt, March 2007. [8] R. Stewart, Q. Xie et.al. Stream Control Transmission Protocol, RFC 4960, Sep. 2007 [9] Tsukamoto, K, Kashihara, S, Oie, Y, “A Unified Handover Management Scheme Based on Frame Retransmissions for TCP over WLANs” IEICE Transactions on Communications, 2008 [10] SCTP library (sctplib), version sctplib-1.0.5 www.sctp.de [11] UC Berkeley, LBL, USC/ISI, and Xerox Parc: ns-2 documentation and software, Version 2.29, Oct. 2005, www.isi.edu/nsnam/ns. [12] A. Caro, et al : ns-2 SCTP module, Version 3.5, www.armandocaro.net/software/ns2sctp/