Cognitive Packet Networks: Improving QoS and Security, and Reduce - - PowerPoint PPT Presentation

Cognitive Packet Networks: Improving QoS and Security, and Reduce Energy Consumption

Erol Gelenbe

FIEEE FACM FRSS FIET Fellow of the National Academy of Technologies of France, Science Academies of Belgium, Hungary, Poland and Turkey

Institute of Theoretical & Applied Informatics Polish Academy of Sciences ACOSIS 2019, Marrakech November 20, 2019

The Internet is Infinite, Pervasive and Unknown Basic Technology is Faster and Being Automated Demand is Ever Growing through Mobile Access and the IoT The Periphery of the Internet: Barbarians and Rome As More Things get Connected, the Less we Know ICT use of Electrical Energy is Growing by ~ 5-7% per Year

User Services in Unknown Networks Cognition and Knowledge Situational Awareness To Maximise User Satisfaction & Optimise Operator Income

Smart “Cognitive Network”

Wide Variety of Terminals and Things Wide Variety of User Applications Diverse Users with Varying Demands Unknown and Varying Infrastructure Recognition of the User’s Context /Service Adaptation Dependable, Safe and Adaptive Network On & Off-Line Analytics & SDN for Distributed Adaptive Control

“Quality of Service”

• Exploit the infrastructure dynamically, for the users’ benefit
• Protect from Attacks: Malware, Storms,Viruses and Worms, DoS
• Offer Fair Service Charges
• Provide security to connections
• Demonstrable service levels and monitored agreements
• The IoT makes it all the more urgent

Conventional Optimisation is Impossible On-Line in Real-Time

• Networks are very large – any optimisation is relevant

for a subset of users and routes at a time

• The system is extremely large .. information delay,

control delay and combinatorial explosion: global algorithms are very slow and come too late

• The system is highly dynamic – traffic varies

significantly over short periods of time

• Corrective action must be fast
• Huge quantities of traffic in the pipes – congestion

can occur suddenly, reaction and detours must be very rapid

• Needed: Learning & Adaptivity Relevant to the

Operators and Users based on On-line Measurement

The Means for “Quality of Service”

• Pro-active monitoring of users
• On-line & Pro-active Network Measurement
• Monitoring of QoS and SLAs
• Approaches which Cross or Combine Layers

Smart Cognitive Network

Cognitive Packet Network (CPN) Principles

• Compatible with the IP Protocol
• “Users” or Operators formulate Goals based on Measurable

Quantities (loss, delay, security, throughput, energy … )

• Goal optimised on-line, e.g. Delay , Loss, Energy measured

Goal = a QoS + b E .. Typically b= 1-a G = a[(1-L)D + L(D+G)] +b [(1-L)E + L(E+G)] = (aD + bE) /[1-(a+b)L] Observe different paths’ through on-line measurement, Operator may Inform the User + Dynamically & On-Line Selects paths or Sub-Networks based on the Measured G that can include Price, Security, QoS … Ongoing  NOT one shot .. Everything may constantly change

CPN Principles

• Seamlessly operates with IP
• Users or Operators select QoS goals
• Smart Packets (SPs) collectively learn to

achieve the goals – Everything Changes with Time

• Learning by sharing information between SPs
• User Packets sharing the same goals can be

grouped into classes

• Nodes (Cognitive Routers) are storage centers,

mailboxes and processing units

• Users or Operators receive Feedback from SPs,

and select the “top” N paths – Changing with Time

CPN and Smart Packets

Smart Packets route themselves based on QoS Goals, e.g.,

Minimise Delay or Loss or Combination Minimise Jitter (for Voice) Maximise Dispersion (for security) Minimise Cost Optimise Cost/Benefit

Smart Packets make observations & take own decisions ACK Packets bring back observed data and trace activity and update a priority list of paths Users and Operators route Dumb Packets by selecting paths based on the “priority list” of paths

Decision System: a “neural” network (Neural Network embedded in Routers or SDN Servers) Internal State of Neuron i, is an Integer xi > 0 Network State at time t is a Vector x(t) = (x1(t), … , xi(t), … , xk(t), … , xn(t)) Is the Internal Potential of Neuron I If xi(t)> 0, we say that Neuron i is excited and it may fire at t+ in which case it will send out a spike If xi(t)=0, the Neuron cannot fire at t+ When Neuron i fires: :

• It sends a spike to some Neuron k, w.p. pik
• Its internal state changes xi(t+) = xi(t) - 1

State of Network x(t) = (x1(t), … , xi(t), … , xl(t), … , xn(t)), xi(t)>0 If xi > 0, we say that Neuron i is excited If xi(t)> 0, then Neuron i will fire with probability ri∆t in the interval [t,t+∆t] , and as a result:

• Its internal state changes xi(t+) = xi(t) – 1
• It sends a spike to some Neuron m w.p. pim

The arriving spike at Neuron m is an

• Excitatory Spike w.p. pim

+

• Inhibitory Spike w.p. pim
• pim = pim

+ + pim

• with Σn

m=1 pim < 1 for all i=1,..,n

Rates and Weights x(t) = (x1(t), … , xi(t), … , xl (t), … , xn(t)), xi(t)>0 If xi(t)> 0, then Neuron i will fire with probability ri∆t in the interval [t,t+∆t] , and as a result: From Neuron i to Neuron l

• Excitatory Weight or Rate is wim

+ = ri pim +

• Inhibitory Weight or Rate is wim
• = ri pim
• Total Firing Rate is ri = Σn

m=1 wim

+ + wim –

To Neuron i, from Outside the Network

• External Excitatory Spikes arrive at rate Λi
• External Inhibitory Spikes arrive at rate λi

1 < + + + Λ = ≤

 

− + j ji j j i i j ji j j i i

p r q r p r q q λ

ji −

ω

Firing Rate of Neuron i External Arrival Rate of Excitatory Spikes External Arrival Rate of Inhibitory Spikes

ji +

ω

Probability that Neuron I is excited

Goal Based Reinforcement Learning in CPN for SPs (Only)

• The Goal Function to be minimized is selected by the user, for

instance G = [1-L]D + L[T+D+G]; T is some penalty

• On-line probing is used to measure L and W, and this

information is brought back to the decision points

• The value of G is estimated at each decision node and used to

compute the estimated reward R = 1/G

• The RNN weights are updated using R, and the RNN which

makes a myopic (one step) decision

• ACKs bring back the path QoS to the Source (or to the

Operator) to maintain a Prriority List of Paths

Routing with Reinforcement Learning using the RNN for the SPs

• Each “neuron” corresponds to

the choice of an output link in the node

• Fully Recurrent Random Neural

Network with Excitatory and Inhibitory Weights

• Weights are updated with RL
• Existence and Uniqueness of

solution is guaranteed

• Decision is made by selecting

the outgoing link which corresponds to the neuron whose excitation probability is largest

Reinforcement Learning Algorithm in CPN

• The decision threshold is the Most Recent

Historical Value of the Reward

• Recent Reward Rl

If then else

1 1

, ) 1 (

− −

= − + = G R R a aT T

l l l

j k n R k i w k i w R j i w j i w

l l

≠ − + ← + ←

− − + +

, 2 ) , ( ) , ( ) , ( ) , (

l l

R T ≤

− 1 l l

R j i w j i w j k n R k i w k i w + ← ≠ − + ←

− − + +

) , ( ) , ( , 2 ) , ( ) , (

• Re-normalize all weights
• Compute q = (q1, … , qn) from the fixed-point
• Select Decision k such that qk > qi for all i=1, …, n



− +

+ =

n i

m i w m i w r

1 *

)] , ( ) , ( [

* *

) , ( ) , ( ) , ( ) , (

i i i i

r r j i w j i w r r j i w j i w

− − + +

← ←

CPN Test-Bed Measurements On-Line Route Discovery by Smart Packets

CPN Test-Bed Measurements Ongoing Route Discovery by Smart Packets

Route Adaptation without Obstructing Traffic

Packet Round-Trip Delay with Saturating Obstructing Traffic at Count 30

Route Adaptation with Saturating Obstructing Traffic at Count 30

Packet Round-Trip Delay with Link Failure at Count 40

Path Tags with Link Failure at Count 40

SP DP All Average Round-Trip Packet Delay VS Percentage of Smart Packets

Voice over CPN

• Fig. 1. Voice over CPN

Experimental Results Voice over CPN

• Fig. 4

Experimental Results Voice over CPN

• Fig. 6 : Average roundtrip delay (left) and jitter (right) for user payload when only DPs are

allowed to carry user payload

Experimental Results: Voice over CPN Packet desequencing Probability at Receiver vs Packet Rate

• Fig. 7. Probability of packet desequencing perceived by the receiver side

CPN for Traffic Engineering

10.0.10.0 10.0.11.0

10.0.16.0 1 . . 1 5 .

• 10.0.14.0

1 . . 1 3 .

• 1

. . 1 2 .

• eth2

eth1 e t h 1

• e

t h 1

• e

t h 1

• CPN-NODE

10.0.17.0

CPN Learns Paths with Minimum Hops Average Path length with different background traffic

2 4 6 8 1 2 3 4 5 6 7 8 9 10 11 rate (Mbps) path length (hops) without background traffic delay hops hops+Delay 2 4 6 8 1 2 3 4 5 6 7 8 9 10 11 rate (Mbps) path length (hops) 1.6Mbps background traffic delay hops hops+Delay 2 4 6 8 1 2 3 4 5 6 7 8 9 10 11 rate (Mbps) path length (hops) 3.2Mbps background traffic delay hops hops+Delay 2 4 6 8 1 2 3 4 5 6 7 8 9 10 11 rate (Mbps) path length (hops) 6.4Mbps background traffic delay hops hops+Delay

• 12 routes discovered and 4 of them are shortest path
• Only about 51% of DPs use these 4 shortest paths

200 400 600 800 1000 1200 1400 1600 1800 2000 5 10 15 Packet Number Route Length 1 2 3 4 5 6 7 8 9 10 11 12 5 10 15 20 25 30 Route No. Percentage used (%)

Delay with different background traffic

1 2 3 4 5 6 7 8 10

1

10

2

rate (Mbps) dumb packet delay (ms) without background traffic delay hops hops+Delay

No background traffic

Medium High

Genetic Algorithms for CPN

• Exploit an analogy between “genotypes”

and network paths

• The fitness of the individual is the QoS of

the path

• Selection function chooses paths for

reproduction based on the QoS of paths

• The genetic operation used to create new

individuals is crossover

Crossover

S f x y D S z a y D b c S z x y D e S a b c f y D e

100 200 300 400 500 600 700 800 10 10

10

Packets Input Rate Forward Delay (ms) Without background traffic GA−disabled GA−enabled 100 200 300 400 500 600 700 800 10 20 30 40 50 60 70 80 90 100 Packets Input Rate Loss Rate (%) Without background traffic GA−disabled GA−enabled 100 200 300 400 500 600 700 800 10 10

10

Packets Input Rate Forward Delay (ms) About 1.6Mbps background traffic GA−disabled GA−enabled 100 200 300 400 500 600 700 800 10 20 30 40 50 60 70 80 90 100 Packets Input Rate Loss Rate (%) About 1.6Mbps background traffic GA−disabled GA−enabled

No background traffic 2.4Mb background traffic

Delay Loss

4 Mb background traffic 5.6Mb background traffic

Delay Loss

100 200 300 400 500 600 700 800 10 10

10

Packets Input Rate Forward Delay (ms) About 4Mbps background traffic GA−disabled GA−enabled 100 200 300 400 500 600 700 800 10 20 30 40 50 60 70 80 90 100 Packets Input Rate Loss Rate (%) About 4Mbps background traffic GA−disabled GA−enabled 100 200 300 400 500 600 700 800 10 10

10

Packets Input Rate Forward Delay (ms) About 5.6Mbps background traffic GA−disabled GA−enabled 100 200 300 400 500 600 700 800 10 20 30 40 50 60 70 80 90 100 Packets Input Rate Loss Rate (%) About 5.6Mbps background traffic GA−disabled GA−enabled

8 Mb/s background traffic

100 200 300 400 500 600 700 800 10 10

1

10

2

Packets Input Rate Forward Delay (ms) About 8Mbps background traffic GA−disabled GA−enabled 100 200 300 400 500 600 700 800 10 20 30 40 50 60 70 80 90 100 Packets Input Rate Loss Rate (%) About 8Mbps background traffic GA−disabled GA−enabled

Experiments with Energy Savings

Measurements on Feasibility Using our 46-node Laboratory Packet Network Test-Bed:

• E. Gelenbe and S. Silvestri, ``Optimisation
• f Power Consumption in Wired Packet Networks,''
• Proc. QShine'09, 22 (12), 717-728, LNICST, Springer

Verlag, 2009.

Power Measurement on Routers

Example of Measured Router Power Profile

Experiments with a Self-Aware Approach Minimise Power subject to End-to-End Delay (80ms) Constraint

[10] E. Gelenbe, ``Steps Toward Self-Aware Networks,'‘ Comm. ACM, 52 (7), pp. 66-75, July 2009. [15] E. Gelenbe and T. Mahmoodi “Energy aware routing in the Cognitive Packet Network”, presented at NGI/Co July 2010, submited for publication.

Measuring Avg Power Over All Routers Vs Average Traffic per Router

Power and Delay with EARP Energy Aware Routing Protocol

Power Savings and QoS using EARP

192.168.2.1 Network Address Translation 192.168.2.102 192.168.2.103 192.168.2.101 C

• m

p u t e r

• Sc

i e n c e

• N

e t w

• r

k

• (

1 3 2 . 1 7 . 1 8 . X ) Internet

192.168.2.20 192.168.2.30 192.168.2.40

Wireless Power-Aware Adhoc CPN Test-Bed

51

Monitoring Architecture

∗ Agent-based monitoring solution, consisting

• f the

∗ monitoring managers (MMs), and ∗ monitoring agents (MAs).

∗ Monitoring agent

∗ Software agent collecting local monitoring metrics ∗ Resides on nodes (hosts and VMs) ∗ Interfaces with the monitoring manager ∗ Uses collectd and RRDtool

∗ Monitoring manager

∗ Controls and configures monitoring via the agents ∗ Provides an interface to the monitoring system

52

The Monitoring Agent

• Controller configures and controls

probing of local resources by the collectd daemon.

• Controller starts, stops and restarts

collectd as necessary.

• collectdmon monitors the collectd

process and automatically restarts it if it fails.

• Periodic measurements from probes

are written to a local DB via RRDtool.

• Controller reads measurements from

the local DB via RRDtool to perform computations and make them available for reporting, acting as a mailbox.

• System metrics

– CPU, memory, disk, network, load, processes

• Application metrics

– SQL databases, Apache server, memcached

• Network metrics

– Latency, jitter, loss

53

Monitored Metrics

CPU Apache (bytes/sec)

• Monitoring agents (MA) record periodic measurements of

multiple metrics to a local repository.

• Monitoring manager collects the data from the MAs via

smart reports (SRs), dumb reports (DRs) and acknowledgements (ACKs)

– Smart reports are sent periodically by the MM, and collect the monitoring data from each hop (MA) they visit (via the corresponding ACK). – Smart reports are routed probabilistically based on the random neural network[2] at each MM and MA, therefore prioritizing parts of the cloud from which to collect data. – The ACK sent by the last MA in the chain carries the monitoring data back to the MM and updates the RNNs.

54

Collection of Monitored Data

[2] E. Gelenbe. Random neural networks with negative and positive signals and product form

• solution. Neural Computation, 1(4): 502-510, 1989.

Collection of Monitored Data

• MMs and MAs have an RNN for each QoS goal as

related to the given requirements for monitoring.

• The users of the monitoring data provide the QoS

goals, such as

– system-related goals (e.g. free memory must be > 20%

• f total memory),

– network-related goals (e.g. loss rate between VM1 and VM2 must be < 0.1%), – application-related goals (e.g. memory and CPU used by the Apache server must be < 80% of total system resources), and – monitoring-related goals (e.g. monitoring data from a host must be not be older than 10 minutes)

• Each RNN has a neuron representing each

resource (MA) connected to the MM or MA

• The weights of the neurons are used to decide

which parts of the cloud are prioritized for monitoring.

– Smart reports are sent probabilistically based on the weights of the neurons.

55

Machine Learning Based Overlays: SMART

Proxy 1. It monitors the quality of the Internet paths by sending probe packets to other proxies, 2. It routes each incoming packet sent by a local application to its destination. Transmission/Reception Agents 1. TA intercepts the packets of the application and forwards them to the local Proxy. 2. RA receives packets from the Proxy and delivers them to the local application.

56

Packet Routing/Forwarding

57

• All-pairs probing: monitoring the quality of

all overlay links is excessively costly, and impairs scalability

• SMART :
• The routing decisions are made on-line at the source proxy based
• n adaptive learning techniques using a random neural network

(RNN)

• Probing does not cover all possible paths but only a few paths

which have been observed to be of good quality, exploring also at random other paths whose quality might have improved recently

• SMART uses a limited monitoring effort but achieves

asymptotically the same average (per round) end-to-end latency as the best path

Main challenge: scalability

58

Minimising Latency

Experiment with 20 nodes

• f the NLNog ring

IP route SMART Melbourne/Gibraltar 390.0 274.6 Narita/Santiago 406.7 253.8 Moscow/Dublin 179.9 81.7 Honk Kong/Calgary 267.1 130.7 Singapore/Paris 322.3 154.1 Tokyo/Haifa 322.6 180.8

Average RTT (ms) for some pathological OD pairs

Latency Minimization

RTT Japan/Chile over 5 days RTT Japan/Chile (zoom)

Throughput Maximization

Experiment with Amazon EC2

IP route SMART Dublin/Sydney 11.5 37.5 Singapore/Sao Paulo 12.8 42.0 Sydney/Virginia 8.5 52.3 Virginia/Singapore 7.4 33.8 Virginia/Sydney 6.9 35.0 Virginia/Tokyo 10.3 39.7

Average Throughput (Mbps) for some pathological OD pairs

Throughput Maximization

Throughput from Virginia to Sydney

• ver 4 days

Throughput from Virginia to Sydney (zoom)

• Carried out using two approaches (simulation and

emulation)

• Based on the interaction between NEST and SMART,
• Aimed at enabling Large-scale experimentation in a controlled environment,
• The simulation approach relies on the ability of
• NEST kernel to simulate complex underlay networks and evaluate relevant key

performances,

• SMART to optimize overlay routing based on computed performance indicators,
• The emulation approach is built using
• an emulated network (by CORE), real applications (VMs) connected to it, and

the SMART system.

• The simulation kernel drives this emulation by
• Generating stochastic traffic, injecting adverse events and computing overlay link

performance,

• Changing link parameters within the emulation environment

SMART : offline validation

63

• We also developed an overlay

Hypervisor which is a GUI for the SMART system.

• This hypervisor allows to follow at

each time instant

– Routing decisions, – And the metric evolution for each

• verlay path
• The Hypervisor can be used either

– In real-time, displaying the current health status of an application overlay – Or to replay the evolution of key metrics within a specific time-frame, based on historical data.

SMART : offline validation

64

• We performed several measurement

campaigns, each lasting 24H

– The results presented are a zoom over 3H periods, – Tests used either delay or bandwidth probes

• Typically SMART enhances network

performances

• As an example for downloading a 10MB file

– SMART achieves

• An improvement of 124% of available bandwidth
• User total delay for the session

– On the IP path : 1m52s (737.4 Kb/s) – Over SMART Paths : 33s (2.42 Mb/s) – A 70.5% improvement

SMART : offline validation

65

SDN Based Network Control: H2020 SerIoT Research & Innovation Project

SDN Based Network Control: SerIoT Project

• Use CPN and Smart Packets to actively

collect measurement data in IoT Network

• Measurements Concern Security, Qos and

Energy

• Define Relevant Goal Functions and Path

Sensitivity Function

• Data reaches SDN routers which take

decisions based on the above

SDN based Network Control

The Goal Function for Security is rf,e) the “rejection factor”: node e, path f r(f,e) = [ S(f,e) – T(f,e) ] + , or for path P S(f,e) is estimated from attack detection, T(f,e) is a tolerance threshold r(f,P)=Σe ε P r(f,e), or r(f,P)= maxe ε P r(f,e) G(f,P) = a.r(f,P)+b.Q(f,P)+c.E(f,P)

SDN based Network Control Experiments

SDN Network Control: Reinforcement Learning and SDN Reaction Time to QoS

SDN Reaction Time to Security Alert

72

Self-Aware Cloud Task Allocation Platform

RN N

Heavy load Medium load Light load

• Online QoS-driven task allocation Platform for the cloud:

– Performs autonomous task-to-resource allocations based on given QoS goals for the tasks – Uses concepts similar to those presented for the pervasive monitoring system and SMART, i.e. learning using online measurements and random neural networks – Aims to optimize the performance related to the QoS requirements requested by end users, e.g. job response time , economic cost, etc.

• The approach is to:

– Do online measurements related to the given QoS goal(s) of tasks that need to be allocated to nodes (hosts, VMs) on the cloud – Adaptively learn the “best nodes” to which tasks should be allocated, depending on their QoS goals – Allocate incoming tasks to nodes based on the learned information, and continue to learn from the allocation decisions by monitoring the QoS received by the tasks

73

ML Task Allocation for the Cloud

Metric Category Metric Relevance: web servers, Search engines Relevance: batch jobs, MapReduce jobs Application level Response time High Low Throughput High High System level CPU utilization Low High Memory utilization Low High Other Economic cost Medium to High Medium to High Energy consumption Medium to High Medium to High

74

QoS Metrics

• RNN with reinforcement learning[3]

– Each RNN corresponds to a job class with a specified QoS goal – Each neuron corresponds to the choice of a host in a cluster. – Smart reports are sent to the most excited neuron. – Jobs are dispatched to the most excited neuron, resulting in the minimizing of the QoS goal.

• Sensible decisions[4]

– Smart reports are sent probabilistically based on the history of measurements. – No RNN. History is kept as an exponentially weighted moving average (EWMA) per QoS goal. – Jobs are dispatched probabilistically using the EWMA metric for their QoS goals.

• Round robin

75

Allocation Strategies

[3] E. Gelenbe, K.-F. Hussain. Learning in the multiple class random neural network. IEEE Trans. Neural Networks, 13(6): 1257-1267, Nov. 2002. [4] E. Gelenbe. Sensible decisions based on QoS. Computational Management Science, 1(1): 1-14, Dec. 2003.

76

Experimental Setup

∗ One job controller ∗ Three hosts

∗ have different processing speed and I/O capacity.

∗ Software components:

∗ Job generator (clients) ∗ Job dispatcher (controller) ∗ Job executor (hosts)

77

Experimental Results

Detail from figure on right

Scenario: Hosts with distinct processing speeds RNN vs. Sensible Allocation vs. Round Robin

78

Experimental Results

∗ Scenario:

∗ Different service (job) classes in terms of resource requirement

∗ CPU intensive services and I/O bound services

∗ Different background load on hosts, stressing CPU and I/O differently

79

SLA Penalties

50 100 150 200 250 300 2000 4000 6000 8000 10000

Job execution time (second) Penalty (for Job1)

500 1000 1500 2000 2500 3000 2000 4000 6000 8000 10000

Job execution time (second) Penalty (for Job2)

Experimental Results for Penalties

80

Scenario:

• Hosts with distinct power consumption and speed

Experimental Results

81

Measured Job Dispatching Probabilities to minimise the Energy-QoS goal function for different relative importance attributed to response time (a) and energy consumption (b) versus Load in Jobs/sec

Measured energy consumption per job (in Joules) and job response time at the hosts (in seconds) averaged over the three hosts as a function of job arrival rate λ

Experimental Results

82

83

Task Allocation across Multiple Clouds

∗ A TAP deployed in each Cloud ∗ The routing overlay, “SMART”, which includes a set of proxies installed at different cloud servers, or in

• ther servers over wide

area networks. ∗ Allocating the incoming jobs to the local or remote clouds depends on ∗ Cloud processing delay ∗ Network delay for job transfer

84

Experimental Results

Weighted average network delay over time on the connections to the three remote clouds Derived from measurement of the round-trip delay and loss via pinging The network performance is

• ptimized using the

routing overlay, “SMART” over clouds

85

Experimental Results

The measured response time for each web request as time elapses; the different colours represent the different clouds where the requests are allocated and processed. As long as the local cloud’s response time is low, tasks are processed

• locally. When the local response time increases significantly tasks are

sent to the remote cloud, and then when things improve at the local cloud, they are again executed locally.

Distributed DoS

Issues that we have adressed

• Detection

– Pattern detection – Anomaly detection – Hybrid detection – Third-party detection

• Response

– Agent identification – Rate-limiting – Filtering – Reconfiguration

CPN DDoS Defence Scheme

• The CPN architecture traces flows using smart and

ACK packets

• A DoS produces QoS degradation
• The user(s) and victim(s) detect the attack and inform

nodes upstream from the victim(s) using ACK packets

• These nodes drop possible DoS packets
• The detection scheme is never perfect (false alarms &

detection failures)

Mathematical model (1)

• Analyses the impact of DDoS protection
• n overall network performance
• Measures traffic rates in relation to

service rates and detection probabilities

Mathematical model

∏ ∏

− = − =

− − = − − =

1 1 , , , 1 1 , , ,

)) 1 )( 1 (( )) 1 )( 1 ((

j l d d d d d d j l n n n n n n

l l j j l l j j

d L I f L I

d d d n n n

λ λ

) ) 1 ( ) 1 ( (

, , , ,

 

− + − =

d d d n n n i d i i n i i i

d I f I s ρ

i B i B i i

i i

L ρ ρ ρ − − ⋅ =

+

1 1

1

Illustration on an Experimental CPN Test-Bed

Predictions of the Model

Experiments

• 2.4GHz P4 PCs, Linux kernel 2.4.26,

CPN

• Different QoS protocols for normal and

attack traffic

• 60 sec

Averaged Likelihood Feedforward RNN Recurrent RNN False Alarms: 2.8 % Correct Detections: 88 % False Alarms: 11 % Correct Detections: 96 % False Alarms: 11 % Correct Detections: 96 %

Trace1 --- Attack Traffic

Averaged Likelihood Feedforward RNN Recurrent RNN False Alarms: 0 % Correct Detections: 76 % False Alarms: 8.3 % Correct Detections: 84 % False Alarms: 2.8 % Correct Detections: 80 %

Trace2 --- Attack Traffic

Stable Networks in the Presence of Failures

• A node failure is emulated by disabling some or all of the Ethernet interfaces of a

node (so that no traffic will be able to go through that node, just like in a real breakdown

• f a machine) and is restored by re-enabling all the interfaces.
• Failures are considered to be similar to worm attacks and their spread is modelled

according to the AAWP (Analytical Active Worm Propagation) model. This is a discrete- time and continuous state deterministic approximation model, proposed by Chen et al. [1] to model the spread of active worms that employ random scanning.

• The AAWP is a discrete time model which is more realistic, since a node must be

completely infected before it starts infecting other node, so that the speed of the spread is connected to the number of nodes that can be infected.

• AAWP uses the random scanning mechanism in which it is assumed that every nodes

is just as likely to infect or be infected by others. Other scanning mechanisms can be used, such as local subnet, permutation and topological scanning.

Experiments

DoS on a streaming video

Joint Work with BT Exact Combining Network and Physical Security UK Technology Strategy Board SATURN, Imperial, Oxford, BT Exact, Northrup-Grumman Other Projects Minimizing Energy Consumption in Wired Networks and Clouds EU FP7 Fit4Green Project Imperial, Several European Universities, HP Mobile Security FP7 NEMESYS Project with Telecom Italia & Deutsche Telekom Cloud Computing FP7 PANACEA Project with ATOS & IBM Security of Health Systems & the IOT H2020 Projects KONFIDO & GHOST

• EG, R. Lent, A. Nunez ``Self-Aware networks and QoS'', Proc. IEEE, 92 (9): 1478--1489, 2004.
• EG, P. Liu and J. Laine ``Genetic algorithms for route discovery'', IEEE Trans. Systems, Man

and Cybernetics B, 36 (6): 1247-1254, 2006.

• EG and G. Loukas, ``A self-aware approach to denial of service defence'', Computer Networks,

51 (5): 1299-1314, 2007.

• EG, G. Sakellari and M. d'Arienzo ``Admission of QoS aware users in a smart network'', ACM
• Trans. on Autonomous and Adaptive Systems, 3(1), 2008.
• EG “Steps towards self-aware networks”’ Comm. ACM, July 2009.
• A. Berl, EG, et al. ``Energy-Efficient Cloud Computing'', The Computer Journal, (2010) 53 (7):

1045-1051.

• EG ``Search in unknown random environments'', Phys. Rev. E 82: 061112 (2010).
• EG and C. Morfopoulou ``A Framework for Energy Aware Routing in Packet Networks'', The

Computer Journal 54 (6): 850-859, 2011.

• EG and Z. Kazhmaganbetova “Cognitive Packet Network for Bilateral Asymmetric Connections”

IEEE Trans. on Industrial Informatics, 10 (3): 1717 - 1725, 2014.

• L. Wang, E. Gelenbe “Adaptive Dispatching of Tasks in the Cloud”, IEEE Transactions on Cloud

Computing, Volume: PP, Issue: 99, Date of Publication: 28 August 2015.

• O. Brun, L. Wang, EG “Big Data for Autonomic Intercontinental Overlays”, IEEE Journal of

Selected Topics in Communications, 34 (3): 575-583 (2016) CoRR abs/1512.08314.

• G. Gorbil, O. H. Abdelrahman, M. Pavloski, EG “Modeling and Analysis of RRC-Based Signalling

Storms in 3G Networks”, IEEE Trans. Emerging Topics Computing 4(1): 113-127 (2016).