[2026-07-01] LatScope End-to-end latency decomposition across the cloud network stack

Motivation

문제 중요성

AI, 클라우드 컴퓨팅, 빅데이터의 발전으로 데이터 센터의 규모와 네트워크 스택의 복잡성이 급격히 증가

기존 연구 및 한계

기존 측정 도구들은 왕복 시간(RTT)이나 단일 계층의 지연만을 측정

• 기존 연구 1 : 다중 계층 정보를 제공하지만 커널 및 TCP/UDP 헤더의 수정을 요구
• 기존 연구 2 : eBPF 기반 시스템 관측 도구들은 일반적으로 특정 계층에 국한

LatScope

Design

• Challenge
  1. 정확한 패킷 처리 시점을 관찰하기 위해 정확한 후킹 지점을 선택하며 커널 수정 없이 기존 커널 기능을 사용해야 함
  2. 계층 간 패킷 처리 크기가 다르기 때문에 1대1 매칭을 할 수 없음
     • Offload : CPU 부하를 줄이기 위해 패킷 분할을 NIC에서 떠넘기는 과정
     • TSO (TCP Segment Offload) : 송신 측 TCP 계층에서 최대 64KB 단위로 묶어서 하위 계층으로 내려보내면 MTU 크기에 맞춰 분할
     • GRO (Generic Receive Offload) : 수신 측 NIC는 분할 된 MTU 만큼의 패킷을 병합하여 TCP 계층으로 올림
  3. 신뢰할 수 있는 전역 시간 동기화 부족
     • NTP 기반 시간 동기화 : 타임 서버에 시간 요청 패킷을 보내면 서버가 요청을 받은 시간과 응답을 보낸 시간을 기록하여 보냄. 왕복 지연 시간의 절반을 네트워크 전송 시간으로 간주하고 서버와 자신의 시계 차이인 Offset을 계산하여 조정
       • NTP : Network time Protocol. 분산된 컴퓨터 시스템들의 System Clock을 UTC와 같은 공통 시간으로 동기화하기 위한 애플리케이션 계층 프로토콜
       • 네트워크 환경에 따라서 매우 부정확할 수 있음
  4. 네트워크 모든 계층의 지연 시간을 측정하면 오버헤드가 발생할 수 있음

Overview

Challenge 1: eBPF 후킹 포인트

각 계층의 대표 함수에만 후킹 적용

• eBPF 한계 : eBPF는 사용 가능한 스택 크기나 설정할 수 있는 probing point가 제한적.
  • 커널 스택 자체가 8KB로 작음
  • Probing point가 많을 경우 Verifier을 통해 검증하는 데 너무 많은 오버헤드가 발생
  • Trade-off : 여러 함수에 eBPF 코드를 후킹하면 더 세분성 있는 데이터를 제공하지만 오버헤드 발생
• 선정 기준
  1. return value를 통해서 전송된 바이트 수를 확인
  2. 필요한 정보를 추출하기 위해 패킷 헤더가 형성된 상태를 확인

Challenge 2: 다중 계층 패킷 매칭

누적 바이트를 타임스탬프와 DB에 저장하고 각 계층 간의 패킷을 매칭하여 지연 시간을 계산

• Flow의 초기 TCP 시퀀스 번호를 저장하고 이후 시퀀스 번호와의 차이를 통해 누적 바이트를 계산
  • TCP 계층에서 out of order 패킷이 발생할 수 있어서 현재까지 관찰된 가장 큰 시퀀스 번호보다 낮은 시퀀스 번호의 패킷은 무시
  • ACK, SYN, FIN, RST와 같은 데이터가 없는 제어 패킷은 제외
• 소켓 계층에서는 OS에 의해 순서가 정리되므로 소켓을 통과한 데이터 크기로 누적 바이트 결정
• 계산 방법
  • $B_{i}^{m}$ : m 계층에서 i 번째 패킷의 시작 누적 바이트
  • $E_{i}^{m}$ : m 계층에서 i 번째 패킷의 마지막 누적 바이트

  • $E_{j}^{n}$ : n 계층 j 번째 패킷에 대하여 다음을 만족한다면 i 번째 패킷과 매칭

    \[B_{j}^{n} \le E_{i}^{m} \le E_{j}^{n}\]
  • 매칭된 패킷들의 타임스탬프를 계산하여 지연 시간을 계산
• 계층 간 지연 시간이 아닌 서버 간 네트워크 지연 시간을 계산할 때도 사용

Challenge 3: 서버 간 시간 동기화

서버 간 또는 호스트와 가상 머신 간 지연 시간 측정을 위해 시간 동기화.

동작 흐름

1. 지연 시간 측정하기 전 관리 서버가 UDP 기반 시간 동기화 패킷을 생성 후 자신의 로컬호스트로 전송
2. 관리 서버의 XDP 프로그램이 패킷을 낚아채 destination IP와 port를 목적지 서버로 변조하고 물리적 네트워크 카드로 전달
   • 각 패킷의 전송 타임스탬프를 저장
3. 각 서버의 XDP 프로그램이 패킷을 수신하여 패킷 수신 시간을 기록하고 src와 dest를 바꿔서 관리 서버로 반환
   • 커널도 CPU 스케쥴링이나 버퍼 상태에 따 소프트웨어 노이즈가 발생하여 지연 시간이 생김. 그렇기에 가장 낮은 계층인 XDP에서 처리
4. 관리 서버가 패킷을 받고 수신 시간을 기록

   • 알고리즘을 사용하여 네트워크 전송 시간을 계산하여 두 서버 간의 시간 차이를 계산.

     

   • Clock Drift로 인해 1~4단계가 64초마다 백그라운드에서 반복

     • Clock Drift : 온도나 전압 변화에 따라 시간이 변하는 현상

     

     • 100회의 동기화 작업 간 관리 서버와 대상 서버 간의 시간 차이 측정
       • 시간 차이 - 시간 차이의 최솟값.
     • 최대 0.25 msec로 동기화가 잘 되는 것을 볼 수 있음

Challenge 4: 오버헤드 제어를 위한 적응형 샘플링

패킷의 일부 또는 지정된 시간 간격으로만 데이터를 추출하여 지연 측정.

• 샘플링을 하지 않는 경우 : sender 10.2%, receiver 24.2%.
• 샘플링 적용
  • 72400B (50개의 MTU) : sender 8.6%, receiver 21.3%. 데이터 카운트 수는 85% 감소
• ELEMENT : ELEMENT가 sender에서는 더 쓰고 receiver에서는 덜 씀. 하지만 데이터 카운트 수가 너무 적음
  • LatScope가 더 많은 데이터 정보를 제공
• iperf : 네트워크에 더미 트래픽을 보내 네트워크 처리량을 측정할 때 사용하는 툴

Evaluation

서로 다른 가상화 환경에 따른 지연 시간

• 비가상화 환경 : T8(end-to-end delay) 안에서 T1(sender 쪽 소켓-TCP 계층)이 가장 큰 비중을 차지.
  • T1은 가상화 여부와 상관 없이 모든 환경에서 많이 발생.
• 가상화 환경
  • 가상화 오버헤드로 평균 지연 시간이 높음.
  • T7 (receiver 쪽 TCP-소켓 )이 증가
    • TCP 패킷 재정렬 처리하는 데 사용되는 오버헤드
• 컨테이너 환경
  • T8이 비가상화보다 높게 나타남
  • T2(sender의 TCP-IP 계층 간 지연) 및 T4(네트워크 지연)의 변동성이 큼

서로 다른 네트워크 환경에서의 지연 시간

• LTE
  • LAN과 마찬가지로 T1이 대부분을 차지. 평균값이 높고 변동성이 느림
    • LTE의 낮은 물리적 대역폭과 높은 RTT 인해 발생하는 bufferbloat
  • T4도 변동성이 큼
• WiFi
  • T8은 LTE보다 낮지만 LAN보다는 높음
  • T4가 더 불안정

경합 시나리오

• Wifi 내에서 20개의 Flow 실행
• T1 뿐만 아니라 T2와 T7 (receiver의 TCP-socket 구간) 증가
• T8의 변동성 증가
  • 플로우 당 대역폭 감소 및 플로우 간 간섭으로 인함

실제 애플리케이션

• iperf가 아닌 FTP에서 실험.
  • 하지만 FTP 역시 iperf와 유사하게 작동하여 비슷하지만 지연 시간과 변동성이 약간 더 큼
• LTE에서는 T1과 T8에서 변동성이 큼
  • DASH 애플리케이션은 주기적으로 다운로드를 받기 때

Use Case

1. QoS 기반 지연 제어 알고리즘 개발

   • 우선 순위에 따른 지연 시간 차이: 우선 순위를 조절하여 지연을 통제함을 보임

     

   • TCP 버퍼에 따른 지연 시간 차이: 버퍼 크기를 조절하며 지연을 통제함을 보임

     

2. Gray failure 탐지
   • Gray failure : 시스템이 죽은 것은 아니지만 미묘하게 성능이 저하된 상태
   • 미묘한 비정상 징후를 보이기 때문에 지연 시간 패턴에서 ML을 통해 탐지
3. 클라우드 설정 선택
   • 네이버 클라우드의 가상 머신 3종의 계층 별 지연 시간

   

Discussion

패킷 필터링

패킷 필터링이 없이 모든 패킷을 다 매칭하면 $O(n^2)$이지만 낮은 시퀀스 번호를 무시하면 $O(n)$

고속 네트워크 지원

측정 데이터를 중앙 DB에 저장하는 구조라서, 100 Gbps 같은 고속 네트워크에서는 오버헤드가 커짐

최신 커널 버전 지원

커널 버전이 바뀌면 함수명이나 인자가 달라질 수 있기 때문에 설정 파일 업데이트

Contribution

• multi-layer latency analyzer로서, 계층 간 패킷을 매칭해서 정밀한 지연을 계산
• XDP로 서버 간 시간을 동기화해서 정확한 inter-server delay 제공
• selective data extraction(adaptive sampling)으로 측정 오버헤드 통제

생각

• 측정 데이터가 수집될때마다 관리 서버 시간으로 보정된다고 했는 데 오버헤드가 있지 않은지
• 왜 receiver가 더 CPU 소모가 많은 거지?