incoming VPN connections

Here, we present some preliminary measurement results from our ,prototype. The network set-up for the measurement is shown in ,Figure 7. We have used NetIQ's Chariot for the measurements. ,Basically, the server provides both FTP and video (with 1.448 ,Mbps CBR streaming over RTP/UDP) services to a client across ,an AP implementing the dual queues. The console is the entity ,needed for Chariot in order to measure the network performance.  ,Figure 7. Network set-up for the experiments ,Table 3. Performance comparison between the original AP ,and a modified AP with two queues ,Comparison  ,Original ,Two ,queue ,Gain ,TCP 3.851  3.703  -3.84%,Throughput ,RTP 1.448  1.448  0.00%,Avg. 2.9  2.6  -10.34%,Max. 4.0  3.0  -25.00%,Jitter of ,RTP ,Min. 2.0  2.0  0.00%,Avg. 30.7  20.2  -34.20%,Max. 32.0  23.0  -28.13%,One-way ,delay of ,RTP ,Min. 30.0  18.0  -40.00%,Table 3 shows the measurement results for a number of ,performance parameters. First of all, we observe that the one-way ,delay of RTP (or RT traffic) is reduced by over 30%. This at least ,verifies that our goal is achieved via this simple modification of the device driver. The jitter of RTP is a bit improved as well. In ,case of throughput, we observe that there is no change with the ,RTP throughput as it should be is the case with a CBR traffic, but ,the TCP (or FTP traffic) throughput is a bit reduced. We predict ,that this happens due to an increased delay of the FTP traffic out ,of the priority queuing of the modified device driver.  ,4.4 Limitations and Future Work ,The priority queuing implemented currently achieves a ,prioritization among different types of frames, thus achieving a ,lower delay for RT traffic. However, this approach is limited in a ,number of ways. First, even if there are dual queues in the device ,driver, there is a single FIFO inside the MAC controller, and we ,cannot do any scheduling of the frames once a frame is forwarded ,to the MAC controller. Second, for the actual medium contention, ,every device including the AP contends in a fair manner based on ,the 802.11 CSMA/CA. Therefore, for example, a RT frame in an ,AP and a NRT frame in a terminal contend with the same channel ,access rule. Accordingly, in certain situations, the performance of ,the proposed scheme will be severely compromised. For example, ,if a terminal transmits a large amount of data, the scheduling ,within the AP explained above may not be that effective. ,Currently, we are investigating a class of algorithms to handle this ,problem.  ,Independent from the scheduling algorithm itself, we need more ,experiments as well. For example, we will need to check the VoIP ,performance with more contending terminals. Once we are ,assured that a reasonable performance based on this software ,queue implementation is achieved, we are planning to implement ,this approach into the existing APs of NESPOT to enhance the ,VoIP services as well as a potential VoD service.,