Home PBE-CC: Congestion Control via Endpoint-Centric, Physical-Layer Bandwidth Measurement
Post
Cancel

PBE-CC: Congestion Control via Endpoint-Centric, Physical-Layer Bandwidth Measurement

By Joe2357
Posted 2020-11-26 Updated 2024-04-23 58 min read

2021 / 1 / 20 iMES 세미나

Abstract

  • cellular network는 복잡해지고 과밀되어짐
    • delay, jitter 등의 문제 발생
  • PBE-CC : sender가 정확하고 급격하게 반응할 수 있도록 하는 최신 5G radio 혁신 기반 congestion control 알고리즘
    • 5G radio 혁신 : wireless capacity를 급격히 늘리거나 줄일 수 있는 bandwidth
    • 구현 언어 : C

Introduction

  • downlink end-to-end data flow : cellular last hop에서 종료
    • 대부분의 delay, delay variation, packet loss, bandwidth 제한 등 발생
  • end-to-end 혼잡도를 측정하기 위해서는 endpoint가 제일 좋음
    • mobile endpoint가 무선 last hop의 혼잡도를 측정
    • 세분화된 측정값을 API를 통해 전송계층과 app에게 공급해야함
  • congestion control 알고리즘이 wireless 상황에서 겪는 3가지 문제점
    • wireless = 공유 매체
      • 같은 cell tower에 있는 다른 user들이 capacity의 변화를 느낄 수 있음
      • 오늘날 ACK 기반 프로토콜에서는, 재전송 승인 흐름에 반영되는데 시간이 걸림
    • 높은 throughput, 낮은 queueing delay를 위해 누구도 관측하기 힘든 wireless cell link capacity의 급격한 변화에 신속대응해야함
      • capacity 변화 원인 : carrier aggregation
        • cellular network가 2개 이상의 base station의 bandwidth를 집계하여 총 bandwidth로 사용하는 기술
        • base station을 추가하거나 제거 -> user가 사용 가능한 wireless capacity가 갑자기 변경
    • wireless channel 품질 = dynamic
      • 원인 : user mobility, multipath propagation, 인접 cell tower interference 등
      • 특정 user의 cellular link가 지원하는 wireless data rate를 wireless channel coherence time으로 알려진 시간 척도에 걸쳐 변경
        • 차량 속도 정도면 ms 단위
      • base station간 handover : state를 migrate해줘야함
        • 설계에는 반영되지 않았음
    • 앞서 말한 요인들에 의해 악화되어감
  • carrier aggregation : end-to-end connection은 aggregated cell의 dynamics에 의해 변동 발생
    • 통계적 multiplexing에 의한, capacity를 평활화할 수 있는 것보다 적음
  • base station, mobile endpoint 모두 변동을 관측할 수 있음
    • 현재 cellular physical-layer 설계 : 자신의 channel에 할당된 message만 해석
      • 다른 user의 channel capacity를 추적하여 capacity를 식별할 수 없음
  • PBE-CC : Congestion Control based of Physical-layer Bandwidth measurements taken at the mobile Endpoint
    • 2개의 module로 이루어져 있는 cross-layer 설계
      • TCP BBR 기반 end-to-end congestion control 알고리즘
        • 가능한 경우 정확한 congestion control을 위해 sender를 수정
        • TCP BBR : 구글에서 만든 congestion control 알고리즘
          • CUBIC의 대용
          • bottleneck link의 buffer를 가득 채우지 않으며 동작
          • packet loss을 줄이고 transport delay를 최소화
          • CUBIC : 손실 기반 방식 알고리즘 ( packet loss를 관측하고 송신 억제 )
      • mobile device를 위한 wireless physical-layer capacity 측정 module
        • end-to-end congestion control 활용
    • 주요 혁신 : wireless cellular link의 매우 정확한 capacity 측정
      • link : 변화를 ms 단위로 세분화하여 추적
      • send rate를 available wireless capacity ( bottleneck ) 와 일치시켜 sender의 send rate를 더 정밀하게 제어할 수 있음
      • wireless capacity의 변화에 대해 PBE-CC가 신속하게 대응
        • capacity가 증가한 경우
          • 새로 생긴 idle capacity를 감지
          • sender가 사용할 수 있는 rate를 증가시킬 수 있음
        • capacity가 감소한 경우
          • send rate를 억제
          • queueing delay를 피할 수 있음 // drill-down 실험
  • wireless cellular link가 대체로 end-to-end link의 bottleneck link
    • PBE-CC : wireless-aware 정밀 congestion control 활용
      • sender의 pace를 정확하게 제어 + wireless link를 공유하는 user 수를 고려
      • -> 동일한 초기 가정을 수행
      • => 각 PBE-CC sender가 user간에 wireless capacity를 전반적으로 공정하게 분배하는 load 제공
      • 추가적인 개선을 통해, sender : connection 시작 시 이 target에 부드럽게 접근
        • 다른 user들이 이에 대응하고 조정할 시간을 줌
      • 예측하지 못한 one-way packet delay 증가를 감지하면, sender가 받은 ACK packet의 속도를 기반으로 한, bottleneck을 조사하는 BBR과 같은 매커니즘을 대신 사용
  • C++로 구현
    • mobile wireless frontend : physical-layer capacity 측정을 위해 주파수 대역을 decode해야함
      • 펌웨어가 제공하지 않음
    • USRP를 이용하여 누락된 펌웨어 기능을 구현
  • Pantheon이라는 training guide를 이용하여 evaluation
    • 선두적인 알고리즘 : BBR, CUBIC
    • 최근에 고안된 알고리즘 : Copa, PCC, PCC-Vivace
  • 실험 평가 : delay와 throughput 측정
    • 고정된 user device를 이용
    • 실험 조건
      • 실내 / 실외
      • busy / quiet
    • 추가 실험 조건
      • 같은 user device 조건 // 고정된 user device
      • wireless network capacity에 대한 경쟁
        • 통제된 경쟁자
        • 통제되지 않은 background traffic 경쟁자
      • 100 ms 단위로 측정된 모든 throughput과 delay order statistics를 개별적으로 기록
  • 결과 ( 15개의 idle cellular link, 25개의 busy link )
    • BBR : 더 좋은 throughput / delay 낮춤
    • Verus : 보다 상당한 이득
    • Copa : delay에서는 약간의 손해 / throughput 11배
End-to-End congestion control
  • loss 기반 알고리즘 : 높은 throughput / 과도한 delay
  • delay 기반 알고리즘 : ACK delay, ACK compression, network jitter 발생
    • network capacity 활용도 감소
  • 위의 방법들은 모두 concurrent loss 기반 알고리즘보다 낮은 capacity 활용률
  • 다른 제안 : 학습된 알고리즘을 사용
    • 특정 목적 함수 최적화
    • 인간이 만든 규칙보다 더 나은 congestion control 작업 생성
  • 온라인 학습 : network 활용도가 현저히 떨어지는 해답으로 수렴
  • BBR : Kleinrock의 최적 운영 지점에 대한 수렴이 목표
    • bottleneck bandwidth 및 $RT_{prop}$의 추정치를 기반으로 throughput 최대화, delay 최소화
    • 테스트한 알고리즘들 중 최고의 성능이었으나, network를 충분히 활용하지 못함
      • 과도한 지연 초래 ( capacity 추정치가 조잡함 )
End-to-End congestion control for cellular networks
  • cellular link를 블랙박스로 취급하고, link capacity를 추론하기 위해 throughput, packet delay, loss 통계를 사용
    • Raven : multipath TCP를 사용
      • multipath를 통한 중복 data 전송
      • interactive video latency 단축
    • PROTEUS : 현재 throughput, loss, one-way delay 수집
      • 회귀 트리 사용
      • 미래 network 성능 예측 목적
    • PropRate : BBR의 주기적인 bandwidth probing을 연속 probing으로 대체
      • packet size, packet send/receive time을 사용하여, 예상 receive rate를 중심으로 send rate를 진동시킴 ( 왔다갔다 )
    • Sprout : packet 도착 시간을 활용
      • network 경로의 불확실한 dynamics 추론
      • link capacity 예측
    • ExLL : send rate 조절
      • packet 도착 패턴 + cellular bandwidth 사용 간의 간계 modeling
    • Verus : cellular network dynamics 추론 대신, target send window size와 인지된 endpoint간 delay 사이의 관계를 포착하는 delay profile 학습 목적
    • end-to-end 통계에 의존할 때, 위의 알고리즘은 capacity 추정 부정확성에 시달림
      • network dynamics에 민감
  • PBE-CC : wireless channel을 직접 측정
    • 보다 세밀한 capacity 추정
    • 탁월한 성능 제공
Cellular-aware congestion control proposals
  • ABC, IETF MTG 표준 초안 : sender에게 best rate를 명확히 전달하기 위해 mobile base station의 수정을 제안
    • 고성능에 중요한 capacity monitor 설계에 대한 설명은 없음
  • CQIC : 3G capacity 추정치를 추출하여 cross-layer 설계를 시작
    • 여전히 세분성이 부족
  • piStream, CLAW : 신호 강도 측정에 사용된 resource block을 예측하는 model 만듬
    • CLAW : 웹 검색 작업 속도 높임
    • piStream : 비디오 작업 속도 높임
    • 자체 측정에 따르면 신호 강도 예측력이 상당히 제한되어있음
  • PBE-CC : control 채널 metadata를 직접 decode하여 추정치가 아닌 정확한 bandwidth 활용도 제공
Cellular PHY-layer monitoring tools
  • QXDM, MobileInsight : 단일 mobile user를 위한 control 메세지를 추출
    • cell tower capacity 점유에 대한 순 정보를 제공할 수는 없음
    • PBE-CC는 제공할 수 있다
  • BurstTracker : end-to-end 연결의 bottleneck 지점을 찾음
  • LTEye, OWL : control message decode
    • PBE-CC와는 달리 carrier aggregation 및 고급 MIMO 표준에서 작동하지 않음
  • 위의 도구들은 congestion control 알고리즘 설계가 부족함

LTE/5G New radio primer

  • Frequency division duplexing ( FDD ) : 주파수 분할 이중화
    • cellular 사업자가 가장 많이 사용하는 mode
  • LTE : OFDMA 채택
    • frequency bandwidth를 180KHz로, 시간을 0.5ms slot으로 나눔
    • 가장 작은 1칸 = physical resource block (PRB)
      • user에게 할당할 수 있는 가장 작은 block
    • 2개의 slot을 group화하여 1ms subframe 제작
      • subframe 내에서 두 slot의 PRB 할당은 동일
    • transport block (TB) : 하나의 subframe을 통해 전송되는 data
      • 할당된 PRB만큼 크기, user의 wireless physical data rate에 의해 달라짐
    • base station : wireless control channel에서 전송되는 control message를 통해 mobile user에게 알림
      • bandwidth 할당 ( 할당된 PRB 양과 위치 )
      • wireless bit rate
        • 변조 및 코딩 방식 (MCS)
        • 공간 stream 수
    • mobile user : TB를 decode하기 전에 subframe의 control message를 먼저 decode
Carrier aggregation
  • base station : component carrier 또는 primary cell을 통해 mobile user에게 data 전송
    • 전달해야하는 data의 양이 많으면, capacity를 추가로 확보하기 위해 secondary cell 활성화
  • cellular network : 각 user에 대한 aggregated cell들의 목록을 유지관리
    • 필요한 경우 순차적으로 활성화
    • 불필요해지는 경우 비활성화
  • 예시
    • receiver인 mobile user에게 primary cell의 최대 capacity을 초과하는 data 전송
      • 40Mbits 고정 제공 load로 2초동안
      • 모든 bandwidth가 이곳에 할당되더라도 packet buffering 발생
    • cellular network : 높은 data rate의 user를 감지
      • data 전송을 도울 secondary cell 활성화
      • secondary cell이 활성화되면 합계 capacity가 40Mbit보다 커짐
        • 쌓인 queue가 점차 비워질 것
    • sender가 send rate를 primary cell의 capacity보다 낮춤 (6Mbit/s)
      • secondary cell 비활성화
Cellular retransmission and reordering
  • 잘못된 TB 전송 : 8ms 이후에 재전송 ( 8개의 subframe 이후 )
    • block 순서를 맞추기 위해, 없어진 순서 이후의 도착한 block들은 buffering
    • 재전송 성공 => 버퍼링된 모든 block과 재전송된 block을 상위계층에 올림
      • TB에서 packet을 추출
  • 재전송 : 오류가 있는 TB 내의 전송계층 packet에 8ms delay 도입
    • receiver 측의 buffering, reordering 작업 : 8ms보다는 감소하는 delay 도입 (7ms ~ 0ms)
  • 재전송마저 실패하는 경우 : 최대 3번까지 재전송을 반복
    • 지연 패널티 : 8ms * 반복 횟수 (최대 3번)

Design

  • PBE-CC : cellular network를 통과하여 mobile endpoint에서 종료되는 flow를 위한 rate 기반 end-to-end congestion control 알고리즘
    • mobile user : base station의 available wireless capacity에 대한 자세한 정보를 포함하는 cellular physical control channel을 decode
    • 그 양을 ms 단위로 정확히 추정 가능
  • sender : mobile user가 명시적으로 feedback하는 bottleneck capacity 추정값 또는 receiver로부터의 ACK 존재 여부를 기준으로 send rate 제어
  • PBE-CC : bottleneck 위치가 wireless hop인 경우 사용 가능
    • congestion을 일으키지 않고 available capacity를 확보하여 send rate 높일 수 있음
    • 다른 mobile user가 capacity를 줄이면 send rate 또한 줄임
  • end-to-end connection : 2가지 경우의 network state에 직면 ( internet bottleneck link와 cellular link의 상대적 capacity에 따라서 )
    • 대부분의 경우 : wireless cellular link가 bottleneck인 경우 = wireless bottleneck 현상
      • PBE-CC mobile user : cellular physical control channel을 decode -> 전체 connection의 bottleneck을 ms 단위로 추정하고 추적 가능
      • sender : user가 feedback하는 bottleneck capacity와 send rate를 일치시킴 -> 정확하게 capacity 활용, buffering 최소화
    • 이외의 경우 : 인터넷 bottleneck이 wireless cellular link capacity보다 작은 경우 = internet bottleneck 현상
      • PBE-CC : cellular 맞춤형 BBR같은 congestion control 알고리즘 사용
        • bottleneck의 capacity를 공정하게 share하기 위해, internet bottleneck을 다른 flow들과 공정하게 경쟁
    • PBE-CC : 2가지 상태에서 발생할 수 있는 변화를 추적
      • 그에 따라 sender의 action을 제어
  • Kleinrock : bandwidth 최대화, delay 최소화하는 operating point가 개별 connection과 network 전체에 최적임을 입증
    • operating point : pipe를 가득 채워야 한다는 것이 특징
    • PBE-CC의 목적 == BBR의 목적 // pipe 채우기, network 내부 buffering 최소화
  • PBE-CC : BDP로 돌아다니는 data의 양을 limit
    • BDP : bandwidth delay product ( 대역폭 지연 제품 ) - 아래의 것들에 의해 계산됨
      • $RT_{prop}$ : 추정 round-trip propagation
      • congestion window bottleneck capacity
    • sender : user의 feedback이 지연되더라도 과도한 양의 packet을 전송하지 않음 -> 네트워크의 queueing을 최소화 // low latency

Connection start: Linear rate increase

  • connection 시작 - sender : linear rate increase 실행 ( bottleneck에 공정하게 접근하기 위함 )

    • control channel decode : cell bandwidth를 공유하는 다른 user들의 수를 알 수 있음

    • 공정하게 나누는 것이 기본 idea이므로, 1명이 사용 가능한 capacity = $P_{exp}$

      \[P_{exp} = P_{cell}/N\] \[\begin{aligned} &P_{exp} =\text{예상 fair-share bandwidth}\\ &P_{cell} =\text{cell의 총 PRB}\\ &N =\text{user 수} \end{aligned}\]

    • 예상 fair-shared send rate = $C_f$

      \[C_f=R_w\times P_{exp}\] \[\begin{aligned} &C_f=\text{예상 fair-share send rate}\\ &R_w=\text{wireless physical data rate}\cdots\text{(PRB당 비트단위 포함)}\\ \end{aligned}\]

  • 3 RTT까지 send rate를 $C_f$까지 linear하게 증가시킴

    • mobile user : ms단위마다 $C_f$를 update, ACK마다 server에게 rate를 전송

  • 이점

    • bursty traffic 방지
    • cell tower, tower를 공유하는 다른 user들에게 증가하는 traffic에 반응할 시간을 남겨둠
      • cell tower : mobile user의 send rate가 증가하면, 그에 비례하여 bandwidth를 추가 할당
        • 이외의 user들은 bandwidth가 감소
      • user : bandwidth가 감소하면 즉시 감지하고 그들의 sender에게 rate를 낮출 것을 요구하는 신호 보냄
    • 모든 PBE-CC user는 동등하게 공유되는 bandwidth와 균형을 이루는 경향

  • fair-share approaching state : 2개 이상의 component carrier가 활성화되면, 각 aggregated cell에 대해 개별적으로 target send rate를 계산

    • 이후 그것을 $C_f$로 합산

  • congestion avoidance 단계에서 더 많은 carrier가 활성화된 경우 : PBE-CC는 fair-share approaching process 재실행

  • user의 fair-shared send rate가 $C_f$에 도달하면, linear rate increase를 그만두고, congestion avoidance로 진입

  • bottleneck이 internet 내부에 있는 경우 : $C_f$만큼의 rate를 달성할 수 없음

    • cell tower에서 달성한 throughput은 $C_f$보다 적음
    • sender의 offered load가 증가 -> end-to-end packet delay 증가

  • mobile user: 아래의 상황을 감지하여 linear rate increase 종료, cellular 맞춤형 BBR로 전환 // internet의 congestion을 처리하기 위함

    • $RT_{prop}$에 대해 receive rate가 증가하지 않는 것
    • one-way packet delay가 offered load가 증가함에 따라 단조롭게 증가하는 것

Steady state: Congestion Avoidance

  • wireless link가 bottleneck인 경우 : sender가 추정 wireless capacity까지 rate 증가시킴 (A)
  • connection startup과 유사하게, wireless bottleneck에서 internet bottleneck으로의 전환 가능성을 식별 (B)
    • 만약 일어난다면, cellular 맞춤형 BBR (C)로 전환하여 bottleneck에서의 flow와 공정한 경쟁을 벌임

A: Wireless Bottleneck state

  • PBE-CC mobile user : available cellular wireless capacity인 $C_p$를 추정

    \[C_p=\sum\limits_{i=1}^{N_{cell}}(R_{w,i}\times (P_{a,i}+\frac 1 N_i P_{idle,i}))\] \[\begin{aligned} &C_p=\text{available cellular wireless capacity}\\ &N_{cell}=\text{user에게 활성화된 cell의 개수}\\ &R_{w,i}=\text{user에게 i번째 cell이 제공하는 wireless data rate}\\ &P_{a,i}=\text{user에게 i번째 cell에서 할당된 PRB의 개수}\\ &N_i=\text{i번째 cell에 있는 user의 수}\\ &P_{idle,i}=\text{i번째 cell에 있는 idle PRB의 개수} \end{aligned}\] \[P_{idle,i}=P_{cell,i}-\sum\limits_{j=1}^{Ni}P^j_{a,i}\] \[\begin{aligned} &P_{idle,i}=\text{i번째 cell에 있는 idle PRB의 개수}\\ &P_{cell,i}=\text{i번째 cell에 있는 PRB의 개수}\\ &N_i=\text{i번째 cell에 있는 user의 수}\\ &P^j_{a,i}=\text{i번째 cell의 user j에게 할당된 PRB의 개수} \end{aligned}\]

  • 추정치를 원활하게 하기 위하여, 계산한 $R_{w,i}, P_{idle,i}, P_{a,i}$를 평균화

    • 가장 최근의 $RT_{prop}$ subframe을 이용하여 계산한 값들의 평균
    • 만약 connection RTT가 40ms라면 40개의 subframe을 이용

  • 추정 wireless capacity $C_p$를 이해하기 위해 $C_p$ 식의 구성요소를 고려해야함

    • $R_w$ = mobile user가 다양한 channel 품질에 의한 capacity 변화를 추적할 수 있도록 함
    • mobile user : 자신에게 할당된 PRB의 수 $P_a$를 추적하여 새로운 user의 출현에 반응
      • 새로운 user가 traffic을 수신하면 기존 user는 $P_a$를 줄임
      • 할당된 PRB 수가 적어짐을 감지하면, sender는 추정된 감소 capacity에 맞춰 send rate를 줄임

  • idle PRB인 $P_{idle}$이 무선 bottleneck connection에 쓰이고 있는 cell에 나타난다면, 모든 PBE-CC user는 control message를 decode하여 이를 감지

    • sender에게 idle PRB를 fair-share한 부분을 갖기 위해 send rate를 올릴 것을 알림 ( $P_{idle} / N$ 만큼 )

    • idle PRB가 등장하는 사례

      1. 한 user가 flow를 끝낸 경우

      2. 여러가지 요인에 의해 user flow의 data rate가 감소한 경우

        1. internet의 congestion
        2. app 자체의 congestion
        3. cellular network에 의한, 한 cell에서 다른 aggregated cell로의 traffic 이동

    • idle PRB가 남았다고 해서 항상 전부를 나눠갖는 것이 아님

      • 1ms마다 자신에게 추가 할당할 수 있는 $P_{idle} / N$ 만큼의 fair-share를 가져감
      • app 자체 congestion에 의해 data rate가 줄어든 user는 fair-share를 가지지 않음 -> 그 칸은 계속 idle인 상태 유지
        • 계속 idle인 PRB는 계속해서 detect되고, fair-share됨

    • network는 flow가 없는 user를 제외하고 모든 user가 idle bandwidth를 모두 잡은 상태로 수렴

Cross-layer bit rate translation

  • $C_f, C_p$ : MAC계층 재전송 + protocol header overhead에 의한 전송계층 data rate와는 다른 wireless physical-layer capacity

    • PBE-CC : 예상 physical-layer capacity $C_p$를 전송계층 goodput인 $C_t$로 변환, server에게 send rate를 설정할 것을 feedback

  • cell : new-data-indicator 사용 -> 재전송된 TB를 나타냄

    • 재전송 overhead, protocol overhead를 별도로 측정 가능

  • TB 오류 확률이 재전송 overhead를 결정

    \[\text{TB error rate}=1-(1-p)^L\] \[\begin{aligned} &p=\text{TB 안의 각 bit에 대한 bit error rate}\cdots\text{(확률은 iid라고 가정)}\\ &L=\text{TB의 크기} \end{aligned}\]

  • PBE-CC : $C_p$와 $C_t$사이의 관계를 정리

    \[C_p=C_t+C_t\times(1-(1-p)^L)+γ\times C_p\] \[\begin{aligned} &C_p=\text{추정 physical-layer capacity}\\ &C_t=\text{전송계층 goodput}\\ &p=\text{TB 안의 각 bit에 대한 bit error rate}\\ &L=\text{TB의 크기 (1개의 subframe 내의 bit 수)}\\ &γ=\text{protocol overhead (6.8%)} \end{aligned}\]

  • SINR을 이용하여 $p$를 추정

    • SINR (signal to interference noise ratio)

      \[SINR(x)=\frac P {I+N}\] \[\begin{aligned} &P=\text{interest 신호 세기}\\ &I=\text{간섭 신호 세기}\\ &N=\text{랜덤 noise term} \end{aligned}\]

    • 이후 $C_p$를 제공하여 방정식을 풀고 $C_t$를 추정

    • 계산을 빠르게 하기 위해, look-up table을 만들어 변화를 저장

  • 한 PBE-CC user가 fair-share capacity를 가져가면..

    \[L=C_t\times 10^{-3}\] \[\begin{aligned} &L=\text{TB의 크기 (1 subframe 내의 bit수 ( bit/} 10^{-3} \text{ms ))} \\ &C_t=\text{전송계층 goodput} \end{aligned}\]
Handling control traffic
  • PBE-CC : 모든 active user에게 fair-share 무선 bandwidth 제공 목적
    • 실험 결과
      • 상당수의 user들이 data를 위해 활성화되어있는 것이 아님
      • base station, mobile에 의해 공유된 network parameter를 update하는 것을 목적으로 활성화되어있었음
        • 다양한 시간대의 period
        • aggregated cell의 list
        • 많은 pricing, 보안 관련 parameter
      • 이러한 user가 있어서, 각 시점에서 감지된 active user는 커질 수 있음
        • 측정치 : 40ms 간격동안 평균 15.8명, 최대 28명의 active user
      • 위의 user들은 fair-share capacity 계산에서 제외
        • 이 user들을 위한 소량의 bandwidth를 cell tower에서 할당
        • 여기서 할당한 bandwidth의 감소 $P_a$를 추적
        • 추적된 값만큼 send rate 줄임
  • control traffic : 적은 수의 PRB를 차지하고, 적은 시간 동안만 활성화됨
    • 68.2% user가 4개의 PRB 점유, 1개의 subframe에서 활성화
    • 그중에서 95%가 base station으로부터 control traffic 수신중
  • PBE-CC monitor : 활성화 시간 duration (subframe), 할당된 bandwidth (PRB)의 임계값을 기반으로 update에만 active된 user들을 필터링
    • 이후 감지된 user들의 수는 상당히 감소
      • 40ms 간격 내에서 15 -> 1.3명으로 현저히 감소
    • bandwidth를 위해 동시에 경쟁하는 user의 수는 최대 7명으로 관찰
  • $N$ : 방정식 (2), (3) 에서 threshold를 적용한 후의 active user 수로 설정
    • 그러나 방정식 (4)에서 idle PRB를 계산하기 위해서는 모든 user로써 계산

B: Switching between Bottleneck states

  • sender offered load가 internet bottleneck capacity를 초과하는 경우 : packet queuing 발생

    • PBE-CC : wireless bottleneck state -> internet bottleneck state로 전환

    • 즉각적인 one-way packet delay가 threshold를 초과하는 경우 switch 실행

      • 임계값 : server <-> client 간의 one-way propagation delay으로 설정해야함

        \[D_{th}=D_{prop}\] \[\begin{aligned} &D_{th}=\text{threshold delay}\\ &D_{prop}=\text{one-way propagation delay} \end{aligned}\]

      • PBE-CC : $D_{prop}$을 10초 window에서의 최소 delay로 추정

        • BBR의 round-trip propagation delay 추정 method를 불러옴
        • 추정 패킷 delay가 10초동안 일정하게 유지된다면, BBR처럼 buffer를 뺌
          • delay를 실제 $D_{prop}$값으로써 update

  • 이론적인 threshold는 실제로는 제대로 작동하지 않음

    • 재정렬 작업에 의함
    • sender offered load가 높은 경우
      • mobile user가 재정렬 buffer에 자주 buffering
      • packet delay 크게 변동
    • offered load가 높아지면 TB error rate 또한 증가
    • mobile user : 재정렬 buffer에 더 많은 packet 저장
      • 수신된 packet 수의 증가, 8ms 재전송 delay 도입
    • 재전송 X, buffering X인 packet은 항상 있음
      • 최소 delay : one-way propagation delay를 캡처

  • 분석에 의해 switching 임계점을 계산

    \[D_{th}=D_{prop}+3\times8+3\] \[\begin{aligned} &D_{th}=\text{switching threshold}\\ &D_{prop}=\text{minimum delay}\\ &3\times8=\text{TB는 최대 3번 재전송 가능}\\ &3=\text{network jitter (실험 중에 94.1%의 확률로 <= 3)} \end{aligned}\]

  • PBE-CC : delay 임계값을 초과하는 delay가 있는 연속 packet 수에 대한 임계값을 추가

    • jitter 완화, 견고성 개선 목적

    • 현재 data rate에 따라 6개의 subframe에 걸쳐 전송할 수 있는 패킷 수 $N_{pkt}$를 정의

      \[N_{pkt}=6\times C_t/MSS\] \[\begin{aligned} &N_{pkt}=\text{6개의 subframe으로 전달할 수 있는 packet의 수}\\ &C_t=\text{현재 전송계층 capacity}\\ &MSS=\text{최대 segment 크기} \end{aligned}\]

  • PBE-CC : server와 mobile user간의 동기화가 필요하지 않음

    • relative delay (현재 propagation delay와 threshold값의 차이) 를 기반으로 결정

C: Internet bottleneck state

  • PBE-CC : internet 내부의 bottleneck capacity와 일치하는 rate를 조사하기 위해 cellular 맞춤형 BBR로 전환

  • BBR sender : connection의 bottleneck bandwidth를 $BtlBw$로 설정

    • $BtlBw$ : 전송 flow에 사용할 수 있는 BBR의 예상 bottleneck bandwidth

      • 최근 10개의 RTT의 최대 delivery rate로 추정

    • sender : 자신의 offered rate를 아래와 같이 설정

      \[\text{offered rate} = \text{pacing_gain} \times BtlBw\]

    • pacing_gain : 3가지 값 중 하나로 설정됨

      • 1.25 ( available idle bandwidth를 probing하는 경우 )
      • 0.75 ( 이전 probing 기간동안 buffering된 packet을 drain하는 경우 )
      • 1 ( 그 이외의 경우 )

    • ProbeBW 상태 : bandwidth를 조사하기 위해 8단계로 이루어진 주기를 반복

      • 각 단계의 길이 : $RT_{prop}$

    • PBE-CC : 처음에 BBR의 ProbeBW 상태로 돌입

      • ProbeBW, ProbeRTT, StartUp, Drain 상태를 번갈아가며, BBR의 ProbeBR과 동일한 control logic을 따름
Wireless-aware, BBR-like probing

  • PBE-CC : internet bottleneck이 지원하는 더 높은 data rate 조사

    • cellular wireless link의 fair-share send rate도 고려

  • BBR의 bandwidth probing scheme 채택

    \[C_{probe}=min(1.25BtlBw, C_f)\] \[\begin{aligned} &C_{probe}=\text{probing rate}\\ &1.25=\text{BBR의 probing pacing_gain}\\ &BtlBw=\text{bottleneck bandwidth}\\ &C_f=\text{wireless link 최대 fair-share capacity} \end{aligned}\]

  • mobile user : internet bottleneck이 감지되면 $C_f$를 sender로 재전송

  • PBE-CC : probing 단계 이후 drain phase 실행 -> 모든 버퍼링 패킷 배출

    • BBR와 유사함
    • internet bottleneck이 감지됨 -> 이미 packet queue가 형성되어있음
      • 해당 상태로 전환 전에, 1 $RT_{prop}$시간 동안 추가 drain phase 실행
      • send rate를 $0.5BtlBw$로 설정
        • 남은 capacity $0.5BtlBw$는 drain하기 위해 남겨둠
Switching back to wireless bottleneck state
  • PBE-CC : network에 어떠한 packet queuing도 존재하지 않은 상태로 send rate가 $C_f$에 도달하면 internet bottleneck 상태를 빠져나옴
    • mobile user : 자신이 측정한 threshold $D_{th}$보다 적은 delay의 연속 packet $N_{pkt}$을 관측한 경우
  • internet bottleneck state를 빠져나와 wireless bottleneck state로 전환
    • network가 다시 internet bottleneck state가 될 때까지 상황 유지

Fairness and TCP-friendliness

  • PBE-CC : BBR 알고리즘을 보수적으로 수정

    • internet bottleneck 현상을 공유하는 flow과 경쟁에서 BBR보다 덜 공격적

  • wireless bottleneck 상태 : 각 PBE-CC user는 경쟁 user의 수를 알고 있음

    • fair-share cellular wireless capacity로 빠르게 수렴
  • cellular physical control channel message를 decode
    • 각 aggregated cell에서 capacity 사용량을 확인하여 fair-share capacity를 계산
    • 계산한 capacity와 sender의 send rate를 맞추도록 sender를 가이드
  • 기존의 end-to-end congestion control 알고리즘 : 더 복잡한 probing과 backoff step을 거쳐 fair-share를 probe해야함
    • 효율성이 떨어진다
  • cell tower의 공정성 정책 : PBE-CC는 다른 congestion control 알고리즘과 wireless link capacity를 공정히 공유
  • propagation delay가 다른 PBE-CC flow : wireless capacity를 공정하게 공유
    • 2가지 이유 존재
      • PBE-CC의 design
      • base station의 buffer 구조
    • PBE-CC : fair-share를 명시적으로 계산
      • 다른 congestion control 알고리즘 : AMID 방식 채택
        • additive increase multiplicative decrease
          • packet loss가 없다면 1개씩 window 증가
          • loss가 있다면 절반으로 window를 줄여버림
          • 나중에 들어온 user가 있더라도 시간이 흐르면 평형을 이룰수 있게됨
        • additive increase 단계 : 적은 propagation delay를 가진 sender가 window size를 더 빠르게 증가시킴 -> 불공평 야기
    • base station : 모든 user에게 분리된 buffer 제공
      • large $RT_{prop}$이 bottleneck을 지배하는 것을 방지
      • large $RT_{prop}$의 BBR 연결 : large BDP를 계산
        • network 내에 상당한 양의 packet을 흘려보냄 -> bottleneck queue에 저장될 것
        • small $RT_{prop}$을 가진 다른 BBR flow에서의 send rate를 낮추는 결과 초래 -> 적은 수의 packet이 돌아다닐 것
      • cellular base station의 분리된 buffer들 : wireless link를 공유하는 다른 flow들로부터 packet을 분리, 고립 -> unfair 방지

Implementation

  • control channel의 모든 control message를 decode해야함 -> 전화 내부의 휴대 펌웨어를 customize해야함
    • 현재 cellular 펌웨어의 소스코드 : cellular 장비 제조업체의 것 -> 접근 불가능
    • 펌웨어 수정할 필요 없이 control message를 decode하는 오픈소스 congestion control prototype 플랫폼 구축
  • 플랫폼 주요 구성요소 : 오픈소스 control channel decoder
    • 상용 소프트웨어 정의 radio ( USRP ) -> RF front-end로 사용
      • cellular wireless 신호를 수집
    • PC -> host로 사용
      • 수집한 신호에서 control 메세지를 decode
  • 다중 병렬 control channel decoder : 각각 1개의 cell에서 신호를 decode
    • 여러 cell에 대해 동시에 작동
  • message fusion module : subframe index에 따라 여러 decoder의 decode control message를 정렬
    • 정렬한 message는 congestion control module로 전달
  • cellular control channel decoder : 3300줄의 C언어로 구현 ( 재사용 코드 제외 )
    • 재사용 코드도 사용했음 ( 오픈소스 LTE 라이브러리 )
      • wireless channel estimator
      • demodulator ( 복조기 : 변조된 반송파로부터 정보 내용을 복구하기 위함 )
      • convolutional decoder ( 에러 방지를 위한 정정코드를 이용하여 에러를 정정하는 프로그램 )
    • 각 decoder : subframe control channel 내에서 가능한 모든 message position을 검색
      • 가능한 모든 message format를 시도하여 올바른 message 도출
      • control channel을 decode함
    • 병렬 decode 구조 구현 (멀티스레드 구조 사용) : 1개의 PC가 여러 cell의 control channel을 동시에 decode
      • 6코어 PC가 각 코어 CPU 사용량을 40% 미만으로 유지하며 6개의 cell을 decode할 수 있었음
  • PBE-CC congestion control 알고리즘의 user space 기반, UDP 기반 prototype 구현 : 874줄의 C++로 구현 ( mobile client, sender side )
    • client side PBE-CC module : decode된 control message를 입력으로 받음
      • 휴대전화로 sender와 통신
      • data packet을 수신할 때, one-way packet propagation delay $D_{prop}$을 추정하고, 추정 capacity를 반환
        • 2개의 1500byte packet을 보내는 interval을 이용하여 capacity 계산, 32bit 정수로 나타냄
      • 현재 bottleneck state를 식별
        • ACK의 1bit를 통해 sender에게 알림
    • server : ACK을 받으면 send rate를 ACK 안에 있는 capacity로 설정
      • 수신된 모든 ACK에 대하여 $RT_{prop}$과 $BtlBw$ update -> bottleneck 위치가 변경될 때마다 즉시 cellular 맞춤형 BBR로 전환할 수 있음

Evaluation

  • 상용 cellular network에서의 PBE-CC의 성능 평가
  • 기존 end-to-end congestion control 알고리즘과 비교

Methodology

Content sender
  • Amazon AWS 서버를 사용 ( PBE-CC sender로 사용 )
  • PBE-CC : 상당히 다른 RTT를 사용
    • 성능 테스트를 위해 3대의 미국 서버, 1대의 싱가포르 서버를 사용
Mobile client
  • 구성요소
    • 신호 수집을 위한 다중 USRP
      • USRP X310, B210
    • control channel decoding을 위한 host PC
      • Dell OptiPlex 7060
        • Intel Core i7-8700 CPU
        • 16GB RAM
        • Ubuntu 16.04
    • 무선 통신을 위한 휴대전화
      • 하드웨어 상에서 carrier aggregation을 지원하는 휴대폰을 사용
        • Xiaomi MIX3 // 2 cell
        • Redmi 8 // 1 cell
        • Samsung S8 // 3 cell
      • cellular network : 모든 휴대폰에 동일한 primary cell을 구성
        • 각 전화기에 대해서는 서로 다른 수의 aggregated cell을 구성했음
Congestion control algorithms to compare
  • 7개의 알고리즘과 성능을 비교할 것
    • cellular network를 위해 설계된 알고리즘
      • Sprout
      • Verus
    • 이미 Linux 커널에 포함된 알고리즘
      • BBR
      • CUBIC
    • 최근 고안된 알고리즘
      • Copa
      • PCC
      • PCC-Vivace
  • Pantheon 이용 : campus를 커버하는 상업용 cellular network에서 위의 모든 알고리즘을 테스트

Micro-benchmark: Cell status

  • micro benchmark 수행하여 cell tower의 2가지 중요한 통계를 제시

    • 매 시간 cell tower와 통신하는 user의 수
    • user의 wireless physical data rate의 distribution

  • control channel decoder : 2개의 base station ( 20MHz, 10MHz )이 전송하는 control message를 decode

  • 실험 수행 시간 : 24시간

    • 1시간마다 active user의 수를 계산

    • peak time인 12~20시에 user 수가 많이 감지됨

      시간당 user 수20MHz10MHz
      최대 user 수233135
      최소 user 수130
      평균 user 수18197
      • 0~3시에는 10MHz cell이 운영자에 의해 꺼졌고, 0명의 user가 관측됨

  • user들의 wireless physical data rate의 distribution 나타냄

    • user들의 data rate는 다양했음 // 대부분 rate가 낮았음
      • 각각 77.4% (10MHz), 71.9% (20MHz) 의 user들이 최대 달성가능 data rate (1.8Mbits/s/PRB) 의 절반도 못 미치는 rate를 보임

End-to-end Delay and Throughput

  • 상용 cellular network 상에서 달성된 PBE-CC의 delay와 throughput 성능을 조사할 것
  • 고정 cellular link에서의 PBE-CC 성능 조사
    • server <-> 고정된 mobile user간의 연결 생성
    • sender가 20초 동안 연결된 user에게 전송
      • throughput, packet delay, 각 flow의 도착 시간 등을 기록
    • sender가 사용할 수 있도록 알고리즘 수정, 8개의 알고리즘 테스트
  • 고려사항
    • 알고리즘을 테스트할 때마다 cellular network capacity가 달라짐
      • 공정한 throughput 테스트를 위해 각 알고리즘마다 5번 반복
    • 서로 다른 수의 aggregated cell의 성능을 측정해야함
      • 서로 다른 휴대전화를 사용
    • 실내 / 실외 상황에서의 변화 관측해야함
    • cell이 busy / idle인 상태를 측정해야함
      • day, late night 시간대에 따로 측정
  • 총 40개 지점, 실내 / 실외, (1, 2, 3) aggregated cell, busy / idle 시간대에서 가능한 모든 경우의 수를 테스트
Comparison among high-throughput algorithm
  • 더 높은 throughput을 달성하는 알고리즘
    • PBE-CC
    • BBR
    • CUBIC
    • Verus
  • 측정 목록
    • 평균 throughput
    • 95th percentile one-way delay
  • PBE-CC : 가장 높은 throughput, 매우 적은 latency

    • 다른 알고리즘과의 비교

      알고리즘throughputdelay reduction (95th)
      BBR1.06x1.8x
      Verus1.6x3.6x
      CUBIC2.3x1.8x
Detailed comparison among eight algorithms

  • 6개의 대표적인 위치 선택

  • (10th, 25th, 50th, 75th, 90th) throughput (100ms 간격), delay를 기록

  • 3가지 관측결과

    • PBE-CC : 평균 throughput이 높지만, 어느정도 높은 throughput variance를 지님

      • 다양한 wireless channel capacity에 따라 send rate를 일치시킬 수 있기 때문

        알고리즘throughputdelay비고
        BBR비슷함더 높음 
        Verus더 높음매우 김cellular network를 위해 만들어진 알고리즘
        CUBIC높음/낮음높음/낮음예측 어려움
        다른 알고리즘더 낮음 Copa, PCC, PCC-Vivace, Sprout

      • 추가 throughput을 달성하기 위해 cellular network secondary cell을 활성화하도록 trigger한 위치의 수를 기록

        • PBE-CC : 모든 위치에서 carrier aggregation 실행
        • BBR, Verus : 5/6 이상의 위치에서 실행
        • CUBIC : 1/2 이하의 위치에서 실행
        • 이외의 알고리즘 : 1/6 이하의 위치에서 실행
          • 보수적인 send rate 사용
          • network가 carrier aggregation을 비활성화
          • available wireless capacity 활용도 상당히 저하

    • PBE-CC : 낮은 delay, 낮은 delay variance

      • BBR, Verus : 상대적으로 높은 throughput, 더 높은 delay
      • throughput이 낮은 4개의 알고리즘 : latency가 더 낮음
      • delay gap이 발생하는 이유 : cellular 재전송
        • throughput이 높다 -> TB error rate의 증가 -> 재전송 증가
        • throughput이 높은 체계에서는 packet이 8ms 배수의 재전송 delay 유발

    • PBE-CC : cell이 idle 상태라면 throughput, delay 모두 낮은 variance를 보임

      • traffic, mobility 경쟁이 없다면, idle cell의 static user에게 wireless capacity가 안정화
      • capacity를 정확히 추정할 수 있게 되고, 안정적인 throughput, delay를 달성
Alternation between states
  • 평균적으로, 18% (25 busy link), 4% (15 idle link) 의 시간동안 internet bottleneck 상태로써 동작
    • cellular network의 bottleneck은 대부분 wireless link의 bottleneck이라는 가설을 입증

Performance under Mobility

  • cellular wireless capacity 변동 주요 원인 : user mobility에 따른 wireless channel 품질 변화

  • mobility에 따른 PBE-CC의 성능 테스트

    • cell이 대부분 idle 상태인 야간에 실험 개시

      • 다른 random 경쟁자의 capacity 변동을 최소화

    • 실험 예시

      • 처음 13초 : -85dBm RSSI가 있는 위치에 휴대전화 설치
      • 다음 13초 : -105dBm RSSI가 있는 위치로 휴대전화 옮김
      • 다음 4초 정도 : 아까보다 빠른 속도로 원래 위치 (-85dBm RSSI) 로 휴대전화 복귀
      • 다음 10초 : 원위치에 대기
      • 총 40초의 test case 생성, 테스트마다 이를 반복

    • 실험 결과

      알고리즘throughputdelay (95th)비고
      PBE-CC55Mbit/s64ms 
      BBR55Mbit/s156ms 
      CUBIC38Mbit/s296ms 
      Verus41Mbit/s467ms 
      이외의 알고리즘low -> wireless capacity의 활용도 낮음 PCC, PCC-Vivace, Sprout, Copa
      • 4개의 알고리즘은 wireless capacity의 활용도가 낮고, mobility가 packet delay에 영향을 미침

    • 추가 실험 예시

      • 40초의 testcase를 20개의 2초 간격으로 나눔
      • 각 간격의 throughput 중앙값, delay 중앙값을 표시
      • 대상 : PBE-CC, BBR

    • 추가 실험 결과

      • PBE-CC : mobility에 의한 신호 강도의 변화에 따라 send rate가 정확히 감소하거나 증가
        • network에 buffering이 거의 나타나지 않음
      • BBR : 부정확한 end-to-end capacity 추정
        • 신호 강도 변화에 과민반응 -> send rate가 과도하게 변화
        • throughput 감소 / 과도한 packet delay

Performance under Controlled Competition

  • network capacity 변화 원인 : 제한된 wireless capacity를 위한 user들간의 경쟁

  • 실험 환경

    • 제어 가능한 on-off 경쟁 traffic
      • 경쟁에 의한 시간 변동 wireless bandwidth 할당을 추적하는 PBE-CC의 기능 시연
    • Redmi 8 전화기 사용, 40초 동안 PBE-CC flow 실행
    • 매 8초마다 4초 동안의 동시 flow 실행
      • AWS server로부터의 60Mbit/s의 고정 offered load
      • Xiaomi MIX3를 이용하여 flow 실행
    • 야간에 실험 : 다른 user들과의 통제되지 않은 경쟁 가능성을 만듬
    • 다른 알고리즘들로 실험 반복

  • 실험 결과

    • PBE-CC만이 높은 throughput, 낮은 latency를 지속적으로 달성

      알고리즘throughputDelay (avg)delay (95th)
      PBE-CC57Mbit/s61ms71ms
      CUBIC58Mbit/s252ms416ms
      Verus56Mbit/s263ms403ms
      BBR62Mbit/s147ms227ms

  • 경쟁 traffic에 대한 react를 추가로 입증하는 실험 진행

    • 200ms 간격마다 troughput 평균, 수신된 모든 packet의 delay를 나타냄
    • MIX3에 의해 traffic에 경쟁이 발생한 부분을 음영으로 표기

  • 추가 실험 결과

    • PBE-CC
      • 경쟁자의 진입을 정확히 추적 -> send rate를 지체없이 낮춤
        • packet queuing이 거의 발생하지 않음
      • 경쟁 traffic 흐름이 끝남을 탐지 -> idle bandwidth를 즉시 확보
        • throughput을 극대화
    • BBR
      • 경쟁 트래픽에 의한 capacity 감소를 바로 감지할 수 없음
        • delay가 상당히 커지는 결과 초래

Single device multiple connections

  • 하나의 장치가 서로 다른 원격 서버에 다중연결하는 경우에서의 평가

  • 실험 환경

    • MIX3 휴대전화로 2개의 AWS 서버로 각각 40초 동안 동시에 flow 생성
    • 각 알고리즘마다 throughput과 delay 측정

  • 실험 결과

    알고리즘throughputdelay
    PBE-CC26Mbit/s, 28Mbit/s48ms, 56ms
    BBR10Mbit/s, 35Mbit/s 
    • 단일 연결에 대한 throughput은 낮을 수도 있음
      • 연결 전반에 걸쳐서 공정성 제공

Fairness

  • bottleneck이 cellular wireless link일 때의 PBE-CC의 공정성에 대한 평가
Methodology

  • base station resource 할당 알고리즘 + 공정성 정책을 알지 못함 -> 시뮬레이션 기반 실험은 실제 cellular network에서의 동작을 예측할 수 없음

    • cellular deployment에서 직접 공정성 평가

  • background traffic의 영향을 제거해야함

    • cell이 idle 상태일 밤에 실험

  • 실험 환경

    • 3개의 휴대전화를 경쟁 user로써 사용 // 각각 AWS server에 연결

      휴대전화 기종연결 시작시간연결 종료시간
      S80s60s
      Redmi 810s50s
      MIX320s40s

    • 3대의 전화기는 primary cell을 공유

      • secondary cell, 구성된 경우 tertiary cell은 다른 것을 사용
      • 1.94GHz의 primary cell이 공유 bottleneck

    • 3개의 연결이 동시에 진행중일 때, primary cell에 의해 각 user에게 할당된 PRB를 기록

      • fair-share를 달성한 경우, 같은 양의 PRB를 할당받았을 것

Multi-user fairness

  • 비슷한 propagation delay를 가진 PBE-CC user들에 대한 공정성 조사
  • 실험 환경
    • 3개의 미국 AWS 서버 설정
    • 3개의 휴대전화를 사용하여 각각 연결 시작
    • primary cell에 의해 할당된 PRB를 기록
  • 실험 결과
    • PBE-CC : bottleneck bandwidth의 fair-share로 빠르게 수렴
    • Jain의 공정성 지수
      • 2개의 동시 flow : 99.97%
      • 3개의 동시 flow : 98.73%
  • 연결된 모든 user가 cellular network를 사용하지 못하게 할 수는 없음
    • unknown user가 생성한 light background traffic을 관찰
    • PBE-CC : background user와도 fair-share 작동

RTT fairness

  • 다른 propagation delay를 가진 다중 flow 사이의 wireless capacity의 fair-share를 보장하는지에 대한 조사
  • 실험 환경
    • 3대의 휴대전화 사용
    • 3대의 AWS 서버에 각각 연결
      • 1개의 싱가포르 서버 (평균 RTT = 297ms)
      • 2대의 미국 서버 (평균 RTT = 52ms, 64ms)
    • 각 연결에 대해 할당된 primary cell의 PRB를 기록
  • 실험 결과
    • delay 차이가 큰 3개의 PBE-CC flow 모두 비슷한 할당 bandwidth를 얻음
    • Jain의 공정성 지수
      • 2개의 동시 flow : 99.74%
      • 3개의 동시 flow : 99.45%

TCP friendliness

  • 새로운 congestion control 체계에 요구되는 사항 : 기존의 알고리즘과 bandwidth를 공정하게 나눌 수 있어야 함
  • 실험 예시
    • 2 PBE-CC user, 1 BBR user의 상황
    • 2 PBE-CC user, 1 CUBIC user의 상황
    • 각 상황에서의 할당 PRB를 기록
  • 실험 결과
    • PBE-CC : 다른 체계의 flow들과 bottleneck bandwidth를 동일하게 공유
    • Jain의 공정성 지수
      • BBR과의 2, 3 동시 flow : 99.96%, 98.52%
      • CUBIC과의 2, 3 동시 flow : 99.95%, 98.34%
  • base station의 공정성 정책 : 한 user가 모든 bandwidth를 점유할 수는 없음
  • CUBIC, BBR : send rate를 급격히 올릴 수 있음
    • base station : 얻을 수 있는 bandwidth 제한 -> 다른 flow와 강제적으로 공유하도록 함

Discussion

Power consumption
  • mobile 장치 : 연결중이면 radio를 켜고 control channel을 decode하여 각 subframe에 해당 data가 있는지 여부를 검사해야함
    • PBE-CC : 현재 필요 이상의 시간동안 radio를 켜지 않음
      • 추가 전력 cost가 발생하지 않음
    • 작은 computational overhead 도입
      • 전송되지 않은 control message를 decode해야할 수도 있음
      • 개수는 매우 적음 ( 95% 이상의 subframe 내부에는 4개 미만의 control message가 있음 )
      • 길이도 매우 짧음 ( 70bit 미만 )
Packet buffering
  • PBE-CC : Kleinrock TCP 운영 지점에서 실행됨
    • buffering, delay를 최소화하는 지점
  • 실제로는 base station의 어느 정도의 byte를 buffering해두는 것이 좋음
    • send rate를 조정하는데 delay가 약간 듬
    • connection throughput 증가를 즉시 활용할 수 있음
    • ( congestion control에는 최소한의 RTT delay는 있음 )
  • 미래 계획 ( PBE-CC 확장 )
    • sender/app 등이 network 내부의 buffering을 적응적으로 조정할 수 있도록 할 예정
    • 증가된 throughput을 위해 증가한 delay를 상쇄할 계획
Fairness policy
  • PBE-CC : 연결 시작 상태에서는 모든 active user와 idle bandwidth를 fair-share
  • 미래 계획 ( 공정성 정책 통합목적 )
    • 낮은 physical data rate를 가진 user가 더 많은 양의 bandwidth를 잡을 수 있도록
  • PBE-CC : 임의의 공정성 정책에 적응 -> steady state에서 평형 달성
Misreported congestion feedback
  • PBE-CC : mobile user가 추정 capacity를 server에 보고
    • 문제점 : 악의적인 user가 network가 지원할 수 있는 양보다 많은 data rate를 보고할 수 있음 -> network에 엄청난 수의 data가 발생
  • 미래 계획 ( 악의적인 user를 감지하는 기능 추가 )
    • server-side에서 실행되는 BBR과 유사한 throughput estimator 구현
      • mobile user의 개입 없이 packet의 전송과 ACK의 timestamp만으로 현재 throughput 추정
    • PBE-CC : user가 제시하는 capacity와 계산한 throughput을 비교
      • 더 높은 capacity를 제시하는 user를 악의적인 user로 간주

Conclusion

  • PBE-CC : mobile user측 wireless physical-layer capacity 추정을 설계에 통합한 최초의 end-to-end congestion control 알고리즘
    • 4G, 5G wireless network multicell 설계에 매우 중요
  • multi-location, mobility, 다양한 background traffic level, 다양한 RTT를 특징으로 하는 철저한 성능 평가 실행
    • PBE-CC : latency와 throughput 모두에서 선두적인 알고리즘을 능가
  • 즉시 배포 가능
    • content server와 mobile user만 수정하면 사용할 수 있음
    • 수정 작업은 어떠한 윤리적 문제도 제기하지 않음
1. iMES, Lab Seminar
Lab Seminar
This post is licensed under CC BY 4.0 by the author.
Recently Updated
Contents