Communication Networks II www.kom.tu-darmstadt.de www.httc.de - - PowerPoint PPT Presentation

▶
communication networks ii
SMART_READER_LITE
LIVE PREVIEW

Communication Networks II www.kom.tu-darmstadt.de www.httc.de - - PowerPoint PPT Presentation

Jul 29, 2023 464 likes •997 views

Communication Networks II www.kom.tu-darmstadt.de www.httc.de Multimedia Communications / QoS Specific Topics (QoS, IntServ, DiffServ) Prof. Dr.-Ing. Ralf Steinmetz TU Darmstadt - Technische Universitt Darmstadt, Dept. of Electrical

slide-1
SLIDE 1

mmcom_qos_e-kp.fm 1 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Communication Networks II

  • Prof. Dr.-Ing. Ralf Steinmetz

TU Darmstadt - Technische Universität Darmstadt,

  • Dept. of Electrical Engineering and Information Technology, Dept. of Computer Science

KOM - Multimedia Communications Lab

  • Merckstr. 25, D-64283 Darmstadt, Germany, Ralf.Steinmetz@KOM.tu-darmstadt.de

Tel.+49 6151 166151, Fax. +49 6151 166152

httc - Hessian Telemedia Technology Competence-Center e.V

  • Merckstr. 25, D-64283 Darmstadt, Ralf.Steinmetz@httc.de

Multimedia Communications / QoS Specific Topics (QoS, IntServ, DiffServ)

slide-2
SLIDE 2

mmcom_qos_e-kp.fm 2 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Scope

KN III (Mobile Networking), Distributed Multimedia Systems (MM I and MM II), Telecooperation II,III. ...; Embedded Systems

L5

Applications Terminal access File access E-mail Web Peer-to- Peer Inst.-Msg. IP-Tel. Application Layer (Anwendung) SIP & H.323

L4

Transport Layer (Transport) Internet: UDP, TCP, SCTP

  • Netw. Transitions

Security Addressing Transport QoS - RTP

L3

Network Layer (Vermittlung) Internet: IP Network QoS

L2

Data Link Layer (Sicherung) LAN, MAN High-Speed LAN

L1

Physical Layer (Bitübertragung) Queueing Theory & Network Calculus Introduction

Legend: KN I KN II

slide-3
SLIDE 3

mmcom_qos_e-kp.fm 3 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Overview

  • 1. Motivation

1.1 Quality-of-Service 1.2 Repetition: Network Layer (Layer 3)

  • 2. IntServ & Resource ReSerVation Protocol RSVP

2.1 IntServ – Components 2.2 IntServ – Service Classes 2.3 The RSVP Protocol 2.4 RSVP - Creating and maintaining reservation state 2.5 RSVP – Merging of Reservations

  • 3. DiffServ: Differentiated Services for the Internet

3.1 DiffServ: Basic Ideas 3.2 DiffServ: Proposed Services

  • 4. Price-Controlled Best-Effort
  • 5. Summary: IntServ, DiffServ, Price Controlled Best Effort, Best Effort
slide-4
SLIDE 4

mmcom_qos_e-kp.fm 4 8.December.04

www.kom.tu-darmstadt.de www.httc.de

  • 1. Motivation

Vision INFORMATION SUPERHIGHWAY Convergence of

  • Internet
  • telephony network
  • radio and T.V. network
  • ...
  • all wired and mobile

One infrastructure for all (digital) services ⇒ the MULTI-SERVICE INTERNET

slide-5
SLIDE 5

mmcom_qos_e-kp.fm 5 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Multiservice Internet

Services on APPLICATION layer (applications):

  • today
  • E-Mail
  • web
  • FTP
  • instant messaging
  • Peer-to-Peer file-sharing
  • next years (high-bandwidth, real-time applications)
  • telemedia telephony (what about emergency calls?)
  • video (in acceptable quality)
  • network games
  • science-fiction (?)
  • tele-medicine
  • highest quality immersive video everywhere
  • virtual worlds in real use
  • robot / car / ... control via Internet
slide-6
SLIDE 6

mmcom_qos_e-kp.fm 6 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Multiservice Internet (2)

Services on NETWORK layer:

  • best-effort service
  • guaranteed service
  • ...

⇒ see further discussion Currently only one service on network layer:

  • best-effort service

⇒ QUALITY OF SERVICE must be supported (somehow) at network layer

slide-7
SLIDE 7

mmcom_qos_e-kp.fm 7 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Internet Real-Time and Multimedia Protocols

Signaling Quality of Service Media transp.

H.323 SIP RTSP RSVP RTCP H.261, MPEG RTP TCP UDP IPv4, IPv6 PPP AAL3/4 AAL5 PPP Sonet ATM Ethernet V.34

slide-8
SLIDE 8

mmcom_qos_e-kp.fm 8 8.December.04

www.kom.tu-darmstadt.de www.httc.de

1.1 Quality-of-Service Requirements of Different Applications

Continuous-media / discrete-media data presentation:

  • real time requirements

Mode dependent:

  • off-line
  • retrieval / distribution
  • dialogue

Media and encoding dependent:

  • discrete media / continuous media
  • compressed / uncompressed / compression method

Affected parameters:

  • 1. priority
  • delay / jitter
  • throughput
  • loss
  • 2. priority
  • availability, security, ...

Loss / Reliability Delay Throughput

slide-9
SLIDE 9

mmcom_qos_e-kp.fm 9 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Why Resource Administration?

QoS depends on available resources Resources and multimedia requirements:

  • always:
  • competition for resources among tasks
  • desire to provide best service at lowest possible costs

⇒ RESOURCE ADMINISTRATION to enforce QoS guarantees

requirements hardware in year X abundant resources insufficient resources 1980 1990 2000 interactive video high-quality audio network file access resources sufficient but scarce resources

“Window of Scarcity”

adapted from [Anderson et al., 1990]

slide-10
SLIDE 10

mmcom_qos_e-kp.fm 10 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Quality-of-Service – Main Issues

QoS specification:

  • application’s requirements
  • guarantees returned by the system

QoS calculation:

  • functions to calculate QoS guarantees

QoS enforcement:

  • reservation of resource capacities
  • scheduling of resource access
slide-11
SLIDE 11

mmcom_qos_e-kp.fm 11 8.December.04

www.kom.tu-darmstadt.de www.httc.de

The 4 Approaches for Quality of Service

  • 1. IntServ (and RSVP)
  • resource reservation (per flow) and admission control
  • queuing priorities based on flow
  • 2. DiffServ
  • introduce a number of service classes
  • queuing priorities based on service class
  • 3. Price-Controlled Best-Effort (Congestion-Pricing)
  • don’t change much
  • let users that cause congestion pay
  • ... and hope some of them back off
  • 4. Overprovisioning
  • don’t change anything
  • just add enough resources (routers, bandwidth)
  • ... and pray

simplicity QoS Control more changes

slide-12
SLIDE 12

mmcom_qos_e-kp.fm 12 8.December.04

www.kom.tu-darmstadt.de www.httc.de

1.2 Repetition: Network Layer (Layer 3)

Network layer protocol IPv4

  • UNRELIABLE DATAGRAM SERVICE
  • NO FLOW control
  • NO ERROR control
  • NO FIXED ROUTES
  • flexibility for path selection
  • reordering problems
  • NOT SUITABLE for time-critical continuous-media data
  • maximum datagram is 64 KByte
  • segmentation for smaller subnets (e.g., Ethernet 1500 byte)
  • reassembly necessary (within endsystem)
  • checksum for IP header only (to avoid misdirection)
  • Time-To-Live (TTL) = hop-counter to break loops

⇒ Modification of Internet protocols and mechanisms in order to provide QUALITY OF SERVICE

slide-13
SLIDE 13

mmcom_qos_e-kp.fm 13 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Transport Layer (Layer 4)

TCP:

  • congestion control included

UDP:

  • no congestion control included

Today:

  • most of the traffic is TCP (Web, Mail, Napster)

Probable Future:

  • video and audio streams will increase UDP’s share of total traffic

⇒ (missing) Congestion control becomes more and more of a problem

slide-14
SLIDE 14

mmcom_qos_e-kp.fm 14 8.December.04

www.kom.tu-darmstadt.de www.httc.de

  • 2. IntServ & Resource ReSerVation Protocol RSVP

The ’Pure’ Internet Model for QoS Provisioning

Use IP and IP Multicast for data transmission:

  • no new data forwarding protocol

Additional mechanisms, e. g.:

  • reservation protocol
  • Resource ReSerVation

Protocol

  • RSVP
  • resource management modules
  • e.g. admission control, packet

classifier, scheduler Data

Policy Control Admission Control RSVP Daemon Packet Classifier Packet Scheduler Appli- cation RSVP

slide-15
SLIDE 15

mmcom_qos_e-kp.fm 15 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Integrated Services (Intserv)

Framework developed with IETF Goal:

  • efficient Internet support for applications

which require SERVICE GUARANTEES

  • fullfil demands of
  • MULTIPOINT, REAL-TIME APPLICATIONS
  • for
  • small and
  • large group communication
  • typical example:
  • large-scale video conferences
slide-16
SLIDE 16

mmcom_qos_e-kp.fm 16 8.December.04

www.kom.tu-darmstadt.de www.httc.de

2.1 IntServ – Components

End-system and router components

  • existence and application of modules
  • depends on specific service used

Data

Policy Control Admission Control RSVP Daemon Packet Classifier Packet Scheduler Appli- cation

Data

Policy Control Admission Control RSVP Daemon Packet Classifier Packet Scheduler Routing RSVP

Host Router

slide-17
SLIDE 17

mmcom_qos_e-kp.fm 17 8.December.04

www.kom.tu-darmstadt.de www.httc.de

2.2 IntServ – Service Classes

3 service classes:

  • guaranteed service:
  • throughput and delay guarantees
  • controlled-load service:
  • limitation of load
  • similar to best-effort service in unloaded network
  • best effort:
  • traditional IP service:
  • no limitations,
  • no guarantees,
  • no effort for QoS provisioning
  • default

Additional classes (suggested, but postponed):

  • committed rate
  • predictive delay
  • controlled delay
  • protected best-effort
slide-18
SLIDE 18

mmcom_qos_e-kp.fm 18 8.December.04

www.kom.tu-darmstadt.de www.httc.de

IntServ – Characterization of Traffic

Stream traffic characterized by TOKEN BUCKET model For

  • guaranteed and
  • controlled-load service

with

  • r

= long-term rate (bytes/s)

  • b

= burst (bytes)

  • M = Maximum packet size (bytes)
  • m = minimum policed unit (bytes)
  • minimum number of tokens required to send an IP packet
  • p

= peak rate (bytes/s) token with rate r bucket of size b packet stream

slide-19
SLIDE 19

mmcom_qos_e-kp.fm 19 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Guaranteed Service

Strong guarantees:

  • guaranteed bounds for bandwidth and delay
  • for applications with hard real-time requirements

Required mechanisms:

  • admission control
  • checks whether a new reservation request can be accepted
  • policing
  • checks whether a flow conforms to its traffic description
  • reshaping
  • adapts a flow to its traffic description
  • needed within the network to reduce bursts caused by jitter
  • per-flow scheduling
  • determines the order by which packets are served
  • based on reservations and guarantees
slide-20
SLIDE 20

mmcom_qos_e-kp.fm 20 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Controlled-Load Service

Limitation of load

  • upper bound for the total traffic on the network
  • no strong guarantees for bandwidth or delay
  • weak assurance that
  • only a small percentage of the traffic is lost or delivered late
  • no quantification of QoS values
  • similar to best-effort service in unloaded networks
  • for applications that can adapt to moderate losses

Required mechanisms:

  • admission control
  • policing
slide-21
SLIDE 21

mmcom_qos_e-kp.fm 21 8.December.04

www.kom.tu-darmstadt.de www.httc.de

2.3 The RSVP Protocol

RSVP: Resource ReSerVation Protocol

  • RFC 2205 (September 1997)
  • and more details at other RFCs

Contains

  • only protocol elements for control
  • not for data transfer

Companion protocol to IP

  • controls HOW IP SENDS A PACKET
  • resource reservation support
slide-22
SLIDE 22

mmcom_qos_e-kp.fm 22 8.December.04

www.kom.tu-darmstadt.de www.httc.de

RSVP in the Protocol Stack

Typical environment with

  • resource reservation protocol (RSVP)
  • simple transport protocol (UDP)
  • Application Level Framing (ALF):
  • integration of protocol framework into application
  • (RTP: real-time transport protocol,
  • SRM: scalable reliable multicast)

UDP IP

RSVP

Layer 1 + 2 using ALF-Protocol-Framework (RTP, SRM, … ) (ivs, nv, vat, vic, wb) Multimedia Applications

slide-23
SLIDE 23

mmcom_qos_e-kp.fm 23 8.December.04

www.kom.tu-darmstadt.de www.httc.de

RSVP – Basics

Main abstractions:

  • IP multicast routing tree from source(s) to multiple targets
  • receiver-initiated reservation
  • filtering provides for
  • heterogeneous receivers
  • different reservation styles
  • concentrates on resource reservation only
  • ‘soft-state’, refreshed periodically
slide-24
SLIDE 24

mmcom_qos_e-kp.fm 24 8.December.04

www.kom.tu-darmstadt.de www.httc.de

RSVP Flow and Session

Simplex transmission model Sessions:

  • destination address
  • unicast or multicast
  • reservation ID (32 bit number)
  • generalized receiver ’port’; supplied by application (’cookie’ for RSVP)
  • protocol number
  • 1+ flows

Data flows distinguished by

  • IPv4: source IP address, source port
  • IPv6: source IP address, flow label

IP Multicast S1 S2 R1 R2 R3

same multicast group and ’port’

slide-25
SLIDE 25

mmcom_qos_e-kp.fm 25 8.December.04

www.kom.tu-darmstadt.de www.httc.de

IP Multicast with Resource Reservation (RSVP)

Periodic transmission of

  • PATH message indicating session parameters
  • sent from sender to complete group
  • answer: reservation message (RESV) from receivers to sender
  • use route defined through PATH messages
  • receiver-initiated reservation
  • routers reserve resources based on RESV messages
  • soft state update

Sender Receiver 1 Receiver 2 Router Data RESV PATH

slide-26
SLIDE 26

mmcom_qos_e-kp.fm 26 8.December.04

www.kom.tu-darmstadt.de www.httc.de

2.4 RSVP - Creating and maintaining reservation state

Source/sender:

  • multicasts data flows
  • sends PATH message (periodically) including TSpec describing flows

Receiver:

  • 1. joins multicast group
  • 2. receives PATH messages
  • 3. determines own QoS requirements and uses received TSpec
  • 4. sends RESV message including filter and flow spec for each sender’s

flow

  • periodic refresh of ‘soft-state’ via transmission of
  • PATH messages
  • RESV message
  • reservations are only valid for a certain time and TIMEOUT
  • source not restricted from transmitting data at any time
  • packets may go across unreserved routes
  • forwarding protocol must be aware of
  • relation between packets and reserved resources
slide-27
SLIDE 27

mmcom_qos_e-kp.fm 27 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Receiver-Initiated Reservations – Reasons

Dynamic membership:

  • endsystems join and leave transmissions frequently
  • if sender initiated then sender must handle these messages
  • potential overload

Large group size:

  • receiver-initiated scheme reduces sender load
  • merging of reservations

Heterogeneous receivers:

  • world is heterogeneous
  • networks,
  • endsystems
  • receiver knows its requirements best
slide-28
SLIDE 28

mmcom_qos_e-kp.fm 28 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Receiver-Initiated Reservations – Drawbacks

Good reasons, but not always true / applicable Moreover, receiver-orientation leads to other problems, e.g.:

  • RSVP background is large-scale conference
  • this is just one application type
  • suitability for many small-scale applications?
  • e.g., video-conferences, VoD, Internet-Phone ?
  • heterogeneous flows must be supported not only heterogeneous

reservations

  • example:
  • merging of 1 MBit stream with a 100 MBit stream.
  • random drop of 99% of the packets?!
  • filtering on data path necessary,

but, too expensive

  • routing based on QoS characteristics very difficult
  • path set before reservation requirements are known
slide-29
SLIDE 29

mmcom_qos_e-kp.fm 29 8.December.04

www.kom.tu-darmstadt.de www.httc.de

RSVP Messages

RSVP messages are

  • sent as datagrams directly over IP
  • periodically resent:
  • to refresh reservation state
  • to substitute lost messages

Message types

  • PATH
  • RESV
  • error messages (PathErr, ResvErr)
  • teardown messages (PathTear, ResvTear)
slide-30
SLIDE 30

mmcom_qos_e-kp.fm 30 8.December.04

www.kom.tu-darmstadt.de www.httc.de

RSVP – Flow Descriptor

Flow Descriptor = (Q, F) Q = FLOWSPEC:

  • defines desired QoS
  • TSPEC:
  • source behavior, leaky bucket
  • RSPEC:
  • reservation,
  • e.g. delay or priority

F= FILTERSPEC:

  • controls classifier
  • to select the subset of data packets to receive this QoS
slide-31
SLIDE 31

mmcom_qos_e-kp.fm 31 8.December.04

www.kom.tu-darmstadt.de www.httc.de

2.5 RSVP – Merging of Reservations

R1 R2 R3 Sender Merged

10MB 3MB 10MB

Receivers Merging Merging

slide-32
SLIDE 32

mmcom_qos_e-kp.fm 32 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Reservation Styles

Shared vs. distinct reservations:

  • some applications can share a reservation among multiple sources
  • e.g., usually only one person is speaking in a conference
  • other applications need one distinct reservation per source
  • e.g., for video from all persons in a conference

Explicit vs. wildcard sender selection:

  • some applications want to make reservations for explicit senders
  • e.g., teleteaching
  • some applications want to make reservations for any sender
  • e.g., conference

Sender Selection Reservation Distinct Shared Explicit Fixed-Filter (FF) style Shared-Explicit (SE) style Wildcard undefined Wildcard-Filter (WF) style

slide-33
SLIDE 33

mmcom_qos_e-kp.fm 33 8.December.04

www.kom.tu-darmstadt.de www.httc.de

RSVP – Filters

Originally specified filters: wildcard no-filter mode, sender’s flow is not filtered (all senders share the reserved resources) fixed sender’s flow filtered according to a fixed filter during reservation (only single sender can use reserved resources) shared explicit set of specified senders share the reserved resources

slide-34
SLIDE 34

mmcom_qos_e-kp.fm 34 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Merging – Fixed-Filter Style

  • each interface reserves
  • maximum of received reservations for each source
  • separate reservation sent to each requested source

s1 s2 r1 (s1,Q1) r2 (s2,Q2) r3 r4 s3 (s1,Q5) ((s2,Q3), (s3, Q6)) ((s2,Q3), (s3,Q4)) ((s1,Q5), (s3,Q6)) s*: senders r*: receivers Q*: FlowSpec assume: Q1 < Q2 < Q3 < Q4 < Q5 < Q6 U1 U2 D1 D2 D3 U*: upstream interfaces D*: downstream interfaces

slide-35
SLIDE 35

mmcom_qos_e-kp.fm 35 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Merging – Shared-Explicit-Filter Style

  • FilterSpec of merged reservations is union of FilterSpecs
  • FlowSpec of merged reservations is maximum FlowSpec

s1 s2 r1 (s1,Q1) r2 (s2,Q2) r3 ((s2,s3),Q3) r4 ((s1,s3),Q4) s3 (s1,Q4) ((s2,s3),Q4) U1 U2 D1 D2 D3 s*: senders r*: receivers Q*: FlowSpec assume: Q1 < Q2 < Q3 < Q4 < Q5 < Q6 U*: upstream interfaces D*: downstream interfaces

slide-36
SLIDE 36

mmcom_qos_e-kp.fm 36 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Merging – Wildcard-Filter Style

  • each interface reserves maximum of received reservations
  • maximum of all reservations is sent to all sources

s1 s2 r1 (*,Q1) r2 (*,Q2) r3 (*,Q3) r4 (*,Q4) s3 (*,Q4) (*,Q4) s*: senders r*: receivers Q*: FlowSpec assume: Q1 < Q2 < Q3 < Q4 < Q5 < Q6 U2 U1 D1 D2 D3 U*: upstream interfaces D*: downstream interfaces

slide-37
SLIDE 37

mmcom_qos_e-kp.fm 37 8.December.04

www.kom.tu-darmstadt.de www.httc.de

RSVP, Routing and Soft-States

Data forwarding tree is set up by routing protocol ⇒ RSVP and routing are decoupled:

  • simple handling of link failures
  • route flapping possible
  • ".. The key to whether use of BGP will scale to a very large Internet lies in

the stability of inter Autonomous System routing. If routes between Autonomous Systems vary frequently a phenomenon termed FLAPPING then the BGP routers will spend a great deal of their time updating their routing tables and propagating the routing changes.."

  • no hard QoS guarantees

RSVP SOFT STATE MANAGEMENT

  • reservation is set for certain time only:
  • REFRESH by end systems necessary
  • state TIMES OUT if no refresh received and reservations are removed
  • periodic transmission of:
  • PATH from sender
  • RESV from receiver
  • merging at routers possible (e.g., RESVs from multiple receivers)
slide-38
SLIDE 38

mmcom_qos_e-kp.fm 38 8.December.04

www.kom.tu-darmstadt.de www.httc.de

  • 3. DiffServ:

Differentiated Services for the Internet

Background: scaling problems of IntServ

  • administration of each INDIVIDUAL flow
  • huge overhead in large-scale networks
  • recommendation:
  • use IntServ for
  • small closed networks
  • limited amount of (perhaps concatenated) flows

DiffServ:

  • avoids drawbacks of best-effort and IntServ
  • no strong guarantees

but better service than best-effort (= no QoS management)

  • no management of individual flows,

i.e. less overhead

  • minimalistic approach
  • with regard to standardization
  • compatibility to IPv4
slide-39
SLIDE 39

mmcom_qos_e-kp.fm 39 8.December.04

www.kom.tu-darmstadt.de www.httc.de

3.1 DiffServ: Basic Ideas

Aggregation of flows

  • reservations for a group of related flows
  • e.g. all flows in the same (priority) class
  • reservation of a more static nature
  • for a longer period than a flow’s lifetime

Tagging of IP packets

  • DS byte in packet header
  • type of Service byte in IPv4
  • traffic Class byte in IPv6
  • determines treatment of
  • packets within routers
  • e.g. packet priority
  • allows user and/or service

provider

  • to tag packets that shall be

treated with preference

DS Codepoint resvd. DS Byte IPv4 Type of Service IPv6 packet header Traffic Class packet header

slide-40
SLIDE 40

mmcom_qos_e-kp.fm 40 8.December.04

www.kom.tu-darmstadt.de www.httc.de

DiffServ Architecture Example

ISP: Internet Service Provider SLA: Service Level Agreement DS: DiffServ

DS Domain DS Domain DS Domain DS Domain non-DS Domain DS Region 1 DS Region 2 DS Region 3 missing SLA agreement DS Domain DS Domain ISP 2 ISP 3 ISP 1 ISP 4 existing SLA agreement

slide-41
SLIDE 41

mmcom_qos_e-kp.fm 41 8.December.04

www.kom.tu-darmstadt.de www.httc.de

3.2 DiffServ: Proposed Services Expedited / Assured Forwarding

PHB = Per-Hop-Behavior (behavior inside one router)

  • absolute bandwidth allocated to aggregate flows
  • DS byte specifies packet (priority) class
  • Expedited Forwarding (EF),
  • Assured Forwarding (AF),
  • Best-Effort

PDB = Per-Domain-Behavior (behavior inside on provider’s domain)

  • virtual wire (Expedited Forwarding Per-Domain-Behavior EF PDB),
  • assured PDB
  • best-effort PDB
  • bulk-handling PDB

Service (offer by provider to customer)

  • Premium Service
  • Assured Service
  • Best-Effort Service
slide-42
SLIDE 42

mmcom_qos_e-kp.fm 42 8.December.04

www.kom.tu-darmstadt.de www.httc.de

DiffServ: Premium and Assured Service

Premium Service:

  • contract between user and network
  • source and target addresses of an aggregate flow
  • bandwidth available for the flow
  • similar to virtual leased line

Assured Service:

  • no guaranteed bandwidth
  • assurance that a high percentage of the flow will obtain a good service
slide-43
SLIDE 43

mmcom_qos_e-kp.fm 43 8.December.04

www.kom.tu-darmstadt.de www.httc.de

DiffServ: Premium and Assured Service (2)

Routers:

  • classification of packets
  • management of P- and A-Bits
  • policing and shaping of flows
  • based on token buckets
  • scheduling of packets
  • high-priority queue for Premium Service
  • low-priority queue for Assured Service and best-effort packets
  • dropping of best-effort packets with a higher probability than assured packets

Classifier Meter Marker Shaper/ Dropper packets

slide-44
SLIDE 44

mmcom_qos_e-kp.fm 44 8.December.04

www.kom.tu-darmstadt.de www.httc.de

DiffServ: Other Proposed Services

Other proposed service models / pricing schemes:

  • Olympic Services:
  • gold,
  • silver,
  • bronze
  • Paris-Metro Pricing:
  • 1st and
  • 2nd class
  • Cumulus Pricing Scheme, ...
slide-45
SLIDE 45

mmcom_qos_e-kp.fm 45 8.December.04

www.kom.tu-darmstadt.de www.httc.de

  • 4. Price-Controlled Best-Effort

Drawback of IntServ and DiffServ:

  • modifications of Internet routers necessary
  • IntServ and DiffServ Routers are more expensive

Alternative Idea

  • stick to current best-effort services

Advantage

  • best-effort (can be) good enough if there is no congestion
  • best-effort routers are already deployed

Congestion in the future

  • more and more UDP traffic
  • UDP has no congestion avoidance mechanism like TCP

⇒ new congestion avoidance mechanism necessary

slide-46
SLIDE 46

mmcom_qos_e-kp.fm 46 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Basic Idea

Congestion avoidance

  • let users pay if they
  • cause congestion
  • use already congested links,
  • so
  • they have to decide whether
  • it is worth to stay and pay or
  • to reduce the amount of traffic

Fairness

  • bandwidth is allocated proportional to the willingness-to-pay
  • proportional fairness
  • is this “fair”?
slide-47
SLIDE 47

mmcom_qos_e-kp.fm 47 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Realization

Explicit Congestion Notification (ECN)

  • see RFC 2481 (for TCP/IP)
  • and later
  • RFC 3168 with different approach, for IP

Explicit Congestion Notification ECN

  • when a router experiences congestion
  • it marks a number of random packets
  • marking a packet is done

by setting the ECN bit in the TOS byte of the IP Header (IPv4)

  • the receiver informs the sender
  • via TCP ACKs of incoming ECN signals
  • the sender reacts by
  • decreasing its traffic
slide-48
SLIDE 48

mmcom_qos_e-kp.fm 48 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Use with/for Pricing

Using Explicit Congestion Notification ECN for pricing:

  • users pay a small amount of money per ECN mark they receive
  • this gives them an incentive to decrease their traffic but does not force it

Highly dynamic prices

  • users cannot predict prices
  • prices can vary rapidly within seconds

⇒ Risk Broker Security

  • what can stop a provider marking too many packets

⇒ High Competition related to (price-controlled) Best-Effort

  • difficult to set the prices to the right magnitude
  • will probably not be good enough for some applications

Price Controlled Best Effort is not an Internet draft yet.

  • Research
  • e.g. in the EU funded M3I Project and dfn project LetsQoS
slide-49
SLIDE 49

mmcom_qos_e-kp.fm 49 8.December.04

www.kom.tu-darmstadt.de www.httc.de

  • 5. Summary: IntServ, DiffServ,

Price Controlled Best Effort, Best Effort

most interesting multimedia applications are networked

  • traffic requirements are
  • very different from traditional data traffic

QoS control is an essential element of multimedia networking:

  • description
  • negotiation
  • provision

4 approaches

  • IntServ (RSVP)
  • DiffServ
  • Price-Controlled Best-Effort (using ECN marks)
  • Overprovisioning

combinations of those possible / make sense

slide-50
SLIDE 50

mmcom_qos_e-kp.fm 50 8.December.04

www.kom.tu-darmstadt.de www.httc.de

IntServ vs. DiffServ

Internet Integrated Services

  • ratio
  • limited resources
  • hard quality requirements
  • approach
  • resource reservation
  • per connection / flow
  • method
  • distributed signaling protocol
  • router identify flows
  • scheduling
  • services
  • best effort service
  • controlled load service
  • guaranteed service
  • scalability for large-scale net. ?
  • packet classification in core router

Internet Differentiated Services

  • ratio
  • abundance of resources
  • adaptive data streams
  • approach:
  • aggregation of flows
  • reservations for aggregates
  • method
  • static control
  • packets marked with priorities
  • services (suggestions)
  • premium, expedited forwarding &

assured (max. packets high prio)

  • “Olympic”: (Gold 60%, Silver 30%,

Bronze 10% capacity)

  • no hard deterministic guarantees
  • packet classific. at net. borders
slide-51
SLIDE 51

mmcom_qos_e-kp.fm 51 8.December.04

www.kom.tu-darmstadt.de www.httc.de

Coexistence IntServ and DiffServ

IntServ: for small, closed networks

  • e.g. VPN (Virtual Private Network), Corporate Network

DiffServ: for large, open networks

  • e.g. backbones

⇒ IntServ and DiffServ are not necessarily competing Integration is possible: Subnet 1

IntServ

Subnet 2

IntServ

Backbone Network

DiffServ

slide-52
SLIDE 52

mmcom_qos_e-kp.fm 52 8.December.04

www.kom.tu-darmstadt.de www.httc.de

IntServ, DiffServ and Price Controlled Best Effort

Combination

  • Price Controlled Best Effort with ECN
  • in the backbone
  • IntServ or DiffServ
  • in the access network