Multidomain DiffServ QoS Simulation

1
Multi-domain DiffServ QoS Simulation

• Beat Nideröst, Wim Sjouw, Mark Janssen, ???
• Utrecht University
• ? Sem Borst, Michel Mandjes ?
• CWI

2
Index

• Dynacore and its network QoS requirements
• The simulation model
• Model validation
• DiffServ simulation
• Time schedule
• Related (future) work

3
Dynacore

• Goal is to build a remote participation
  demonstrator
• Allows scientists from the FOM institute in
  Rijnhuizen (NL) to experiment remotely at the
  Textor-94 plasma-physics experiment in Jülich (D)
• The demonstrator consists of four tools
• Measurement database with graphical client
• Diagnostic Control and Status display
• Video Conferencing Software
• Remote Terminal login
• The demonstrator uses the LAN in Rijnhuizen and
  Jülich, and the best effort research networks
  Surfnet 4, TEN-155 and B-WiN
• Similar collaborations with JET in the UK and
  other plasma physics institutes are planned in
  the near future

4
Network QoS requirements

• Measurement database
• Bandwidth gt 5 Mbit/s
• Network delay not an issue
• Video conferencing
• Bandwidth gt 300 kbit/s
• One-way network delay lt 30 ms
• Diagnostic control monitoring and remote
  terminal login
• Bandwidth delay not an issue
• Low packet loss desired
• In the current situation, these requirements are
  met most of, but not all the time. Could an
  DiffServ enabled backbone help to guarantee the
  required QoS?

5
The Network Model

• Look at a fixed path between a computer in Jülich
  and a computer in Rijnhuizen.
• Interesting QoS parameters are the available
  network bandwidth to applications running on
  these computers, the network delay and jitter,
  and the packet loss rate.
• The model only involves the two end computers and
  all the routers that transport packets between
  these two.
• Models of the traffic on all connections to these
  routers substitute the real hardware connected to
  them.

6
The current fixed route

• FOM -gt IPP - 40 byte packets
• 1 cisco1.rijnh.nl
• 2 AR1.Utrecht.surf.net
• 3 AR2.Utrecht.surf.net
• 4 BR7.Amsterdam.surf.net
• 5 ge.nl40.ten-155.net
• 6 de-nl-1.de40.ten-155.net
• 7 ge.de3.de1.ten-155.net
• 8 IR-Frankfurt1.win-ip.dfn.de
• 9 zr-frankfurt1.win-ip.dfn.de
• 10 zr-koeln1.win-ip.dfn.de
• 11 rwth-aachen1.win-ip.dfn.de
• 12 kr-kfa-juelich.kfa-juelich.de
• 13 zam047-i.zam.kfa-juelich.de
• 14 ipp277.ipp.kfa-juelich.de
• Round Trip Time approx. 20 ms

IPP -gt FOM - 40 byte packets 1
zam047.kfa-juelich.de 2 zam301-I.kfa-juelich.de
3 rwth-aachen1.win-ip.dfn.de 4
zr-koeln1.win-ip.dfn.de 5 zr-frankfurt1.win-ip.d
fn.de 6 ir-frankfurt1.win-ip.dfn.de 7
dfn.de.ten-155.net 8 ge.de40.ten-155.net 9
de-nl-2.nl40.ten-155.net 10 212.1.196.230 11
AR2.Utrecht.surf.net 12 AR1.Utrecht.surf.net 13
rijnh-router.Customer.surf.net 14
huygens.rijnh.nl Round Trip Time approx. 19 ms
7
The traffic models

• Traffic models define the ingress and egress
  connection, the protocol, packet size and the
  time stamp of all IP packets that use the routers
  in the simulation
• The model must be valid for at least one hour,
  the duration of our simulations.
• Analysis of all traffic in the real networks is
  required to find the correct traffic models.
• Multiple traffic models can describe the traffic
  at different times of the day, days of the week,
  etc.

8
How to measure traffic?

• Remember the traffic models for all ingress and
  egress points should be valid during the same
  period of time
• Sniffing traffic?
• A lot of expensive equipment needed
• Is per-domain traffic measurement is acceptable?
• Huge amounts of data
• Unsecure (unless we dont record packet content)
• Or can routers do the measurement???

9
Simulation of the current network

• We validate the simulation by comparing the
  measured QoS parameters of the real network with
  the parameters we get from the simulation.
• Goal is to validate traffic models for different
  times of day, day of the week, etc.
• These models can be used in many other
  simulations (overprovisioning theory, usefulness
  of link upgrades)
• Needs input from research networks
• The network structure between the two endpoints
  (in order to create the network model)
• Measurements of all real network traffic through
  the interconnecting routers simultaneously to
  measuring the end-to-end QoS parameters.
• Can this tool become an IS?

10
Simulation of a DiffServ network

• Use validated traffic models together with
  modified network models
• The new models simulate networks in which
  DiffServ is enabled
• Different network models can be used to simulate
  different DiffServ configurations (PHBs etc.) or
  networks in which DiffServ is enabled only in
  certain parts (for example, only Surfnet has
  DiffServ enabled).
• All traffic is best effort, except for the
  end-to-end traffic between our applications in
  Jülich and Rijnhuizen.
• Goal is to see if the QoS parameters in our
  simulation improve significantly when DiffServ is
  enabled.

11
Time Schedule
12
Help wanted

• Determine the network model
• All the IP routers along the path FOM / FZJ,
  together with their hardware type and
  configuration, and their routing setup.
• All the ingress/egress connections on these
  routers.
• Updates on changes in the configuration.
• Build tools to measure the real network traffic
• Come up with techniques that allow us to record
  the parameters that we need. We would need input
  about the technical possibilities of the backbone
  routers (what can we measure, what not?)
• Measure the real network traffic
• For this, we need some access to the backbone
• Implement DiffServ in the network model
• How should we do this?

13
Possible future directions

• Improve the LANs and uplinks
• More capacity and QoS
• Profile our applications
• Extend simulation to include more domains
  (NRENs).
• This could yield a network model that might be
  used in other simulations, for example to study
  the impact of improving network capacity, as
  well.
• Instead of static DiffServ, add dynamic
  configuration of QoS to the model.
• This would allow, for example, an end user to ask
  the network for a specific QoS connection when
  needed. How can such a dynamic system be managed,
  what protocols are needed to implement it?