QoS and CoS Developments in COIAS and MECCANO

1
QoS and CoS Developments in COIAS and MECCANO

• Peter T. Kirstein
• University College London

2
Acknowledgement

• Slides mainly developed by Patrick Coquet for
  ACTS COIAS Concertation Meeting
• Valid equally for COIAS and MECCANO

3
MECCANO Aims

• MECCANO aims to deploy Medium Quality MM
  conferences over multicast Internet
• Underlying networks are those that users can get
  access to in Europe
• Tools include video, audio, shared workspace,
  media servers
• Networks include research nets, TEN-155, ISDN,
  DBS and local radio nets
• Mostly use IPv4 some move to IPv6

4
COIAS Aims

• Develop IPv6 for a variety of components
• Develop Integrated architecture for a variety of
  networks
• Same mix as MECCANO, but more emphasis on DBS
  satellite and less on deployment
• Apply system to real problems and application
  developed by Eurocontrol
• Types of Application similar to MECCANO, but
  extra real-time problems

5
Common Interests

• Variety of multimedia applications
• Universal use of IP - with trend to IPv6
• Variety of underlying networks
• Applications able to signal relative priorities
  and qualities of service
• Application QoS needs translated to IP CoS
• Network-level IP able to use CoS to give
  priorities, choose technology, signal QoS

6
IP - the User-User Protocol
7
Schematic of DBS Addition
8
MECCANO Topology
9
MECCANO Configuration

• UK (UCL and HP on SuperJANET)
• Germany (Bremen, Erlangen, Freiburg, Mannheim,
  Stuttgart on DFB)
• Norway (Oslo on Uninett)
• France (INRIA on RENATER)
• DBS Up-stations (INRIA and ??)
• Downstations Internet at all sites including
  Canada (CRC) and Poland (Cracow)
• TEN-155 Connections between countries

10
COIAS Configuration Schematic
11
HIgh Performance NETworks
Nomadism Mobility
Flexibility
12
ISPs Interests in IP and ATM

• The ISPs Problem
• Provide new services voice, video, push and
  inter-active services...
• In an open market,
• Best quality/price for the customers
• Best benefit for the ISP
• Require a simple solution
• Provide a limited number of traffic quality
  classes
• Boundary devices can differentiate IP flows
• Map on ISP traffic classes and hence ATM QoS

13
Corporate Interest in IP and ATM

• The Corporate Network Problems
• Support new services web, push and inter-active
  services and (if cost effective) voiceand (if
  the interest is real) video.
• By simple migration of the existing network
  infrastructure
• With the guaranty that the existing applications
  will continue to run (at least as well as
  before!)
• ATM could increase bandwidth capacity
• Its QoS is not used, because the applications do
  not signal QoS, and IP layers do not signal CoS,

14
Proposed Solutions

• Differentiated IP classes of service on top of
  ATM QoS classes -
• Native ATM end stations
• Differentiation of application flows at the API
  level
• Intranet CoS policy
• Boundary Devices
• Mapping of intranet QoS with the ISP CoS
• Dynamic resource reservation. If implemented
• usage limited to intranets
• limited to guaranteed traffic

15
Intranet implementation
Host
Router
Host
QoS Agent
QoS Agent
QoS Agent
TCP/IP
SSM
SSM
SSM
QoS Policy
QoS Policy
QoS Policy
CoS/QoS Associations
CoS/QoS Associations
CoS/QoS Associations
ATM
ATM
ATM
ATM
16
Shaping/Scheduler Overview

• Packets are classified according to the flows to
  which they belong
• The rate of each class is controlled
• maximum throughput per class
• The rate of each station is controlled
• maximum throughput per network attachment
• Unused bandwidth is re-allocated according to
  classes priorities

17
SSM configuration

• Available commands
• class creation, modification,suppression,
• statistics per class
• Number of bits transmitted in the limits,
  overlimit, discarded.
• set the rate of the station on each subnet,
• set each class parameters
• priority, maximum rate on the subnet,
• size of the queue.

18
SSM configuration
19
Differentiated Services
Best Effort Audio traffic
Traffic injection
Assured Audio Traffic
20
Differentiated Services
Best Effort UDP traffic
Assured Audio Rate
21
CoS/QoS architecture
22
Internet Protocol stack
23
Conclusion

• Queuing shaping mechanisms are complementary
• necessary and have proved their efficiency
• Diffserv model should be implemented in all nodes
  
• Diffserv model is compatible with the Intserv
  model
• could be used to guaranty some critical dynamic
  traffic
• QoS/CoS policy has to be managed at a system
  level
• just as the security policy
• Must define how to distribute the QoS policy
  objects
• just as security policy objets
• Differentiated IP service classes should lead to
  the use of the ATM QoS classes

24
Practical Demonstrators

• COIAS and MECCANO provide good testbeds to
  experiment
• Will have mix of technologies - ATM, DBS and
  ordinary Internet
• TEN-155 promises to allow wide-area
  experimentation with QoS
• Both projects committed to pilot high quality MM
  services with real QoS