ANGEL - Automated Network Games Enhancement Layer
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.
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
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
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.
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
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.
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
- 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.