As part of a broader organisational restructure, data networking research at Swinburne University of Technology has moved from the Centre for Advanced Internet Architecture (CAIA) to the Internet For Things (I4T) Research Lab.

Although CAIA no longer exists, this website reflects CAIA's activities and outputs between March 2002 and February 2017, and is being maintained as a service to the broader data networking research community.

ANGEL - Automated Network Games Enhancement Layer

Network Reconfiguration

Classification of network traffic and determining which network streams form real-time traffic and should possibly be prioritised is only the first part of the job. The next step is to perform some network re-configuration to enable better overall performance. The goal is to reconfigure some network devices to better maintain the performance of real-time applications (like network games), while at the same time not overly affecting the performance of other network applications.

On this page we outline the techniques with which we will be experimenting for the ANGEL project, including possible techniques for prioritising traffic, protocols that allow us to communicate the traffic classification information, and some potential problems that we need to consider.

Priority Queuing

One possible technique to improve the performance of real-time traffic in the presence of other network traffic is through the use of Priority Queues. A simple approach would be to enable two queues in the network device, incomming traffic is directed to the appropriate queue based on the output of the traffic classification algorithm running elsewhere in the network. The queue carrying real-time traffic is given a higher priority so that these packets can be routed before other (non real-time) packets that are queued at the router.

It is anticipated that one of the primary causes of network congestion and delay for real-time traffic is in the out-going router at the consumber premises (eg. the ADSL or cable modem). In this case packets arriving from the consumer computer/LAN are being restricted from a network speed of 10Mbps/100Mbps/1Gbps to the slower outgoing link speed - typically 128kbps-1Mbps. Given a scenario of multiple applications generating network traffic, it is feasible that the queues in this router can grow quickly.

By reconfiguring the CPE in real-time (based on information from external traffic classification) it is possible to configure the modem to route any incoming real-time traffic packet immediately (or at least before any queued non real-time packets). This will not greatly effect non real-time flows as their congestion avoidance algorithms will compensate for the available bandwidth, meanwhile real-time flows will not suffer as much from unpredictable queueing delays and the subsequent RTT (Round Trip Time) variation (network jitter).

Within the scope of the ANGEL project, we will be experimenting with different configurations queueing techniques and evaluation their performance in not only improving the throughput of real-time traffic and the subsequent network gaming experience, but also in minimising the effect on non real-time traffic and the throughput of other applications.

Link Layer Reconfiguration

While priority queuing can minimise the time that real-time packets must wait before being allowed to egress the router, if the router is presently outputting a non real-time packet, the real-time traffic must still wait until this other packet is first output. While this may appear to be a short time, on a slower upload link (say 128kbps) it can take some time to transfer a 1500 byte ethernet frame.

Many ADSL modems use ATM (Asynchronous Transfer Mode) as the underlying link-layer protocol. Other customer premises equipment may use similar techniques. In this instance it may be possible to take advantage of the ATM sub-structure and configure two virtual channels, one for classified real-time traffic and the other for all other traffic. If this is the case - and the ATM implementation is complete - then the individual 53 byte ATM parcels can be interleaved on the wire (to be reconstructed into the IP packet at the other end of the link). In this case it may be possible to route the real-time traffic even while other packets are being transmitted.

It is difficult to predict the success of this approach, this may depend on whether or not the ATM implementations in the modem can support this type of traffic routing. It will also be necessary to compare this approach with the methods used in Priority Queueing. It may also be possible to apply both techniques concurrently, if so the performance of this configuration needs also to be evaluated.

Protocols

In order for the network reconfiguration to take place at certain network devices, it is essential that these devices be informed about which traffic flows should be prioritised. Ideally we would not perform real-time classification within the modem/router, this would require available processing power as well as being difficult to upgrade. Instead we would like the traffic classification to be performed by dedicated machine(s) within the ISP network. This approach allows centralised upgrades to the traffic classification techniques and better compatability with older modem equipment.

This raises the issue of how the network devices are going to discover which network streams should be prioritised. In order to accomplish this, a suitable protocol must be devised that would allow a network monitoring agent to communicate with a network device and inform the routers which traffic flows should be prioritised. One of the key components of the ANGEL project will be to devise and implement an initial version of this protocol.

Potential Problems

There are a number of potential issues that come to mind immediately that could mitigate against the implementation of this type of system:

  • Choice - the user may not want the ISP to be monitoring their network traffic and re-configuring their modem. It is essential that this type of service be optional and configurable by the user
  • Security - The modem (and other network devices if the ISP also chooses to reconfigure internal routers) must be secured against malicious reconfiguration by other users. This will involve careful consideration of how the traffic classification communications protocol should be designed to provide this sort of protection
  • Abuse - Will it be a problem if the user configures his/her modem to prioritise other traffic. There is no benefit in prioritising all traffic as this will result in the same implementation as what is available now - all traffic being processed by one queue. It may be useful to aallow the user to specify which traffic they believe to be important and worthy of prioritisation, perhaps even allowing them to configure their own traffic classifier on the internal LAN
  • Timeout - How will traffic streams be "de-prioritised". There must be a means for network devices to remove traffic flows from the prioritisation list when they are not specifically mentioned in the traffic classification protocol. This will ensure that resources are not wasted on traffic flows that either no longer exists or are no longer real-time flows
  • Upgrade Path - Different consumer (CPE) devices will have difference capabilities, newer products may have better prioritisation techniques. This will have an impact in the protocol design to ensure that the protocol only communicates information about which flows to prioritise, not how to do so. This will allow the CPE to choose the best approach to maximise the performance gains. It will also allow older equipment to prioritise traffic using a best-effort approach (eg. less memory may mean that less active flows can be prioritised concurrently). This is also a factor that should impact on the protocol design to ensure that if only some flows can be prioritised that they are ranked in order of importance to maximise any potential gains

Other problems may also come up during evaulation and implementation of the ANGEL prototype. In this case these problems will be explored as they are discovered.

Last Updated: Friday 12-Oct-2007 08:13:44 AEST | Maintained by: Jason But (jbut@swin.edu.au) | Authorised by: Grenville Armitage ( garmitage@swin.edu.au)