Cooperative Self-optimisation of Network Protocol Parameters

at Runtime

Sven Tomforde

, Jan Kantert

, Sebastian von Mammen

and J

org H

ahner

Organic Computing Group, University of Augsburg, Eichleitnerstr. 30, 86159, Augsburg, Germany

SRA Group, Leibniz Universi

at Hannover, Appelstr. 4, 30167, Hannover, Germany

Keywords:

Organic Computing, Intelligent System Control, Evolutionary Algorithms, Collaboration, End-to-End

Communication.

Abstract:

Network protocols are deployed in highly dynamic environments, but typically conﬁgured with a static setup

of conﬁgurations. The Organic Network Control system (ONC) has been developed to alter protocol con-

ﬁgurations at runtime. ONC is equipped with online learning capabilities and safety considerations. This

paper presents a ﬁrst TCP-based study on how this approach can be applied to end-to-end protocols and si-

multaneously alleviating the drawbacks of a simulation-based optimisation procedure. The paper explains the

developed algorithm and demonstrates the beneﬁt of the solution in an Omnet++ scenario.

1 INTRODUCTION

Large-scale data communication networks – such as

the Internet – have experienced a dramatically in-

creasing volume of data within the last decade. As a

result, great efforts have been made towards improv-

ing the performance of the utilised protocols. Simul-

taneously, more efﬁcient technologies have been in-

vestigated. One approach that researchers have fol-

lowed is context-aware adaptation of protocols and

their parameter conﬁgurations. The basic idea is

to introduce “life-like” properties in communication

– meaning that self-adaptation and learning compo-

nents allow for highly robust and evolving solutions.

Previous work introduced the Organic Network

Control (ONC) approach (Tomforde and H

ahner,

2011), which adapts protocol parameter settings dy-

namically and without the need of human interven-

tion. ONC works well for protocols with a local im-

pact, e.g., mobile ad-hoc networks, which is caused

by pure local knowledge and decisions. In order to

shift the focus towards system-wide decisions, we

introduce a novel concept to cooperatively optimise

these parameters. To this end, we discuss a ﬁrst TCP-

based study and evaluate the beneﬁts of the solutions.

The remainder of this paper is organised as fol-

lows. Section 2 describes ONC and related work. Af-

terwards, the novel cooperative approach to replace

ONC’s rule-generation component is introduced, ex-

emplarily showing adaptation of TCP/IP parameters

(Section 3). We discuss our experimental results in

Section 4. Finally, Section 5 summarises the paper

and gives an outlook to future work.

2 STATE OF THE ART

In this section, we ﬁrst outline the workings of ONC.

Second, we reference the amalgamation of its under-

lying mechanisms and inspirations.

2.1 Organic Network Control (ONC)

The goal of ONC is the integration of Organic

Computing (OC) (M

uller-Schloer, 2004) principles

into existing network protocols, including self-

organisation, self-optimisation, adaptivity, and ro-

bustness. ONC achieves this goal by automatic adap-

tation of network protocol parameters to environmen-

tal conditions. Thus, ONC strongly deviates from

most established protocol implementations that main-

tain constant values for the respective parameters.

Figure 1 shows the layout of an OC architec-

ture, i.e. the Multi-Layer Observer/Controller archi-

tecture (Tomforde et al., 2011b). In the context of

the ONC system, the System under Observation and

Control (SuOC) at Layer 0 represents one individual

network protocol instance that runs on a particular

host. Layer 1 contains an observer and a controller

123

Tomforde S., Kantert J., von Mammen S. and Hähner J..

Cooperative Self-optimisation of Network Protocol Parameters at Runtime.

DOI: 10.5220/0005520701230130

In Proceedings of the 12th International Conference on Informatics in Control, Automation and Robotics (ICINCO-2015), pages 123-130

ISBN: 978-989-758-122-9

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

Layer 3

Layer 0

User

System under Observation

and Control (SuOC)

Layer 1

Parameter Selection

Observer

Controller

Learning

Component

Layer 2

Offline Learning

Observer

Controller

Simulator

Opt. heuristic

Collaboration Mechanisms

Monitoring Goal Mgmt.

Figure 1: Multi-layered Observer-Controller Architecture.

component. The observer component is responsible

for monitoring the SuOC’s status and its environment

and generates a situation description from the current

observations. This is passed to the controller com-

ponent. Based on this data, the controller decides

whether and which changes should be introduced into

the system. In addition, the current system description

is used to reward any previous decisions’ successes

or to punish their failures, respectively. Making the

right decisions and reinforcing the knowledge-base is

typically realised by a modiﬁed Learning Classiﬁer

System, see (Prothmann et al., 2008). Due to safety

and performance reasons, the online learning system

is not allowed to generate novel behaviour – instead,

it works on existing rules. In case of missing knowl-

edge, i.e. if no decision can be made regarding the cur-

rent situation, new rules are generated by Layer 2. In

particular, it ﬁnds the best possible action for a given

situation by means of a simulator and an according

optimisation component. Finally, Layer 3 provides an

interface to the user and to neighbouring systems.

ONC has been applied to different types of net-

work protocols, including reliable broadcast algo-

rithms for mobile ad-hoc networks (Tomforde et al.,

2011a), mode-selection protocols for wireless sensor

networks (Tomforde et al., 2010), and Peer-to-Peer

protocols (Tomforde and H

ahner, 2011).

2.2 Related Work

ONC is a representative of decentralised approaches

to adapt network protocols. Several related ap-

proaches can be found in the literature that are speciﬁc

to certain protocol implementations, whereas ONC

is applicable to network protocols with variable pa-

rameters in general. For instance, Su et al. describe

a mobility-adaptive self-parametrisation of different

unicast and multicast routing protocols in the MANet-

domain – depending on a positioning system. Boleng

determines mobility by locally analysing the observed

neighbourhood. Considering the average link du-

ration as mobility metric, he uses the received val-

ues to control data routing in the so-called Adaptive

Location Aided Routing from Mines protocol. Fi-

nally, Stanze et al. describe a system for mobility-

adaptive self-parametrisation of a routing protocol in

MANets. To this end, they measure mobility by us-

ing the MANET Relative Velocity Indicator protocol.

These approaches are only feasible in the MANet-

domain as they work directly on the mobility aspect.

Further concepts for self-conﬁguration are already

considered in the design of protocols. Examples

are the congestion avoidance mechanisms in TCP

(Martin et al., 2003) and the collision detection for

Ethernet-protocols (Kleinrock and A.Tobagi, 1975).

Considering adaptivity aspects within the protocol

logic has drawbacks: The logic has to be changed

and a cooperation with standard non-adaptable pro-

tocols might not be possible (besides further aspects

such as limited re-usability, limitation to only one pur-

pose). Again, this results in problem- and protocol-

speciﬁc solutions without the possibility of a gen-

eralised approach. The self-conﬁguring approaches

outlined above have in common that individual net-

work nodes can adapt based on locally available

information. In contrast to such decentralised ap-

proaches, systems have been investigated where one

central, network-wide instance concerts parameter

changes. The most prominent examples have been

presented by Ye et al. (Ye and Kalyanaraman, 2004)

and Georganopoulos and Lewis (Georganopoulos and

Lewis, 2007). Closely related is the concept of pro-

tocol stack composition, which aims at providing a

more general solution to adapting protocol parame-

ters. Instead of interfering with the protocol logic,

protocol stack composition allows to switch between

protocols and stacks dynamically (Rosa et al., 1997).

Several different systems have been developed – pop-

ular representatives are Appia (Miranda et al., 2001)

and Horus (van Renesse et al., 1996). Here, protocols

with static settings are selected on demand from a pre-

deﬁned set of solutions without any chance to extend

it at runtime. Furthermore, they rely on a centralised

element to observe and, if need be, reconﬁgure the

protocol stack for the whole network. Due to central-

isation, challenges arise such as additional bandwidth

usage and a single point of failure.

3 COOPERATIVE PARAMETER

OPTIMISATION

The ONC approach as introduced in Section 2.1

works well for protocols with a local impact. In

ICINCO2015-12thInternationalConferenceonInformaticsinControl,AutomationandRobotics

124

particular, this means that altering protocol parame-

ters has mainly a local focus, which is e.g. the case

for MANet protocols. Besides the potential beneﬁt

demonstrated in previous work (see e.g. (Tomforde

and H

ahner, 2011; Tomforde et al., 2010)), the con-

cept has drawbacks that restrict its applicability. For

instance, we rely on the existence of a simulation

model that a) approximates reality very accurate and

b) models the behaviour independently of all other

nodes in the network. Especially for protocol al-

gorithms that have more than just a local inﬂuence,

the simulation-based rule-generation approach is lim-

ited in ﬁnding the desired behaviour. One example

of previous work, where such a drawback has been

observed is the control of the Peer-to-Peer client Bit-

Torrent (Tomforde and H

ahner, 2011). Besides these

concept-inherent limitations, processing time is an-

other drawback. Simulation-based optimisation ap-

proaches are time-consuming.

In general, there are two different approaches to

counter these limitations. The ﬁrst is the pure ma-

chine learning idea: Neglecting safety considerations,

one could deactivate the Layer 2-based rule genera-

tion and equip Layer 1 with an exploration mecha-

nisms. In particular, the Learning Classiﬁer System

of Layer 1’s controller could be implemented as a

standard eXtended Classiﬁer System (XCS) (Wilson,

1995). Besides the safety-aspects, this approach is

problematic due to the extremely long convergence

durations. Additionally, bad protocol parameter set-

tings (i.e. a result of machine learning) affect the com-

munication ability in such a way that the system might

get trapped in a non-communicating state. As a result

of these consideration, such a solution is not feasible.

The alternative is to replace the simulation-based

solution by other mechanisms. Since simple con-

cepts such as approximation or computation of op-

timal settings are not available for network parame-

ter estimation, we replaced the simulation-based rule-

generation by a context-dependent cooperative solu-

tion. The idea is to get rid of the simulation model

and try possible behaviour directly in the real system

– but still consider safety.

3.1 Modiﬁcation of the ONC

Architecture

In general, there is signiﬁcant work available on opti-

mising TCP parameters and techniques. For instance,

Nichols and Jacobsen summarise a set of solutions for

most of the current TCP problems (Nichols and Ja-

cobson, 2014). Furthermore, Dukkipati et al. already

presented a solution for TCP’s “slow-start” problem,

which is also addressed by our approach (Dukkipati

et al., 2010). Within this paper, TCP serves as an ex-

ample for connection-oriented protocols and conse-

quently as use case for out experiments. The general

idea is transferable to similar protocols – we therefore

neglect a deeper comparison with comparable TCP

modiﬁcations.

Layer 0: In order to be able to adapt the TCP/IP host

to changing conditions, Layer 0 needs the possibility

to access variable parameters and to monitor the cur-

rent situations. According interfaces have been im-

plemented. Details on implementation parameters are

given in the context of the simulator (see Section 3.3).

Layer 1: The parameter conﬁguration loop of Layer 1

consists of an observer and a controller component.

The observer derives a situation description from the

SuOC’s accessible attributes. In the TCP/IP setting,

we use the following situation description:

1. The (averaged) duration of a TCP connection

from or to this host.

2. The (averaged) number of TCP connections that

are open simultaneously.

3. The (averaged) round-trip time per packet.

4. The particular physical medium used as basis for

the communication (e.g. WiFi or Ethernet).

5. The maximum transmission rate for the current

connection (e.g. 100Mbit/s).

Based on this situation description, the controller

performs two tasks: a) evaluate the success of the

last action and b) choose the next action. We imple-

mented Layer 1’s controller as a modiﬁed variant of

Wilson’s eXtended Classiﬁer System (Wilson, 1995)

(see (Prothmann et al., 2008) for details). We measure

the system’s performance as the throughput without

overhead (“goodput”). I.e., we measure the round-trip

time of packets and estimate the throughput based on

the packet size and the considered period. From this

accumulated value we subtract the overhead.

In order to have a normalised reference value, we

calculate the round-trip time as given by Equation 1.

Thereby, the abbreviation RTT speciﬁes the (aver-

aged) round-trip time – the index c refers to the cur-

rently observed one, max to the maximal observed

one, min to the minimal observed, and n to the (ﬁ-

nally) normalised value. As a result of this normalisa-

tion, RTT

is within the interval [0, 1]. In addition, the

actual value within this range is adapted in relation to

the possible value for maximum and minimum.

RT T

= 1 −

(RT T

−RT T

min

)

(RT T

max

−RT T

min

)

(1)

Layer 2: The most important modiﬁcations to ONC

are concerned with the rule-generation component.

Again, this component consists of an observer and

a controller part. In case of periods of inactivity or

low resource utilisation, parts of the bandwidth can

CooperativeSelf-optimisationofNetworkProtocolParametersatRuntime

125

be used to cooperatively optimise parameter settings.

This is the task of the observer-controller tandem on

Layer 2. In contrast to the previous architecture as de-

picted in Figure 1, no simulation tool is available nor

necessary, and it is therefore replaced by a component

that is responsible for: a) ﬁnding cooperation part-

ners, b) generating (test) trafﬁc to utilise the band-

width, and c) cooperatively optimising the parameter

settings for both ends of the TCP connection using a

heuristic. For part c), the same optimisation approach

as used for ONC’s Layer 2 (see Section 2.1) can be

applied. The other two aspect are described in detail

in the next subsection.

Layer 3: The third layer of the architecture encap-

sulates the collaboration and cooperation with other

entities, as well as with the user. It maintains and up-

dates a list about available neighbours. This list serves

as set of potential cooperation partners. Details are

given in the remainder of this section.

3.2 Cooperative Self-optimisation of

Protocol Parameters

Our proposed self-optimisation approach consists of

two parts: a) identify cooperation partners and estab-

lish a test-connection with adaptable TCP parameters

(this assumes that all hosts run the same TCP imple-

mentation and access the same parameters using the

same names), and b) ﬁnd the best setting for the spec-

iﬁed conditions.

a) Cooperation Partners: Hosts are assumed to

be aware of other hosts within their vicinities – e.g.

due to observing addresses in TCP packets transmit-

ted over the physical medium. Hence, each host main-

tains a list of potential cooperation partners. Can-

didate partners have to be selected from this set.

Thereby, different strategies are possible, e.g.: a) a

random selection, b) the last communication partners

of TCP connections established by or to the speciﬁc

host, c) hosts that will most probably be the next

communication partners, and d) hosts that exhibited

bad/good RTTs in the past. We decide to keep the

approach as simple as possible and therefore choose

random selection. In addition, two restrictions have

to be considered: 1) the candidate partner does not

run an ONC module and 2) the candidate partner re-

fuses to cooperate (e.g. due to over-utilisation). Both

restrictions are covered by introducing a time-out and

then starting the selection process again. Those not

answering are further put on a blacklist.

b) Optimisation Process: After selecting part-

ners, the cooperative testing of parameter settings is

initialised. We distinguish between an active and a

passive role: The requesting host is active and there-

fore responsible to generate candidate parameter set-

tings and set up test trafﬁc. The other cooperation

partner is passive and applies the requested parame-

ters for a given time interval. During this period, it

accepts the incoming TCP connections of the active

host, accepts the data (and deletes it), and observes

the situation. Within such an evaluation cycle, one pa-

rameter set can be evaluated by the active host. This

loop – testing a variety of candidate parameter sets –

is processed until a stop criterion is reached (i.e. num-

ber of maximum cycles or no improvement for a spe-

ciﬁc number of cycles). In order to generate candidate

parameter sets to be tested, we used an Evolutionary

Algorithm working on a bit string representation. As

test data, we use a randomised html-trafﬁc generator

as available in the simulator and conﬁgure it with the

requested conditions (i.e. number of open TCP con-

nections, available bandwidth, etc).

The bit string encoding the candidate solution

consists of the 10 parameters listed in Table 1.

Thereby, the ordering in the string reﬂects the order-

ing in the table and the number of bits used per param-

eter is given in the third column. Based on this string,

the genetic operators I) selection, II) crossover, and

III) mutation are applied. For I), we use a probability-

based selection of candidates within the population

(meaning from the set of known rules). The proba-

bility of becoming a parent becomes higher with in-

creasing performance. The second aspect – cross-over

– decides how the new candidate is generated: either

by combining the two selected parents or randomly.

Typically, EAs are conﬁgured with a high cross-over

probability (meaning to utilise selection). Therefore,

we set this parameter to 0.95. The operator splits both

bit strings of the parents at one (randomly chosen)

point and recombines them while switching the ends

(one-point-cross-over). Alternatives include variants

of two- and more-point cross-over. Finally, additional

randomness comes in with the mutation parameter

(III). Mutation introduces more exploration capabil-

ities, but high probabilities will mislead the process

towards random search behaviour. Hence, the muta-

tion probability is set to a low value (i.e. 0.1).

c) Optimisation Protocol: Standardised TCP

messages specifying the request for cooperation, the

acknowledgement/reject, and the transmission of the

candidate parameter sets have been deﬁned to allow

the possible partners to understand each other.

3.3 Implementation in Omnet

Each host in Omnet (i.e. its TCP instance) serves

as SuOC according to the ONC architecture. Upon

each of these SuOCs, ONC is set up according to

ICINCO2015-12thInternationalConferenceonInformaticsinControl,AutomationandRobotics

126

the modiﬁed architecture (see Section 3.1). We used

the Omnet++ network simulator (Varga, 2001) as ba-

sis for the development and evaluation. Omnet++ is

a standard tool in network protocol simulation and

has been widely used in academia and industry. We

implemented the SuOC as instance of the Standard-

Host module in the INET-Framework (INET Project,

2014) of Omnet++. This module realises the TCP/IP

protocol stack and can easily be connected to a net-

work within the simulator. The sub-modules con-

taining the particular functionality of the TCP and

IP layers are conﬁgured at simulation start-up using

NED-parameters (i.e. special variables belonging to

one module; NED is Omnet’s control language). Ini-

tially, these parameters are set using standard conﬁg-

urations, but they can be altered individually – which

is important to simulate the desired behaviour.

Table 1: TCP parameters, standard conﬁguration (INET),

and number of bits for encoding in the optimisation process.

Parameter Value Bits

mss 536 10bits

advertisedWindow 14 ×mss 5bit

tcpAlgorithmClass TCPReno 2bit

delayedAcksEnabled false 1bit

nagleEnabled true 1bit

limitedTransmitEnabled false 1bit

increasedIW Enabled false 1bit

sackSupport false 1bit

windowScalingSupport false 1bit

timestampSupport false 1bit

Table 1 lists the available TCP parameters of

the StandardHost module. Thereby, mss refers

to the maximum segment size (see RFC 793),

advertisedWindow refers to the maximum size of the

buffer for incoming messages, tcpAlgorithmClass

is used to select the desired TCP variant (TCPReno,

TCPNewReno, TCPTahoe, TCPNoCongestionCon-

trol, or DumpTCP), delayedAcksEnabled enables

or disables the delayed ACK-algorithm (see RFC

1122), nagleEnabled chooses to use the Nagle-

algorithm (see RFC 896), limitedTransmitEnabled

activates the Limited-Transmit-algorithm (avail-

able for TCPReno, TCPTahoe, TCPNewReno,

and TCPNoCongestionControl, see RFC 3042),

increasedIW Enabled controls the Increased Initial

Window (see RFC 3390), sackSupport activates

the support for selective acknowledgments (is

automatically used if both endpoints support

this option, see RFCs 2018, 2883, and 3517),

windowScalingSupport activates the support for

window scaling (is automatically used if both end-

points support this option, see RFC 1323), and ﬁnally

timestampSupport activates the support for times-

tamps (see RFC 1323). We decided to use all of these

parameters and not just the set of most promising

ones, since we wanted the system to automatically

ﬁgure out the impact of each particular parameter.

4 EVALUATION

This section evaluates the potential beneﬁt of the pre-

viously explained approach. Therefore, simulations

within the network simulator Omnet++ (Varga, 2001)

have been performed.

4.1 Experimental Setup

In order to simulate the cooperative parameter optimi-

sation mechanism, we implemented the approach as

described in Section 3.3 directly in Omnet by deﬁning

new modules. Afterwards, we set up a test network

that consists of two hosts (cli0 and cli1) running the

ONC approach and communicating with each other.

A third component (srv) provides content and does

not understand the ONC messages. We also tested

the approach in simulations of larger networks (i.e. 5,

10, and 20 hosts). Since the results are comparable to

those of this simple setting, we neglect this informa-

tion in the context of this paper.

4.2 Experimental Results

We start the evaluation with an investigation of the

underlying ﬁtness landscape for the parameter space.

Afterwards, the learning behaviour at runtime of the

developed solution is analysed. This is done in com-

parison to the usage of standard TCP parameters

available in Omnet++ (which are already a near-to-

optimal conﬁguration, see ﬁtness landscape). Finally,

the individual results for exemplary simulation runs

are generalised by deriving averaged values over dif-

ferent scenarios with varying conditions.

Buffer Size

Max. Segment Size

Fitness (higher values are better)

Figure 2: Fitness Landscape.

CooperativeSelf-optimisationofNetworkProtocolParametersatRuntime

127

4.2.1 Fitness Landscape

Initially, we analysed the underlying ﬁtness landscape

for the optimisation problem. For better illustration,

the following section focuses on the two most im-

portant parameters: (a) maximum segment size and

(b) buffer size). We set up a simulation in Omnet++

without ONC module – it contains just the simulated

client and server components. The simulation covers

one complete day (i.e. 24 hours). As a result, Fig-

ure 2 visualises the relation between the two param-

eters: smaller values for the maximum segment size

and higher ones for the buffer size are better. In gen-

eral, the ﬁtness landscape describes an almost ﬂat and

smooth surface – meaning that the optimisation is a

minor complex problem. Taking further parameters

into account makes the optimisation problem more

complex. Especially the true/false decisions for en-

abling or disabling certain functionalities results in

hard breaks in the landscape (difﬁcult to optimise).

4.2.2 Online Learning Behaviour

In order to simulate the online learning behaviour and

the success over time, we simulated ﬁve consecutive

days in Omnet. Both clients randomly access web-

sites at the server component. One of the clients (we

refer to this as “passive” – i.e. cli1) keeps its standard

TCP conﬁguration during operation – this means that

it does not activate its ONC-based parameter adapta-

tion mechanism during normal operation. This is only

done in case of incoming requests for cooperative op-

timisation by the other client.

Layer 2

Layer 1

Simulated time

Fitness of the active rule

Figure 3: Change of the ﬁtness of the active rule over time;

starting with a bad parameter setting.

The active client (i.e. cli0) simultaneously ex-

ecutes the ONC component – it evaluates its be-

haviour and adapts the parameter settings using ONC.

Thereby, it starts the cooperative optimisation in case

of missing knowledge or unsatisfying performance.

Initially, the active client starts with an empty rule

base – meaning there is no prior knowledge or any

information about the desired parameter settings.

The goal for the active client is to ﬁnd well-

performing parameter settings – without any initial

information. As starting conﬁguration we chose bad

settings according to the ﬁtness landscape character-

isation depicted in Figure 2 – in particular, we iden-

tiﬁed one of the “deepest” valley (i.e. mss = 40,000

and bu f f er = 20, 000).

Figure 3 illustrates the achieved results for the ac-

tive client. Thereby, the ﬁgure distinguishes between

Layer 1 (blue line) and Layer 2 (red line). The values

have been accessed at the begin of each new parame-

ter set being active and at the end. From this ﬁgure it

is visible that the start parameter conﬁguration is far

from being optimal, values for the ﬁtness between 0.9

and 1.0 can be observed. The theoretic optimum in

this scenario (which depends e.g. on the channel char-

acteristics) is

√

2, meaning about 1.414. The perfor-

mance of Layer 2 quickly approaches values between

1.0 and 1.2 that further improve to values between 1.2

and 1.3 during the simulation.

The randomised trafﬁc generation pattern resulted

in the highest load within the ﬁrst 12 hours of the ﬁrst

day. Afterwards, the ONC component of the active

client recognises that no trafﬁc is observed (i.e. there

is the possibility to ﬁnd new parameter settings) and

the current setting seems to be non-optimal (i.e. far

from the theoretic optimum). In the course of the sim-

ulation, eventually new trafﬁc comes in and the ONC

system proceeds in adapting the parameter sets. This

results in a continuously increasing performance of

Layer 1. At the end of the simulation (i.e. at the end

of day 5), the performance is constantly near to 1.3

(this is about 92% of the optimum).

For comparison reasons, we performed the same

simulation without the ONC component. This means

that each participant performs the standard TCP pa-

rameter set as listed in Table 1. This standard param-

eter set represents the hand-optimised solution avail-

able in the simulator – in general, this should be the

setting that works best on average in each possible sit-

uation. The results are illustrated by Figure 4. Com-

paring both ﬁgures, it can be observed that the ONC

approach ﬁnds similar parameter settings as the stan-

dard parameter set (i.e. the last parameter sets are:

mss = 586 and bu f f er = 7,504) – but without the

need of prior knowledge, without manual optimisa-

tion, and with the potential beneﬁt to adapt auto-

matically to changing conditions and different phys-

ical connections. This is exactly what we wanted to

achieve with the developed concept.

Another observation that can be made in this

single-run scenario is that the performance is chang-

ing - it is not just a continuous improvement. In con-

trast, periods of decreasing performance can be ob-

served. This is due to the learning mechanism that

follows a roulette-wheel approach considering the ﬁt-

ICINCO2015-12thInternationalConferenceonInformaticsinControl,AutomationandRobotics

128

ness of the available rules. Please note that the results

shown in the ﬁgures reﬂect just one simulation run

and have not been averaged over several runs. This

is due to demonstrating the speciﬁc behaviour – the

effects of individual rule adaptations are not visible in

aggregated ﬁgures based on several runs. Averaged

values are considered in the following part.

4.2.3 Evaluation of Multiple Scenarios

Layer 2

Layer 1

Simulated time

Fitness of the active rule

Figure 4: Change of the ﬁtness when performing the stan-

dard parameter sets.

The third part of the evaluation considers the

performance of ONC in a more generalised way.

Thereby, we take 27 runs of the simulation with vary-

ing seeds into account and derive the statistical re-

sults. The considered simulation period has been in-

creased to 15 days to get an impression about the

long-term behaviour of the system. In order to be able

to compare the results of all runs, we deactivated the

dynamic adaptation of the RTT estimation. This is

done by deﬁning static RT T

min

(here: 0, 013 ms) and

RT T

max

(here: 4, 3 ms) values (cf. Equation 1). Fig-

ure 5 illustrates the results for the ONC solution. In

comparison, Figure 6 illustrates the behaviour in case

of using just the standard parameter settings (i.e. de-

activated rule-adaptation for all hosts). The ﬁgures

display the average during the simulation time (blue

line), the corridor within that values are measured (i.e.

minimum and maximum values over time), and the

standard deviation.

Similar to the previous experiments, ONC (i.e.

client0) starts with a bad parameter setting (i.e. again:

mss = 40, 000 and bu f f er = 20, 000). The ﬁgure

shows that the effect observed for the single run can

be generalised for several runs. Thereby, we depict

the corridor of the observed behaviour using the mini-

mum and maximum values at the certain point in time

for the system performance. The most obvious insight

by considering this corridor is that its size decreases

over time for Layer 1; in contrast, the behaviour does

not change signiﬁcantly for Layer 2. This is exactly

what the learning approach is assumed to achieve:

With increasing number of classiﬁers and growing ex-

perience with these, the system gets aware of the par-

ticular impact (i.e. it actually learns the desired be-

haviour). Layer 2 tries to ﬁnd novel behaviour for

previously untested situations – therefore, no recog-

nition of patterns is possible (i.e. it has to discover the

ﬁtness landscape again for each new task).

Fitness Layer 2Fitness Layer 1

Simulated time

Minimum/Maximum

Standard deviation

Arithmetic mean

Figure 5: Performance of Layer 1 and Layer 2 for 15 simu-

lated days (start = bad parameter settings).

A second major observation can be made when

comparing Figure 5 and Figure 6. For the ONC-based

variant, the learning behaviour is visible (decreasing

corridor size) – while it stays static for the non-ONC

version. This reﬂects the expected behaviour, since

the non-ONC version performs the standard parame-

ter sets without modiﬁcations and hence results in a

statistically static behaviour by design.

Fitness Layer 2Fitness Layer 1

Simulated time

Minimum/Maximum

Standard deviation

Arithmetic mean

Figure 6: Performance of Layer 1 and Layer 2 for 15 simu-

lated days (standard parameter settings).

4.3 Discussion of the Achieved Results

The simulation results demonstrate the potential

beneﬁt of utilising the proposed cooperative self-

optimisation to ﬁnd the best possible parameter set-

tings in connection-oriented network protocols. The

scenario is a perfect example to demonstrate OC’s vi-

sion of moving design-time decisions to runtime and

into the responsibility of the system. Instead of spend-

ing resource- and time-consuming optimisation ef-

forts at design-time to ﬁnd the best possible parameter

settings – mostly those conﬁgurations are requested

that work best on average for all foreseen situations

CooperativeSelf-optimisationofNetworkProtocolParametersatRuntime

129

– the system itself ﬁnds the best parameter settings in

each situation. This results in a highly self-adaptive

and robust behaving system which can also adapt to

unforeseen situations.

Since a local perspective is not enough for

connection-oriented protocols to either set consistent

parameters or to measure the success, cooperative so-

lutions are needed. This matches again perfectly with

OC’s research agenda. In this paper, we developed a

self-organised solution which cooperatively ﬁnds the

best strategies at runtime. The effect of testing and

changing parameters always appears for two partners

– thereby, we created a self-organised way of chang-

ing the structure of the system (i.e. which entity is

cooperating with which other entity). From a perfor-

mance perspective, the developed solution is able to

ﬁnd parameters that show the same performance as

the optimised standard parameters in undisturbed sit-

uations. However, the system is expected to ﬁnd su-

perior parameter settings in disturbed situations (i.e.

very high latency or very high packet loss).

5 CONCLUSIONS

This paper presented a novel distributed approach for

self-optimisation of data communication protocol pa-

rameters. Based on previous work in the context of

the Organic Network Control system (ONC), we ex-

plained a cooperative approach to ﬁnd and test param-

eter settings for TCP. The approach has been eval-

uated in a Omnet++-based simulation and demon-

strated the potential beneﬁt. In contrast to other solu-

tions from the state of the art, our method works with-

out prior knowledge, considers safety-boundaries,

and self-improves its behaviour over time.

Current and future work focus on further improv-

ing the mechanism and applying it to continuously

changing conditions. In the scenarios considered in

this paper, we demonstrated that the solution is able

to ﬁnd similar parameter settings as those initially

available in the TCP implementation – but without

any prior knowledge and without the need of time-

consuming optimisation processes at design-time. We

only simulated slightly changing conditions that do

not affect the physical medium (i.e. we only work on

Ethernet connections). Currently, we analyse how the

behaviour changes in case of replacing the physical

medium (e.g. Ethernet vs. WiFi) during operation.

REFERENCES

Dukkipati, N. et al. (2010). An Argument for Increasing

TCP’s Initial Congestion Window. ACM SIGCOMM

Computer Communications Review, 40:27–33.

Georganopoulos, N. and Lewis, T. (2007). A Framework

for Dynamic Link and Network Layer Protocol Opti-

misation. Proc. of Mobile and Wireless Communica-

tions Summit, pages 1–5.

INET Project (2014). The INET Framework.

http://inet.omnetpp.org/.

Kleinrock, L. and A.Tobagi, F. (1975). Packet Switch-

ing in Radio Channels: CSMA Modes and Their

Throughput-Delay Characteristics. IEEE Trans. on

Com., 23(12):1400–1416.

Martin, J., Nilsson, A., and Rhee, I. (2003). Delay-based

congestion avoidance for TCP. IEEE/ACM Transac-

tions on Networking, 11(3):356 – 369.

Miranda, H., Pinto, A., and Rodrigues, L. (2001). Appia: A

Flexible Protocol Kernel Supporting Multiple Coordi-

nated Channels. In Proc. of ICDCS ’01, pages 707 –

710. IEEE.

uller-Schloer, C. (2004). Organic Computing: On the

Feasibility of Controlled Emergence. In Proc. of

CODES and ISSS’04, pages 2–5.

Nichols, K. and Jacobson, V. (2014). Controlled Delay Ac-

tive Queue Management draft-nichols-tsvwg-codel-

02. Technical report, Pollere Inc. and Google.

Prothmann, H., Rochner, F., Tomforde, S., Branke, J.,

uller-Schloer, C., and Schmeck, H. (2008). Organic

Control of Trafﬁc Lights. In Proc. of ATC-08, volume

5060 of LNCS, pages 219–233. Springer Verlag.

Rosa, L., Lopes, A., and Rodrigues, L. (1997). Appia to R-

Appia: Refactoring a Protocol Composition Frame-

work for Dynamic Reconﬁguration. Technical Re-

port 1, Univ. of Lisbon, Dep. of Informatics.

Tomforde, S. and H

ahner, J. (2011). Biologically Inspired

Networking and Sensing: Algorithms and Architec-

tures, chapter Organic Network Control, pages 11–35.

Tomforde, S., Hurling, B., and H

ahner, J. (2011a). Dis-

tributed Network Protocol Parameter Adaptation in

Mobile Ad-Hoc Networks. In Informatics in Control,

Automation and Robotics, pages 91 – 104. Springer.

Tomforde, S., Prothmann, H., Branke, J., H

ahner, J., Mnif,

M., M

uller-Schloer, C., Richter, U., and Schmeck, H.

(2011b). Observation and Control of Organic Sys-

tems. In Organic Computing - A Paradigm Shift for

Complex Systems, pages 325 – 338. Birkh

auser.

Tomforde, S., Zgeras, I., H

ahner, J., and M

uller-Schloer,

C. (2010). Adaptive Control of Wireless Sensor Net-

works. In Proc. of ATC’10, pages 77 – 91.

van Renesse, R., Birman, K. P., and Maffeis, S. (1996). Ho-

rus: a ﬂexible group communication system. Commu-

nications of the ACM, 39(4):76 – 83.

Varga, A. (2001). The OMNET++ discrete event simulation

system. In Proc. of European Simulation Multiconfer-

ence, pages 319–324.

Wilson, S. W. (1995). Classiﬁer Fitness Based on Accuracy.

Evolutionary Computation, 3(2):149–175.

Ye, T. and Kalyanaraman, S. (2004). A recursive random

search algorithm for network parameter optimization.

SIGMETRICS Perform. Eval. Rev., 32(3):44–53.

ICINCO2015-12thInternationalConferenceonInformaticsinControl,AutomationandRobotics

130