slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
인터넷 QoS 기술 PowerPoint Presentation
Download Presentation
인터넷 QoS 기술

Loading in 2 Seconds...

play fullscreen
1 / 144

인터넷 QoS 기술 - PowerPoint PPT Presentation


  • 320 Views
  • Uploaded on

인터넷 QoS 기술. 1999. 7. 숭실대학교 김 영 한 yhkim@dcn.soongsil.ac.kr. Content. Introduction Integrated Service Differentiated Service Scheduling algorithm Buffer Management. Existing Internet Model. 인터넷의 급속한 성장 사용자 증가 다양한 응용 프로그램의 출현 both data and real-time applications Weaknesses

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '인터넷 QoS 기술' - seamus


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

인터넷 QoS 기술

1999. 7.

숭실대학교 김 영 한

yhkim@dcn.soongsil.ac.kr

content
Content
  • Introduction
  • Integrated Service
  • Differentiated Service
  • Scheduling algorithm
  • Buffer Management
existing internet model
Existing Internet Model
  • 인터넷의 급속한 성장
    • 사용자 증가
    • 다양한 응용 프로그램의 출현
      • both data and real-time applications
  • Weaknesses
    • Unable to support Quality of Service
    • Does not allow variable grade service
    • charging
    • 망 운용이 어려워지고 있음
      • ( Gateway based on old packet switching techmology)
slide4

Existing Internet Model(cont’d)

  • Current Internet Approach
  • 복잡함
    • 많은 파라미터들과 복잡한 traffic management 방식
    • 사용자의 의식 부족과 망 운용자의 어려움
challenges
Challenges

High speed networks that can provide QoS support

  • Hardware architecture
    • Need a lot of computing cycles
    • Need high bandwidth data paths among CPUs, memory, devices, and network
  • Operating system and protocols
    • Handle continuous flows of data
    • Provide (soft) real time performance
    • Provide inter-stream synchronization
    • Support for multipoint communication
    • Efficient implementations within the constraints of OS and hardware
  • Applications development environment
slide6

What are Quality of Service ?

  • QOS is a concept for specifying how “good” offered (networking) services are [ISO]
    • QoS characterized by specific parameters
    • Parameters vary for different layers
slide7

What are QoS gurantees ?

Ensure that negotiated QOS parameters will

be enforce in spatial (layer) and temporal

(duration of session) dimensions

Types of guarantees

• Guaranteed services enforce parameters negotiated

with QoS specification

Guarantees could be deterministic or statistical

• Predictive services enforce QoS parameters estimated

from past behavior

integrated services intserv
Integrated services(IntServ)
  • Service model
    • Guaranteed service
    • controlled load service
    • best-effort service
  • Protocol support
    • RSVP(Resource reservation protocol)
  • Algorithms
    • scheduling
    • admission control
limitations of resource management architecture today
Limitations of Resource Management Architecture Today
  • IP provides only best effort service
  • IP does not participate in resource management
    • IP cannot provide service quarantees on a per flow basis
    • IP cannot provide service differentiation among traffic aggregates
  • IETF and research community efforts
    • integrated service initiative
    • differentiated services initiative
integrated services internet
Integrated Services Internet
  • Enhance IP’s service model
    • old model : single best-effort service class
    • new model : multiple service classes, including best-effort and QoS classes
  • Create protocols and algorithms to support new service models
    • old model : no resource management at IP level
    • new model : explicit resource management at IP level
  • Key architecture difference
    • old model : stateless
    • new model : per flow state maintained at routers
      • used for admission control and scheduling
      • set up by signaling protocol
components of intserv network
Components of IntServ Network
  • RSVP
    • signaling protocol to set-up
    • tear-down per flow reservation state
  • Packet classifier
    • determine the route and the QoS class for each packet
  • Packet scheduler
    • make forward decisions every packet, to achieve the promised QoS on the particular link-layer medium
  • Admission control
    • determines whether the node has sufficient available resources
  • Policy control
    • determine whether the user has administrative permission to make the reservation
service classes
Service Classes
  • Guaranteed service : hard real-time
    • guarantee a deterministic upper bound on delay for each packet in a session provided that the session does not send more than it specifies
    • admission control based on worst-case analysis
    • per flow queueing support at routers
  • Controlled load service : soft real-time
    • provide a flow with a QoS closely approximating the QoS that the same flow would receive from an unloaded network
    • measurement based admission control possible
    • scheduling for aggregate possible
role of rsvp in the architecture
Role of RSVP in the Architecture
  • Signaling protocol for establishing per flow state
  • Carry resource request from hosts to routers
  • Collect needed information from routers to hosts
  • At each hop
    • consults admission control and policy module
    • sets up admission state or informs the requester of the failure
rsvp design feature
RSVP Design Feature
  • IP Multicast centric design
  • Receiver initiated reservation
  • Different reservation styles
  • Soft state inside network
  • Decouple routing from reservation
rsvp reservation model
RSVP Reservation Model
  • Performs signaling to set up reservation state for a session
  • A session is a simplex data flow sent to a unicast or a multicast address, characterized by
rsvp basic operations
RSVP Basic Operations
  • Sender sends PATH message via the data delivery path
    • set up the path state each router including the address of previous hop
  • Receiver sends RESV message on the reverse path
    • specifies the reservation style, QoS desired
    • set up the reservation state at each router
  • Things to notice
    • receiver initiated reservation
    • decouple the routing from reservation
    • two types of state : path and reservation
example of rsvp basic operation
Example of RSVP Basic Operation

Example

1. Path_msg

S1

2. forwarding Path_msg

R1

R2

D1

S2

R3

3-1.Resv_msg

4. forwarding Resv_msg

D2

3-2. Resv_msg

path message
PATH Message
  • Sender Template : a filter spec identifying the sender
    • whether to forward a RESV message to this sender
      • shared explicit, fixed filter styles
  • Sender Tspec
    • Describes data traffic generated by a sender
    • Never modified in the network
  • Adspec object
    • Describes services and parameters of the path
    • May be updated by network elements
sender tspec usage
SENDER_TSPEC Usage
  • Delivered to both intermediate network elements and receiving applications
  • Each intermediate network element uses SENDER_TSPECs and information arriving in the RESV messages to make an appropriate resource reservation from the desired service
  • Receiver uses SENDER_TSPEC and ADSPEC to pick a service
sender tspec format
SENDER_TSPEC Format

0 (version)

reserved

7 (overall length)

1 (general)

0

reserved

6 (service data length)

127 (tb tspec)

0 (flags)

5 (parameter length)

token bucket rate

token bucket size

peak data rate

minimum policed unit

maximum packet size (MTU)

resv message
RESV Message
  • FLOWSPEC object
    • Tspec
      • Describes the traffic flow desired
    • Rspec
      • Parameters required to invoke the desired service
    • Transmitted upstream to intermediate network nodes and senders
    • May be merged at intermediate network nodes
specification of reservation with resv message
Specification of Reservation with RESV Message
  • A reservation request or flow descriptor has two parts
    • flow spec and filter spec
  • Flow spec specifies desired QoS parameters
    • used by admission control module during set up time
    • used by traffic control module or packet scheduler
  • Filter spec specifies the set of data packets that can use the reservation
    • list of <IP source addr, port number>
    • empty list means wildcard or any source can use the resource
flow spec
Flow Spec
  • Tspec :traffic specification
    • p : peak rate of flow
    • b : bucket depth of maximum burst size
    • r : token bucket rate or long term average rate
    • m : minimum policed unit
    • M : maximum datagram size
  • Rspec : resource specification
    • R : required service rate, must be no less than r
    • S : Slack term
flowspec usage
FLOWSPEC Usage
  • Intermediate network nodes
    • Merge multiple FLOWSPECs
    • Make appropriate service reservation
  • FLOWSPECs arrive at senders
    • Sender use new minimum MTU value for sending
flowspec format
FLOWSPEC Format

0 (version)

reserved

overall length

service id

0

reserved

service data length

127 (tb tspec)

0 (flags)

5 (parameter length)

token bucket rate

token bucket size

peak data rate

minimum policed unit

maximum packet size (MTU)

Rspec for invoking QoS control

(parameter header, parameter) pair

performance guarantee
Performance Guarantee
  • Delay has two components
    • fixed component : sum of propagation and switching delays along the path, a function of the path
    • variable component : sum of queueing delays along the path, a function of the service
  • Guaranteed service provides a bound on queueing delay
    • a function of Tspec and Rspec
    • calculated based on the fluid model
reservation style
Reservation Style
  • Motivation : achieve more efficient resource utilization in multicast (M*N)
  • Observation: in a video conferencing when there are M senders, only a few can be active simultaneously
    • multiple senders can share the same reservation
  • Various reservation style specify different rules for sharing among senders
reservation styles and filter spec
Reservation Styles and Filter Spec
  • Reservation style
    • use filter to specify which senders can use the reservation
  • Three styles
    • fixed filter : no sharing among senders, sender explicitly identified for the reservation

< IP source addr, port number >

    • wildcard filter : sharing among senders, sender explicitly identified for the reservation

empty list or *

    • shared explicit filter : resource shared by senders that are explicitly specified

< IP source addr, port number >

fixed filter example
Fixed Filter Example

FF(S1{4B}, S2{5B})

S1

R1

FF(S1{4B})

S1{4B}

S2{5B}

S1{3B}

S3{B}

FF(S1{3B}, S3{B})

R2

FF(S1{B})

S2

FF(S2{5B}, S3{B})

R3

S3

Router

Host

wildcard filter example
Wildcard Filter Example

WF(*{4B})

S1

R1

WF(*{4B})

*{4B}

*{3B}

WF(*{3B})

R2

WF(*{4B})

S2

WF(*{4B})

R3

S3

Router

Host

reservation merging
Reservation Merging
  • Multiple receivers of same session may request reservation for the same sender
  • Intermediate router merge requests and pass one message to upper link
  • Reserve message forwarded according to the path state that was set up by the path message
  • What if different receivers request different QoS?
    • conflicting styles not permitted
    • merging reservations means computing maximum of the reservation requested
    • may have to reject the larger request
one pass with advertising opwa
One Pass With Advertising (OPWA)
  • Improvement over basic model
  • Motivation
    • collect information along the path so that receivers can make better reservation request
  • Optional Adspec object in PATH message
    • Default General Parameters fragment
    • Service specific fragment such as Guaranteed service or Controlled load service fragment
adspec usage
ADSPEC Usage
  • Sender initialized
  • At each network element
    • Each service updates its section of ADSPEC
    • Break bit is set if the service is absent
    • General parameters break bit is set if a non-RSVP hop is on the path
    • Services may override general parameters
  • Receiver discovers whether RSVP is fully supported and what services are available
adspec usage cont
ADSPEC Usage (cont.)
  • Receiver discovers the path maximum transfer unit (MTU)
    • QoS control may place an upper bound on packet size
    • Use default MTU unless overridden
  • Receiver uses SENDER_TSPEC and ADSPEC to pick the right service
adspec format
ADSPEC Format

0 (version)

reserved

service data length

default general parameters fragment (service 1)

service i specific fragment

service j specific fragment

more services specific fragments……..

soft state
Soft State
  • Per session state has a timer associated with it
    • path state, reservation state
  • State lost when timer expires
  • Sender/Receiver periodically refreshes the state, resends PATH/RESV messages, resets timer
  • Claimed advantages
    • no need to clean up dangling state after failure
    • can tolerate lost signaling packets
      • signaling message need not be reliably transmitted
    • easy to adapt to route changes
  • State can be explicitly deleted by a Teardown message
rsvp and routing
RSVP and Routing
  • RSVP designed to work with variety of routing protocols
  • Minimal routing service
    • RSVP asks routing how to route a PATH message
  • Route pinning
    • addresses QoS changes due to “avoidable” route changes while session in progress
  • QoS routing
    • RSVP route selection based on QoS prarmeters
    • granularity of reservation and routing may differ
  • Explicit routing
    • Use RSVP to set up routes for reserved traffic
recap of rsvp
Recap of RSVP
  • PATH message
    • sender template and traffic spec
    • advertisement
    • mark route for RESV message
    • follow data path
  • RESV message
    • reservation request, including flow and filter spec
    • reservation style and merging rules
    • follow reverse data path
  • Other messages
    • PathTear, ResvTear, PathErr, ResvErr
why diffserv
WHY DiffServ
  • Service Providers 요구
    • Scalability
    • 간단한 implementation과 관리
    • 서비스에 따른 차등화된 pricing
  • Users 요구
    • Better than best effort service
      • Bandwidth guarantee
      • Low Delay & Jitter & Loss
    • Predictable service
definition cont
Definition (cont.)
  • Scalable Service differentiation
    • Using DSCP(DiffServ Code Point) of IP Header
      • Traffic classification state를 줄일 수 있음.
      • 적절한 PHB선택을 위해 marking
    • Traffic aggregation
      • Micro-flow state를 유지할 필요가 없음
    • 복잡한 작업을 망의 edge 노드에서 수행
      • 내부 라우터의 기능을 간소화
architecture
Architecture
  • DS Domain
    • DS node들의 연속적인 집합
    • 같은 관리를 받는 여러 network들
  • DS Edge Node
    • DS domain의 경계
    • DS Ingress Node & Egress Node
    • Traffic conditioning 기능 수행
architecture cont
Architecture (cont.)
  • Interior Node
    • DS domain 내에서 다른 interior node 나 edge node와 연결
    • Domain에서 지원하는 PHB group의 정의에 따라 DS codepoint에 의한 패킷 전달이 가능
    • 제한된 Traffic conditioning 기능이 가능하다.
dscp diffserv code point
DSCP (DiffServ Code Point)

IPv4 Header (first 32bits)

4-bit header length

8-bit type of

service (TOS)

4-bit version

16-bit total length (in byte)

6-bit DSCP for

Per-Hop Behavior

2-bit

CU

Currently Unused

8-bit

TrafficClass

4-bit version

20-bit Flow Label

IPv6 Header (first 32bits)

sla tca
SLA & TCA
  • Service
    • quantitative service
    • qualitative service
  • SLA (Service level agreement)
    • dynamic : 망의 변화에 맟춰서 변동가능
    • static : 관리자가 manual에 따라 set
  • TCA (Traffic conditioning agreement)
phb per hop behavior
PHB (Per Hop Behavior)
  • Hop by Hop의 행동방침
  • Small set (building-block) of aggregation flow
  • 서비스의 품질 종류
    • Default PHB
    • AF (Assured Forwarding) PHB
    • EF (Expedited Forwarding) PHB
phb cont
PHB (cont.)
  • Default PHB
    • 최소한의 resource할당 되어져야한다.
      • For non-ds traffic.
      • DSCP ; 000000
  • Class Selector Code Point : xxx000
    • backward compatibility
    • 상대적인 우선순위
    • routing signalling traffic등에 사용
af phb
AF PHB
  • Key Idea
    • Traffic 특성으로 다수의 class로 구분.
    • congestion상황에서도 drop level을 차별화 해서 minimum rate을 보장.
  • 3개의 Drop precedence 갖는 4개의 class로 구성
  • 각 class는 독립적이고, class간의 관계는 아직 불명확하다.
af phb cont
AF PHB (cont.)
  • 각 class에게는 최소한의 forwarding resource가 보장되어야 한다.
  • Reordering 방지
    • 각 class는 각각의 queue 가짐
  • Forwarding assurance level 결정요인
    • 패킷이 속한 AF class에 할당된 resource양
    • Class에 존재하는 active load수
    • Congestion상황 : Drop precedence level
ef phb
EF PHB
  • Key Idea
    • Low loss, delay & jitter 실현
    • 각 Node의 queueing 방법이 해결과제
      • 각 node에서 Max arrival rate을 min departure rate보다 작게 해주는 것으로 극복
  • Top-priority traffic
    • 다른 PHB group나 traffic을 가로채기 할 수 있다.
    • premium service, virtual leased line service
ef phb cont
EF PHB (cont.)
  • Requirements
    • 사용 대역폭의 엄격한 제한필요
    • Excess traffic -> Drop at ingress router
      • conformant flow 에 영향 없도록
    • 망을 지나온(experienced) traffic의 delay, jitter는 매우 작아야 한다.
diffserv edge node
DiffServ Edge Node
  • Packet Classify
    • BA (Behavior aggregate) classifier
    • MF (Multi Field) classifier
  • Traffic Conditoning
    • Meter (Traffic Measuring)
    • Marker (DSCP)
    • Policer (Shaper & Dropper)
diffserv edge node cont
DiffServ Edge Node (cont.)

EF

  • Marker

AF

BE

  • Classifier
  • Meter
  • Policer

Shape

Drop

Traffic Conditioner

traffic conditioner
Traffic Conditioner
  • Classifier
    • 패킷 header 내의 특정 영역들을 참고로 하여 traffic stream으로부터 특정 packet들을 선택
    • 적절한 PHB 선택
      • BA(Behavior Aggregate) Classifier
        • DS field만을 참고
      • MF Classifier (Multi-field Classification)
        • 다른 여러 개의 field를 참고 한다.
        • src/dst address field, port field
traffic conditioner cont
Traffic Conditioner (cont.)
  • Meter
    • Classifier에 의해 선택된 packet들을 TCA 의 profile을 기반으로 measuring
      • in-profile packet인지 out-of-profile packet인지 판별
    • Measuring
      • Using TSW(Time sliding window)
        • Average rate estimator
      • Using Leaky Bucket algorithm
        • Token bucket estimator
traffic conditioner cont1
Traffic Conditioner (cont.)
  • Marker
    • Packet header 내의 DS field 값을 특정 codepoint 값으로 설정 (DSCP)
    • Recommended codepoint value
      • Best Effort : 000000 (Default value)
      • EF : 101000
      • AF : 4개의 class(3bit) 와 3개의 drop precedence에 따라서 다름 (12가지)
        • TCM (Three Color Marker)
traffic conditioner cont2
Traffic Conditioner (cont.)
  • Marker (cont.) - TCM
    • AF의 3가지 차별화된 drop precedence에 적합한 marker
    • trTCM(two rate TCM)
      • 두 rate(PIR,CIR)과 두 bucket size(PBS,CBS)를 근거로 Green, Yellow, Red mark
    • srTCM(single rate TCM)
      • CIR 하나의 rate과 CBS, EBS 두 bucket size를 근거로 mark.
traffic conditioner cont3
Traffic Conditioner (cont.)
  • Marker (cont.) - TCM
  • Mode
    • Color Blind Mode (No Pre-marked)
    • Color Aware Mode (Pre-marked)
  • Result
  • Marked
  • Packet
  • Stream
  • Packet
  • Stream
  • Marker
  • Meter
traffic conditioner cont4
Traffic Conditioner (cont.)
  • Marker (cont.) - trTCM -color blind mode

Token

PIR times/sec

PBS

Tp

  • Packet
  • Stream

계산

  • pkt
  • pkt
  • pkt

Token

CIR times/sec

CBS

  • Marked
  • Packet
  • Stream

Tc

traffic conditioner cont5
Traffic Conditioner (cont.)
  • AF PHB Marking
    • Tp(t) - B < 0 ( green,yellow token 부족 )
      • red maps to AFx3
    • Tc(t) - B < 0 ( green token 부족 )
      • yellow maps to AFx2
    • else ( enough both token )
      • green maps to AFx1
    • treatment of packets after marking is service specific
traffic conditioner cont6
Traffic Conditioner (cont.)
  • Shaper
    • Traffic stream을 traffic profile에 맞추기 위해 하나 또는 여러 개의 packet들을 지연
  • Dropper
    • Buffer 크기를 0 또는 작은 값으로 설정함으로써 discard policer를 구현

Packet discarding policy

Traffic shaping policy

diffserv core node cont
DiffServ Core Node (cont.)
  • BA Classifier
    • 적절히 Marking되어온 flow의 DSCP만으로 각 queue에 할당
    • AF,EF : CBQ등으로 resource 할당
  • AF : 3가지 dorp precedence를 위해 차별화 할 수 있는 buffer management 필요.
    • RIO, WRED, FRED, GRED
  • EF : PQ, WRR등으로 최고 우선순위 할당
qbone architecture internet2
Qbone Architecture-Internet2
  • BB(Bandwidth Broker)
    • a type of policy server
    • manage the QoS resource based on the SLD
  • SLD(Service Level Descriptions)
    • a translation of a SLA for provisioning & alloc- ating QoS resource within the network device.
  • RAR(Resource Allocation Request)
qbone architecture internet2 cont
Qbone Architecture-Internet2(cont.)
  • BB2
  • BB1
  • BB3
  • RARs
  • END USERs
  • SLDs
  • SLDs
  • AS1
  • AS2
  • AS3
  • Inter_domain
  • BBAC
  • Sample Network Configuration
  • Intra-domain
qbone architecture internet2 cont1
Qbone Architecture-Internet2(cont.)
  • Service allocation in customer domain
    • Application들이 SLA에 의해 정의된 service를 share하는 방법 (basically two choices)
      • Host decide for its applications
      • Consult a central controller for an appropriate service
        • central controller : BB (bandwidth broker)
          • sender의 요구에 맞는 service class결정후 reply
          • RSVP, SNMP, LDAP사용 classification, marking, shaping rule을 set (at leaf router)
          • reshaping rules set (at exit router)
qbone architecture internet2 cont2
Qbone Architecture-Internet2(cont.)
  • Resource allocation in ISP Domain
    • Static SLA
      • boundary router can be mannually configured
      • AF : oversubscribed 가능
        • statistical multiplexing 얻기위해
      • EF : oversubscribed 불가능
    • Dynamic SLA
      • signalling process필요
        • eg) RSVP message using.
europe 3 level scenarios
Europe-3 level scenarios
  • DiffServ: Test specification (Europe)
    • Three different scenarios
      • 1. IP precedence based QoS mechanisms
      • 2. DiffServ architecture
      • 3. Mixed DiffServ - IntServ architecture
  • IP precedence based QoS mechanisms
    • Tests give the possibility to divide traffic into different classes and to reserve an amount of bandwidth on a best-effore connection.
europe 3 level scenarios cont
Europe-3 level scenarios(cont.)
  • DiffServ architecture
europe 3 level scenarios cont1
Europe-3 level scenarios(cont.)
  • DiffServ architecture (cont.)
    • Tentative list
      • Exedited Forwarding
      • Assured Forwarding
    • Divided into several diffserv clouds
      • a set of diffserv stub domains
    • Core domain interconnecting several stub networks
    • Point to point connection : ATM connection.
europe 3 level scenarios cont2
Europe-3 level scenarios(cont.)
  • Mixed DiffServ - IntServ architecture
measurement mechanisms ewma
Measurement Mechanisms- EWMA
  • Exponential Weight Moving Average
    • ri : A-second interval 동안 측정된 arrival rate
    • Average arrival rate 계산
    • Time constant
measurement mechanisms tsw cont
Measurement Mechanisms - TSW (cont.)
  • TSW(Time Sliding Window) rate estimator
    • Provide a smooth estimate of the TCP sending rate over
    • a period of time.
    • Estimates the sending rate upon each packet arrival.
    • Maintain three state variable
      • Win_length : which is measured in unit of time
      • Avg_rate : the rate estimate upon each packet arrival
      • T_front : the time of last packet arrival
measurement mechanisms tsw cont1
Measurement Mechanisms- TSW (cont.)
  • Initially;
  • Win_length = a constant;
  • Avg_rate = connection’s target rate, Rt;
  • T_front = 0;
  • Upon each packet arrival,
    • Byte_in_TSW = Avg_rate * Win_length;
    • New_bytes = Bytes_in_TSW + pkt_size;
    • Avg_rate = New_bytes / ( now - T_front + Win_length);
    • T_front = now;
  • Whereas, now is the time of current packet arrival ;
  • and pkt_size is the packet size of the arriving packet;

TSW algorithm

measurement mechanisms tsw cont2
Measurement Mechanisms- TSW (cont.)

Win_length

pkt

pkt

pkt

pkt

pkt

Avg_rate

Bytes_in_TSW = Avg_rate * Win_length

New arrival pkt

pkt

pkt

pkt

T_front

now

New_bytes = Bytes_in_TSW + pkt_size

Avg_rate = New_bytes / ( now - T_front + Win_length )

classifier
Classifier
  • Identify the context of packets to apply the actions necessary to satisfy service requirement
    • traditional application
      • providing firewall and security functions
    • another important application
      • identification and classification of packets so as to provide the resources necessary for meeting customer-specific differentiated services requirements
classifier cont
Classifier (cont.)
  • Desirable attributes
    • must apply to various ranges.
      • ex) addresses, port numbers, protocol, etc.
    • should be applied to aggregates and keeps the number of rules to be specified manageable.
    • Rules must be assigned explicit priorities in order to resolve conflicts if rules overlap.
classifier cont1
Classifier (cont.)
  • General packet classification problem
    • A point location problem in multi-dimensional space
    • Problem of finding the object that contains a point in multi-dimensional space
scheduler
Scheduler
  • Scheduler 의 분류
  • Desirable Attributes of a Scheduling Algorithm
  • GPS(Generalized processor sharing)
  • Scheduling Algorithms
    • WFQ, SCFQ, VC, FBFQ, WF2Q, WF2Q+, etc.
  • Hierarchical Link-sharing
    • CBQ, H-PFQ
scheduler1
Scheduler의 분류
  • Frame-based Scheduler
    • 시간을 고정된,또는 변환할 수 있는 길이의 frame으로 나눈다.
    • 한 frame 동안 전송되어야 하는 양으로 예약
    • 예) Round-robin scheduler
  • Sorted-priority Scheduler
    • global 변수를 사용하여 outgoing link schedule된다.
    • GPS(generalized processor sharing)를 기본으로 한다.
    • 예)Virtual Clock, Weighted Fair Queueing,…
desirable attributes of a scheduling algorithm
Desirable Attributes of a Scheduling Algorithm
  • Isolation of flow
  • Low end-to-end delay
  • Utilization
  • Fairness
  • Simplicity of implementation
    • timestamp 계산하는데 드는 복잡도
    • 다음에 전송할 packet을 찾는데 드는 복잡도

==> 일반적으로 O(logV), 여기서 V는 output link를 sharing

하는 session의 수

  • Scalability
slide83
GPS
  • GPS(Generalized processor sharing)
    • 많은 sorted-priority scheduler 설계의 기본
    • GPS multiplexing은 fluid-flow model
      • 이상적인 scheduling 원칙
      • traffic은 무한히 쪼개질 수 있다고 가정
    • Service 원칙
      • 각 session들은 최소한 자신에게 예약된 rate으로 서비스 받음.
      • 잉여 대역폭은 각 session에 할당된 대역폭에 비례적으로 서비스 받음.
slide84

GPS (cont.)

  • The Operation of GPS

wi(t) = wj(t) where i,j  B(t)

Session 1

Output Link

Session 2

Session 3

* 각 session에 예약된 service rate은 모두 같다고 가정

slide85

GPS (cont.)

  • GPS의 문제점
    • 실제 network에서는 구현 불가능한 개념
      • Server는 동시에 여러 session에게 service를 못하므로
      • 모든 packet들은 다른 session으로 service가 넘어가기 전에 service가 완료되어져야만 하므로
  • 개선책
    • normalized service를 다음과 같이 제공 가능

=> fairness 유지가 중요

approximation of gps
Approximation of GPS
  • System & Session Potential

Scheduler

p2

p1

p4

System

potential

p3

algorithms
Algorithms
  • WFQ(Weighted Fair Queueing)
  • SCFQ(Self-Clocked Fair Queueing)
  • Virtual Clock
  • FFQ(Frame-Based Fair Queueing)
  • SPFQ(Starting Potential-Based Fair Queueing)
  • WF2Q(Worst-case Fair Weighted Fair Queueing)
  • WF2Q+
  • CBQ(Class based Fair Queueing)
  • H-PFQ(Hierarchical Packet Fair Queueing)
slide88
WFQ
  • 배경
    • GPS를 실제 network에 적용하기위해
  • WFQ는 GPS에 대한 Approximated fair queueing
    • 실제 packet-based traffic에 적용할 수 있다.
  • WFQ와 동일한 scheme들
    • PGPS : Packet-by-packet generalized processor sharing
  • WFQ의 Service 원칙
    • Finish tag 값 중 작은 것부터 service
    • Finish tag
wfq cont
WFQ(cont.)
  • WFQ의 Virtual time function
    • GPS를 흉내내기위한 도구
    • Virtual time의 계산
wfq cont1
WFQ (cont.)

Session 1

Output Link

Session 2

Session 3

* 각 session에 예약된 service rate은 모두 같다고 가정

wfq cont2
WFQ(cont.)
  • 문제점

Virtual time update (WFQ system에서 event 발생시마다)

    • Backlogged session들에 대한 추적이 필요(overhead)
    • event발생이 빈번하면 virtual time 계산이 복잡
    • server의 load가 증가한다

=> High speed network에,그리고 traffic이 많을 때 부적합

slide92
SCFQ
  • 등장배경
    • virtual time 계산의 복잡성을 줄이기 위해
  • Virtual time 값
    • 현재 service받고 있는 packet의 finish tag 값
  • Finish tag :
  • Service 방식
    • 가장 작은 finish tag값을 가진 packet을 service
scfq cont
SCFQ (cont.)
  • SCFQ 특성
    • Latency :
    • Fairness index :
    • Complexity : O(1)
scfq cont1
SCFQ (cont.)
  • 장점
    • 내부적으로 생성된 virtual time을 사용
      • virtual time 계산의 복잡성을 줄임
  • 단점
    • session간의 isolation 특성이 좋지 않다.
    • delay bound가 backlog된 session의 개수에 비례적으로 증가
    • session의 수가 증가할수록 성능저하
      • 많은 사용자를 수용하는 광대역 망에서 delay 성능 저하
virtual clock server
Virtual Clock Server
  • Virtual time : packet arrival시의 real-time 사용
  • Finish tag
  • Latency :
  • fairness index :
  • complexity : O(1)
  • delay bound가 보장되지 않는다.
frame based fq
Frame-based FQ
  • 등장배경
    • 간단한 방법으로 system potential을 계산하기위해
    • 각 session potential과 system potential과의 차이의 한계를 좁히기 위해(framing 기법을 사용)
  • Framing 기법

F는 한 frame 동안 전송된 bit수, r은server의 service rate

frame based fq cont
Frame-based FQ(cont.)
  • Frame update operation
    • system potential recalibration process
    • k번째 frame update point
      • 모든 backlogged session potential 값이 kT보다 큼
      • 임의의 session potential이 (k+1)를 넘지않음

==>위의 두 조건을 모두 만족하는 시점

frame based fq cont1
Frame-based FQ(cont.)
  • Frame & System potential update operation
frame based fq cont2
Frame-based FQ(cont.)
  • Example operation
frame based fq cont3
Frame-based FQ(cont.)
  • Latency :
  • Complexity : O(1)
  • 단점
    • frame이 update되기 전에는 system potential이 real time으로 증가하므로 session potential과 차이가 남

==> fairness에 영향을 준다.(성능의 저하)

starting potential fq
Starting-Potential FQ
  • 등장 배경
    • Frame-based FQ의 fairness 특성을 개선하기위해
      • 매 packet의 service가 끝나는 시점을 System potential update 시점으로 함
  • Starting Potential :
    • fluid model에서 session i의 head에 있는 packet이 service받기 시작할 때의 session i의 potential
  • Base potential function :
starting potential fq cont
Starting-Potential FQ (cont.)
  • The operation of SPFQ
    • Session & base potential update
      • 각 session queue의 head에 새로운 packet이 위치할 때 마다
    • System potential update
      • 매 packet의 service가 끝나는 시점에 system potential 값이 base potential값보다 작을 때

system potential <== base potential

starting potential fq cont1
Starting-Potential FQ (cont.)
  • Latency :
  • Complexity : O(1)
  • SPFQ의 장점
    • Frame-based FQ보다 session과 system potential간의 차이가 줄어든다 ==> fairness 특성이 좋아짐
    • Starting potential을 이용하여 system potential을 update, 그리고 service 받을 packet을 선택

==>packet-by-packet server에 적절

group priority scheduling
Group priority scheduling
  • Basic idea
    • flow상의 연속적인 packet들을 몇 개의 Group으로 나눈다.
    • 각 Group내의 packet들은 동일한 priority 값을 가진다.
    • Group priority value는 그 group에 속한 packet중 가장 큰 값으로 선택된다.
    • Scheduler는 group priority value로 group내의 모든 packet을 scheduling한다.
wf 2 q
WF2Q
  • Worst-case Fair Weighted Fair Queueing
  • 배경
    • WFQ의 문제점을 해결하기 위해
      • GPS와 WFQ에서 제공된 서비스량의 차이가 크다.
      • WFQ는 GPS에 가장 근사화 된 알고리즘이 아니다.
  • 서비스 원칙
    • Smallest Eligible virtual Finish time First (SEFF)
  • Eligibility of packet
    • GPS system에서 서비스를 시작했을 것으로 예상되는 패킷
wf 2 q1
WF2Q
  • Packet Arrivals
wf 2 q2
WF2Q
  • GPS service order
    • service share - session 1: 0.5, session 2,..,11: 0.05
wf 2 q3
WF2Q
  • WFQ service order
    • service share - session 1: 0.5, session 2,..,11: 0.05
wf 2 q4
WF2Q
  • WF2Q service order
    • service share - session 1: 0.5, session 2,..,11: 0.05
wf 2 q5
WF2Q+
  • 배경
    • WF2Q의 특성을 유지
    • WF2Q의 구현 복잡도를 줄이기 위해
  • 서비스 원칙
    • WF2Q와 같은 SEFF 원칙 사용
    • Virtual time function
    • Virtual start time
    • Virtual Finish time ( = Finish tag )
wf 2 q6
WF2Q+
  • Service order
    • service share - session 1: 0.5, session 2,..,11: 0.05
cbq class based fair queueing
CBQ(class based fair queueing)
  • Policy goals for CBQ
    • 각 connection들이 요구하는 bandwidth 보장
    • QoS 지원
    • link-sharing의 flexibility 제공
  • Goals of link-sharing
    • 각 class에 할당된 bandwidth를 rough하게 보장
    • Excess bandwidth를 합당한 방식으로 분배
example class hierarchy

Link

40%

10%

50%

Agent

A

Agent

B

Agent

C

real-

time

telnet

ftp

IP

DEC-

net

real-

time

telnet

ftp

30%

10%

10%

20%

3%

2%

5%

real-

time

telnet

ftp

15%

5%

0%

Example class hierarchy
cbq cont
CBQ(cont.)
  • Mechanisms
    • Classifier : map arriving packets to classes.
    • Estimator : compute a short-term estimate of

the class’s bandwidth.

    • Selector : 다음에 서비스 받을 패킷을 선택
    • Delayer : congestion시 overlimit인 class에

해당하는 패킷의 서비스를 지연시킨다.

cbq cont1
CBQ(cont.)
  • Definition
    • General and link-sharing scheduler
    • Regulated and unregulated classes
    • Overlimit, underlimit, and at-limit classes
    • Satisfied and unsatisfied classes
    • Levels in the class structure
cbq cont2
CBQ (cont.)

Overlimit class

Level 3

Underlimit class

A

B

Level 2

Class to be regulated

UnsatisfiedClass

1

1

Level 1

2

2

Persistent backlog

1,2 : priority

cbq cont3
CBQ (cont.)
  • Formal link-sharing guidelines :
    • A class can continue unregulated if one of the following condition hold

1. The class is not overlimit, OR

2. The class has a not-overlimit ancestor at level i and there are no unsatisfied classes in the link-sharing structure at levels lower than i.

    • Otherwise, the class will be regulated by the link-sharing scheduler
example of link sharing guideline
Example of link-sharing guideline

Overlimit class

Underlimit class

A

B

Class to be regulated

UnsatisfiedClass

1

1

2

2

Persistent backlog

1,2 : priority

approximation to the formal link sharing guidelines
Approximation to the formal link-sharing guidelines
  • Ancestors-Only link-sharing guidelines
    • A class can continue unregulated if one of the following conditions hold:

1. The class is not overlimit, OR

2. The class has an underlimit.

    • Otherwise, the class will be regulated by the link-sharing scheduler.
  • Advantages : ease and efficiency of implement
  • Disadvantages : performance is less robust
approximation to the formal link sharing guidelines cont
Approximation to the formal link-sharing guidelines (cont.)
  • Top-Level link-sharing guidelines
    • A class can continue unregulated if one of the following conditions hold:

1. The class is not overlimit, OR

2. The class has an underlimit ancestor whose level is at most Top-Level.

    • Otherwise, the class will be regulated by the link-sharing scheduler.
approximation to the formal link sharing guidelines cont1
Approximation to the formal link-sharing guidelines(cont.)
  • Heuristics for setting the Top-Level variable

1. If a packet arrives for a not-overlimit class, set Top-Level to 1.

2. If Top-Level is i, and a packet arrives for an overlimit class with an underlimit parent at a lower level than i (say j), then set Top-Level to j.

3. After a packet is sent form a class, and that class now either has an empty queue or is unable to continue unregulated, then set Top-Level to Infinity.

observations of cbq
Observations of CBQ
  • Most rules are heuristic
    • definition of overlimit, underlimit, and at-limit classes
    • different link-sharing policies
  • Many parameter, difficult to understand
  • No firm guarantees
  • Fundamental problem
    • more difficult to provide QoS in a hierarchy
hierarchical packet fair queueing
Hierarchical Packet Fair Queueing
  • Start with an idealized model that can capture all the requirements
  • Develop practical algorithms to approximate the ideal model
    • Hierarchical GPS model
    • Hierarchical PFQ algorithm
hierarchical gps
Hierarchical GPS
  • A Formal Model
h gps
H-GPS
  • Hierarchical Generalized Processor Sharing
    • service multiple queues simultaneously, in proportion to service shares
    • parent node distributes bandwidth instantaneously to children nodes
  • Advantages
    • proven end-to-end delay bounds for guaranteed traffic
    • ideal semantics of fairness and hierarchical bandwidth distribution
    • techniques to estimate available bandwidth for best-effort traffic
hierarchical pfq
Hierarchical PFQ
  • Packet algorithms approximating the fluid H-GPS algorithm
  • Difference of H-GPS from GPS
    • finishing order of packets currently in system dependent on future arrival
    • reason: ratio of service shares of two backlogged sessions may change due to new backlogged sessions
  • Solution
    • not assign virtual finish time to each packet upon arrival at its queue
    • only assign virtual finish time to each packet on arrival at head-of-line of its queue
  • Organize on level Packet Fair Queueing algorithms into a hierarchy
slide127

Active Buffer Management

  • RED ( Rendom Early Detection )
  • ECN ( Explicit congestion notification )
  • with RED
  • FRED (Flow Random Early Detection)
  • RIO ( RED In and Out )
  • WRED (Weighted Random Early Detection)
slide128
RED
  • The Environment
    • - Feedback based transport protocols ( e.g TCP )
  • Drop-tail

Transmit

Flow 1

Flow 2

Output

Flow 3

Full

Drop

- Gateway의 buffer가 차면 이후 도착하는 패킷을 폐기

slide129

RED (cont.)

  • Problems with current Drop-Tail gateways
    • large average dealy
    • distribute losses among connections
    • biases against bursty traffic
    • global synchronization
    • no control over packet drops
  • Drop-tail
  • Random - Drop gateways give the gateway some control of which packet to drop, but don’t take car of all of the problems of Drop -Tail gateways
slide130

RED (cont.)

  • Drop tail vs RED

Drop-tail

RED

- drop-tail : queue가 모두 찬 후에 congestion을 감지

- RED : congestion을 사전에 감지

slide131

RED

  • RED Design goals
    • congestion avoidance
    • global synchronization avoidance
    • avoidance of bias against bursty traffic
    • bound on average queue length
  • RED (Random Early Detection)

Maxth

Maxth

Minth

AvgLen

slide132

RED (cont.)

  • Algorithm for RED
  • For each packet arrival
    • if avglen < MinThreshold queue the packet
    • if MinThreshold < avglen < MaxThreshold  calculate probability P  drop the arriving packet with probability P
    • if avglen  MaxThreshold  drop the arriving packet
slide133

RED (cont.)

  • high throughput,
  • low average delay
slide134

RED (cont.)

Calculating the packet drop probability

  • Method 1:
  • The packet marking probabiluty p is a linear fucntion of avg.
  • Pb <-- maxp ( avg - minth ) / ( maxth - minth )
  • This gives geometric (roughly exponential ) intermarking
  • intervals ( the number of packets between marked /dropped
  • packets ).
slide135

RED (cont.)

Method 2 :

The packet marking probability increases as count, the

number of packets since the last marked packet increases.

Pa = pb / ( 1 - count pb )

This gives intermarking intervals uniform on [1,1/pb]

slide136

ECN with RED (cont.)

  • ECN(Explicit Congestion Notification) with RED
  • Work well for bulk data transfer
  • Does not work well for delay sensitive applications
    • audio, WEB, telnet
  • Explict Congestion Notification (ECN)
    • borrow ideas from DECbit
    • use two bits in IP header
  • IP header
    • ECN-Capable Transport (ECT) bit set by sender.
    • Congestion Experienced (CE) bit set by router.
slide137

FRED

  • FRED (Flow Random Early Detection)
  • Emulating fair bandwidth allocation by using FIFO and
  • smart buffer management techniques
  • Ideas
    • each flow counter Qi : number of buffers used by the
    • Qave : estimated queue occupancy
    • two global variables : min_thres, max_thres
slide138

FRED (cont.)

  • Algorithm for FRED

If ( Qi > Qave / N )

drop

Else if ( Qave > min_th )

random drop

Else

accept

slide140

RIO

  • RIO (RED In/Out)
  • Differential dropping in the gateway
  • RED gateway with In/Out bit
  • twin RED algorithms for dropping
    • two sets of parameters
    • In packet / Out packet
  • Different levels of best-effort service in times of Network congestion
slide141

RIO (cont.)

  • RIO (RED In/Out)

P(drop_out)

P(drop_in)

1

1

P max_out

P max_int

avg_total

avg_in

Min_in

Max_in

Min_out

Max_out

  • In packet은 avg_in을 구하고 높은 값의 Minth와 Maxth으로 제어
  • Out packet은 In과 Out packet의 합으로 avg_total을 구하고 낮은 값의Minth와 Maxth으로 제어
slide142

RIO (cont.)

  • Algorithm for RIO
    • For each packet arrival
      • if it is an IN packet
        • calculate the average IN queue size avg_in;
      • calculate the average queue size avg_total;
    • if it is an IN packet
      • if min_in < avg_in < max_in
        • calculate probability Pin;
        • with probability Pin, drop this packet;
      • else if max_in < avg_in
        • drop this packet.
        • ---continue…..
slide143

WRED

  • WRED (Weighted Random Early Detection)
    • --- CISCO modified RED
  • Generally drop packets selectively based on IP precedence.
  • Provides separate thresholds and weights for different
  • IP precedences
  • What
    • Multiple queue
    • Multiple threshold for packet dropping
  • Good
    • drop packet in controlled manor
    • Not CPU intensive
slide144

WRED (cont.)

Maxth

Minth

Classify

Discard test

Maxth

Minth

  • Buffer queue depth
  • IP precedence
  • RSVP session

Multiple queues of WRED