QoS Congestion Management
Congestion and Queuing
- Congestion은 네트워크 어느 지점에서든 발생 가능
- Queuing은 congestion을 관리함
- 대역폭과 delay 이점을 제공하기 위함
Congestion and Queuing: Speed Mismatch
- 속도 불일치는 Congestion의 가장 흔한 사유
- LAN에서 WAN으로 이동할 때 지속될 수 있음
- 일반적으로 LAN에서 LAN으로 이동할 때 일시적으로 발생
Queuing Algorithms
- FIFO
- PQ
- Round Robin
- WRR
- DRR
- CQ
- WFQ
- CBWFQ
- LLQ
First In, First Out (FIFO)
Priority Queuing (PQ)
Round Robin
Weighted Round Robin (WRR)
Modified Deficit Round Robin
Queuing Components
- 하드웨어 Queuing은 항상 FIFO Queuing을 사용
- 소프트웨어 Queuing은 플랫폼과 Cisco IOS 소프트웨어 버전에 따라 선택되고 설정될 수 있음
The Software Queue
- 일반적으로, 완전 하드웨어 Queue는 interface congestion을 나타내고 소프트웨어 Queuing이 이를 관리하는 데에 사용됨
- 패킷이 포워딩 되었을 때, 하드웨어 Queue에 공간이 있다면 라우터는 소프트웨어 Queue를 우회할 것임
FIFO Queuing
- 단순하고 빠름, 모든 플랫폼에서 지원됨, 모든 스위칭 경로에서 지원됨
- jitter를 발생시킴, 리소스 부족 현상 발생시킴
Weighted Fair Queuing
- Queuing 알고리즘은 모든 flow 사이에 공정한 대역폭을 공유해야 함
- queue의 앞부분에서 순서를 결정함으로 상호작용하는 flow에 대해 응답 시간 감소
- 인터페이스를 단순화하는 것으로 high-volume conversation 방지
- WFQ 실행 중, 메시지는 conversation(flows)로 분류되어야 함
WFQ 구조
WFQ Implementations
- Implementation parameters
- Queueing platform: central CPU 또는 VIP
- Classification mechanism
- Weighted fairness
- 각 queue마다 modified tail drop
WFQ Classification
- 같은 flow의 패킷이 같은 큐로 들어감
- ToS 영역은 변화하는 parameter
- 같은 flow의 패킷이 다른 Queue가 됨
- 각 flow queue의 고정된 번호가 설정됨
WFQ Insertion and Drop Policy
- WFQ는 dropping의 두 가지 모드가 있음
- Congestion discard threshold에 도달했을 때 사전에 Drop
- hold-queue limit에 도달했을 때 강제 Drop
- WFQ는 가장 공격적인 흐름에 대해 Drop
- Drop 메커니즘 예외사항
- empty sub-queue로 정의된 패킷은 절대로 drop되지 않음
- 패킷 우선순위는 dropping scheme에 영향을 주지 않음
Finish Time Calculation
WFQ Dropping Operations
- HQO는 WFQ 시스템이 hold 할 수 있는 패킷의 가장 큰 숫자
- CDT는 가장 공격적인 흐름의 패킷을 drop하기 시작했을 대의 threshold
- N은 N번째 패킷이 도착했을 때, WFQ 시스템에서 패킷의 번호를 의미
Weight in WFQ Scheduling
WFQ Case Study Interface Congestion
-
HQO(hold-queue out limit)는 WFQ 시스템이 지닐 수 있는 최대 패킷의 수를 의미
-
HQO = 10
CBWFQ(Class-Based Weighted Fair Queuing) & LLQ(Low-Latency Queuing)
CBWFQ 구조
CBWFQ 구조: Scheduling
- CBWFQ는 트래픽 클래스에 할당된 weights에 따라 대역폭을 설정
- weight는 아래의 항목에 따라 결정
- 대역폭(kb/s)
- 대역폭 percentage(사용 가능한 인터페이스 대역폭의 비율)
- 사용 가능한 나머지 대역폭의 비율
- 하나의 서비스 정책은 여러 혼합된 weight의 타입을 가질 수 없음
CBWFQ 구조: Available Bandwidth
LLQ 구조
LLQ 이점
- 높은 우선순위 클래스가 보장됨
- 패킷의 Low-latency propagation
- 대역폭
- 모든 media 타입에 대해 일관된 구성 및 동작
LLQ & Cisco TelePresence
- Queuing은 경로의 모든 노드에서 가능해야 함
- 제한 우선순위 Queue에서 Cisco TelePresence를 제공하는 것을 추천
- TelePresence에 대한 서비스 레벨 요구치는 아래와 같음
- Latency: 150ms
- Jitter: 10ms
- Packet loss: 0.05%
Congestion Avoidance
Behavior of a TCP Sender
- 송신자 N bytes 전송
- start credit(window size) 작음
- 네트워크 큐의 과포화상태를 피하기 위해
- credit이 기하급수적으로 증가
- 네트워크 기능 측정을 위해
Behavior of a TCP Receiver
- 수신자는 다음 메시지 수신할 경우 ACK를 예약
- TCP는 마지막으로 수신한 세그먼트가 아닌 다음에 받을 것으로 판단되는 세그먼트를 확인
- N+1이 막혔을 경우, 바로 N+2 세그먼트를 보는 것이 아닌 N+1을 계속 확인
TCP Slow Start
- ACK가 뭔가 확인했을 때
- Credit을 업데이트하고 전송
- 반대 상황, 손실된 패킷 확인
- 곧바로 첫 확인 불가 메시지 전송
- 현재 credit을 반으로 줄임(slows down)
- 네트워크 throughput을 측정하기 위해 천천히 증가
Multi Drops in TCP
- 같은 세션에 다수의 drop이 발생했을 경우
- 현재의 TCP는 timeout 대기
- 선택적 확인이 해결 방법이 될 수 있음
- 새로운 "빠른 재전송"이 회복을 위한 round-trip 시간을 보낼 수 있음
Managing Interface Congestion with Tail Drop
- 라우터 인터페이스는 output queue가 다 찼을 때 congestion을 겪음
- 추가로 들어오는 패킷은 tail-drop됨
- drop된 패킷은 어플리케이션 성능 저하를 일으킬 수 있음
- tail drop은 큰 약점을 지님
Tail Drop 한계
- TCP synchronization
- TCP stavation
- No Differentiated drop
TCP Synchronization
- 다수의 TCP 세션이 다른 시간으로 시작됨
- TCP window size 증가
- Tail Drop은 동시에 많은 세션의 많은 패킷 drop을 일으킬 수 있음
- TCP 세션이 동시에 재시작(synchronized)
Random Early Detection(RED)
- congestion이 예방됐을 경우, Tail drop을 피할 수 있음
- RED는 Queue가 다 차기 전에 패킷을 랜덤하게 Drop
- RED는 평균 Queue의 크기가 증가할수록 Drop Rate도 증가
RED Prefiles
Weighted Random Early Detection(WRED)
- WRED는 다수의 각기 다른 RED profile을 사용
- 각 Profile은 아래의 항목들로 정의되어 있음
- Minimum Threshold
- Maximum Threshold
- Maximum drop probability
- WRED profile selection은 다음 항목을 기초로 함
- IP precedence(8 profiles)
- DSCP(64 profiles)
- WRED는 중요 패킷들에 비해 덜 중요한 패킷을 공격적으로 Drop
- WRED는 Interface, VC, class 수준에서 적용 가능
WRED Building Blocks
Changing WRED Sensitivity to Bursts
Traffic Policing & Shaping
Traffic Policing and Shaping Overview
Single Token Bucket
- 만약 충분한 토큰이 사용 가능하다면
- 패킷 크기와 동일한 토큰이 bucket에서 사라짐
- 패킷은 전송됨
- 풍분한 토큰이 없다면
- 패킷 Drop(또는 Mark)
