MPBond: Efficient Network-level Collaboration Among Personal Mobile Devices

2021 / 2 / 17 iMES 세미나

Abstract

• MPBond : 여러 개인 mobile device가 공동으로 internet에서 content를 가져올 수 있도록 하는 효율적인 system
  • 스마트워치 : data downloading을 통해 페어링된 스마트폰 지원
  • MPTCP ( Multipath TCP ) 에 영감을 받음
    • distribute multipath transport 개념 적용 ( 여러 subflow들이 다른 device로 traverse할 수 있음 )
  • 개발
    • cross-device 연결 관리 scheme
    • buffering 전략
    • packet scheduling 알고리즘
    • MPBond architecture에 기반한 policy framework
  • 범용 mobile device에 MPBond를 구현하고 있음
  • 다양한 network 조건에서 다른 workload를 이용한 실제 평가
    • MPBond의 효율성 증명
    • 최신 협업 framework와의 비교
      • file download time : 5% -> 46% 단축
      • video streaming bitrate : 2% -> 118% 향상
      • energy efficiency : 10% -> 57% 개선

Introduction

• user가 여러 개의 mobile device를 가지고 있는 것이 일반적
  • 스마트워치 : 스마트폰과 페어링되어야 함
    • 대부분 2개의 휴대전화 ( 업무용, 개인용 ) 사용
• 스마트 mobile device : 여러 network interface 포함
  • 원격 internet 서버, local device 등과 통신 가능
  • 핵심 : 협업적으로 작동할 수 있는 device network interface의 잠재력은 완전히 이용되기 힘듬
  • mobile device ecosystem에 networking software 혁신 도입

    • MPBond 개발 : 여러 개인 mobile devices들이 공동으로 internet에서 content를 가져올 수 있는 전체론적 system

      • 오늘날 mobile/wearable OS가 지원하지 못하는 것들을 가능하게 함
        1. 스마트워치 : cellular를 통해 data를 download하여, 페어링된 스마트폰 지원
           • 현재 많은 COTS 스마트워치는 cellular에 직접 access 가능
           • 단일 device를 사용하는 것보다 더 좋은 throughput 제공
        2. 공공장소에서의 WiFi network : 각 interface마다 rate에 제한 부과
           • 각 device마다 WiFi interface가 있으므로, multi-device collaboration으로 극복 가능
        3. 2개의 스마트폰이 LTE bandwidth를 공유할 수 있음
           • cellular interface가 MPBond에 의해 결합되어지고, 하나의 가상 interface로 사용됨
        4. Wearable : 신호가 좋은 지점에 배치하여 WiFi/LTE range extenders 역할 수행 가능
           • 스마트폰 : 배터리가 부족한 경우 에너지 효율적인 BT link를 통해 페어링된 스마트워치로 power-hungry LTE access를 offload할 수 있음
      • 위의 사용 사례들 : user data가 여러 subflow들에 분산되는 multipath transport scheme에서 실현될 수 있음

• MPBond : subflow가 서로 다른 device들을 통과하는 distribute multipath를 지원해야함 ( 기존의 multipath paradigm (MPTCP) 과 다름 )

  • client app이 실행되는 primary device / primary의 network 성능을 향상시키는 여러 helper devices로 구성
  • primary에서의 traffic : MPBond service에 의해 인터셉트
    • local wireless link ( pipe ) 를 통해 helper들에게 traffic을 distribute
      • helper : 각각 자신의 cellular interface를 통해 remote server로 traffic 전달
    • 나머지는 primary의 cellular interface를 통해 전송
  • 역방향 link ( downlink ) : 유사하게 작동
    • server 또는 MPBond capable proxy : content를 primary와 helper들에게 distribute
  • primary : 받은 모든 part를 merge -> client app으로 content 전달

• MPBond scheme : 많은 challenge를 안고 있음

  • 다른 기종들과 local wireless link를 적절히 관리하는 방법?
  • helper device를 전략적으로 활용하여 network 성능을 향상시키는 방법?
  • MPBond에 고유한 remote path와 local pipe를 모두 고려하는 강력한 multipath scheduler를 설계하는 방법?
  • user와 app에게 적절한 interface를 보이는 방법?
  • client와 server app에 대해 전체 MPBond system을 명료하게 만드는 방법?

• 주요 design

  • MPBond : distribute multipath transport 프레임워크
    • subflow가 helper를 traverse하고 helper들이 pipe를 통해 primary device와 data를 교환할 수 있도록 함
    • 다양한 wireless 기술을 이용하여 pipe를 유연하게 관리하는 scheme 개발
    • MPTCP의 control plane protocol 확장 -> primary와 helper 조정
      • distribute multipath와 pipe를 지원하기 위함
  • MPBond : 모든 subflow를 2개의 TCP flow로 분할
    • 분할된 결과
      • primary와 helper 사이의 flow
      • helper와 server 사이의 flow
    • TCP 분할 : MPBond ( internet과 pipe ) 의 경우에는 이기종 network에 걸친 end-to-end TCP session에 이득
      • flow를 분할하기 전에 buffer를 설정할 수 있음 : network 상에서의 변동에 의한 부정적 성능 영향을 효과적으로 완화
      • 신기술은 아님 : 한 단계 더 발전시킴
        • mobile multipath 전송의 맥락에서, helper device에 적용
  • PAMS ( Pipe-Aware Multipath Scheduler ) 개발 : 여러 subflow에게 traffic을 전략적으로 distribute
    • MPBond 맞춤형으로 개조하기 위한 3가지 구성요소
      • pipe, helper측 buffering, 이기종 network를 고려한 subflow latency 추정 module
      • 각 packet의 전송 latency를 낮추는 현명한 scheduling 결정을 위한 algorithm
      • network 상태 변동, pipe를 통한 고장 가능성을 처리하는 smart reinjection scheme
  • MPBond : 다양한 정책을 유연하게 지정할 수 있음
    • app별 사용 권한 부여
    • 각 device resource 소비 제한
    • traffic 우선순위 지정

• 상용 mobile device에 MPBond 구현

  • app 투명성과 좋은 성능을 유지하면서 user space에서 구현할 수 있음
  • 실제 mobile network로 체계적 평가
  • 주요 평가 결과
    • 비교 대상 : kibbutz, COMBINE ( 최첨단 system )
      • 결과 : 다양한 workload, 광범위한 network 조건에서 energy 소비 10% ~ 57% 줄임
      • 다양하고 wild한 network 환경에서, file download 시간 13% ~ 35% 줄임
        • download 시간 감소 -> 적은 energy 소비
    • bandwidth가 많이 필요한 360˚ video 스트리밍을 위해 적합한 QoE 제공하기 위해서는 3개의 협업 mobile device가 필요
      • MPBond dual mode의 효과 입증

• MPBond : distribute multipath 개념을 적용

  • 개인 mobile device간 network-level 협업 혁신을 이룬 효율적이고 실용적인 system
  • 다른 cross-device data sharing scheme보다 더 좋은 성능 제공
    • PAMS scheduler에 의해 향상된 성능
    • app의 투명성
    • 더 좋은 유연성
  • wearable 기기를 고려한 첫번째 연구
  • GitHub에 open-source로 공개되어있음

Background and Related Work

Multipath Transport

• 여러 network path를 동시에 활용하여 data 전송을 가속화하는 기술
• MPTCP ( 사실상 multipath solution ) : socket interface와 여러 기본 TCP subflow 사이에 shim layer 제공
  • transport layer에서 작동 : app과 network 모두 수정할 필요가 없음
  • 가치 : 다른 path의 공동 사용에서 입증됨
    • QoE가 다양한 internet app에서 주는 이점과 비슷
• packet scheduler : multipath 전송 system에 핵심 요소
  • 잠재적으로 이기종 network path를 통해 설정된 서로 다른 subflow에 data를 배포
  • MinRTT : MPTCP의 기본 scheduler
    • congestion window의 가용 공간, 최소 network RTT를 이용한 path 선택
  • MPTCP 성능을 향상시키기 위한 scheduling algorithm 혁신 연구도 있음
  • multipath transport protocol : 단일 host에서 subflow 설정
    • MPTCP
    • MPRTP
    • MPQUIC
    • MP-H2
    • MP-RDMA
  • MPBond : 협업하기 위해 subflow를 여러 mobile device를 통과하도록 distribute

Multi-device Collaboration

• 기존 work : data 전달을 위한 여러 device간의 network-level 협업을 해결하기 위해 다양한 노력
  • Mobile kibbutz : tethering 기반 MPTCP 활용
    • 자신의 cellular interface를 이용하여 다른 tethering된 device의 cellular network를 통한 network data 전송
    • Android : USB 케이블 또는 wireless network를 이용하여 device P는 device C를 tethering할 수 있음
      • wireless tethering을 사용하는 경우
        • P가 WiFi AP 역할 수행 ( SoftAP mode )
        • WiFi를 통해 C로부터 traffic 수신
        • P의 LTE network를 통해 internet server로 전송 ( uplink traffic )
      • downlink 방향도 비슷하게 작동
      • C는 2개의 local interface가 있음
        • P에 연결될 WiFi interface
        • MPTCP를 적용할 수 있는 자체 LTE interface
• PRISM : heavy-weight 메커니즘
  • OS kernel에서 TCP stack을 수정, 다중 WWAN link에서 단일 TCP flow를 제거
  • custom proxy를 사용, 다른 device의 다중 WWAN 연결을 활용
• 다른 network-level 협업 solution : app 계층에서 작동, 특정 app에 중점
  • COMBINE : HTTP byte-range request 사용, wireless peer 간의 HTTP server에서 file을 공동으로 download
  • MicroCast : video streaming이 주 목표
  • Cool-Tether : web browsing traffic 전용, energy 효율적 cellular tethering 제안
• MPBond : 경량, 여러가지 이점 제공 ( 향상된 성능 등 )
  • 신중히 설계된 scheduler, app의 투명성, 더 좋은 유연성
  • MPBond 이외 연구들은 wearable에 적용되지 않음
  • network-level 협업 이외에도, 여러 mobile device 간에 다른 I/O resource를 공유하는 system 존재

Motivation

1. Incentives to Carry Multiple Devices

• user가 여러 mobile device를 가지는 것이 보편화 ( 업무용 / 개인용 등 )
  • 분리하여 사용 : data의 유출이나 손상을 최소화
  • 통신사가 상호보완적 coverage 소지 => device를 바꾸면서 더 좋은 성능을 사용할 수 있음
    • 선불 요금제가 보급된 나라 ( 인도 ) 에서 인기
  • WiFi 핫스팟 용으로 이전 phone 사용
  • roaming에 편리한 sim card가 장착된 phone 사용
  • 배터리 불안 완화
  • 도난 방지
  • 여분의 저장공간 활용
  • 중요한 data 백업
• phone을 새로 사서 여분으로 사용하지는 않음
  • 기존에 사용하던 오래된 phone을 여분으로써 사용
• 스마트워치를 사용하는 것이 유행
  • sim card가 내장 : cellular network에 접근할 수 있음
  • internet access 기능을 갖춘 dual / triple mobile device 조합이 가능
    • 스마트폰 + 태블릿
    • 스마트폰 + 노트북 + 스마트워치
  • device network interface 잠재력은 완전히 이용되지 못함

2. Benefits of Multi-device Collaboration

• device들 간의 network-level 협업 : network 성능 크게 향상 가능
• 기본 idea
  • last-mile wireless hop이 bottleneck인 경우 : 여러 device로 동시에 download하는 것이 WWAN throughput 향상
  • 여러 device에서 수신한 content : WLAN을 통해 병합 -> app으로 전달
• WWAN측 throughput aggregation의 이점에 대해 실험적으로 입증
  • 이전의 연구에서는 거의 진행되지 않은 부분
  • 서로 다른 cellular carrier를 사용하는 3개의 COTS mobile device 고려
    • phone을 나란히 배치
    • 1분동안 자신의 LTE network를 이용하여 인근 server에서 동시 대량 download 수행
    • 200ms마다 TCP throughput 샘플링
    • 3곳에서 실험
      • 대학 사무실
      • 주택 아파트
      • 식료품 가게
  • 결과
    • 3개의 carrier가 각각 6.2Mbps ~ 61.8Mbps 범위의 중앙값 throughput으로, 3곳의 위치에서 다른 성능 보임
      • 특정 device가 특정 위치에서 더 좋은 성능을 보이지는 않음
      • app의 최소 QoE 요구를 충족 목적, live network 상태에 따라 최적의 device를 동적으로 선택 가능 ( MPBond가 지원 )
    • WLAN측 merging이 bottleneck이 아닌 경우
      • 2개의 interface 사용 : 15.8% -> 474.2% throughput 상승
      • 3개의 device 사용 : 63.1% -> 695.4% throughput 상승
    • aggregated throughput : bandwidth를 많이 잡아먹는 app을 효율적으로 지원
      • UHD video 스트리밍
      • mobile VR
      • mobile holographic communication

3. Networking Capability of Wearables

• 위의 실험 : LTE 기능이 있는 스마트워치가 포함되어있음
  • 적절한 throughput을 가지고 있음 // 그래도 network capability에 대해 스마트폰이나 태블릿 등과 비교당할 우려
  • 동일 년도에 출시한 스마트폰 vs 스마트워치를 이용하여 LTE throughput을 실험적으로 증명
    • device 기능이 성능에 미치는 영향 테스트
    • 실험 내용
      • 두 device에는 동일한 sim card ( AT&T ) 를 반복적으로 삽입
      • 동일한 위치 / LTE를 통한 10회의 연속 TCP bulk download
    • 결과
      • 스마트워치 중앙 throughput : 29.9Mbps
      • 스마트폰 중앙 throughput : 56.1Mbps
    • 예상 원인
      • 시계의 소형 form factor ( 안테나 크기 작아짐, tx/rx 전력 감소 )
  • But) 스마트워치 interface : 다른 device들이 WWAN측에서의 성능이 좋지 않은 경우, 공동 content 제공에 상당히 기여할 수 있음
• 잠재적 우려사항 : energy

4. Do Existing Network-level Collaboration Schemes Suffice?

• 기존 network-level 협업 scheme : 몇가지 한계점이 있음

A Lack of Flexibility

• 원하는 network-level 수준 협업 요구사항
  • 다양한 유형의 app을 지원할 수 있도록 유연해야함
  • mobile, network infrastructure에 대해 최소한의 변경을 요구
• kibbutz : app의 관점에서 tethering device는 단순히 layer-3 router처럼 작동
  • layer-4/5 에서 다양한 개선 및 정책을 유연하게 지원할 수 없음
  • tethering subsystem : OS/kernel과 결합 -> 수정이나 확장이 어려움
    • Android tethering은 많은 실질적 limit이 있음
      • 2개 이상의 device에 대한 tethering 지원하지 않음 -> 최대 2개의 device에서 동작
      • WiFi/Bluetooth 중 하나만의 tethering 연결이 설정될 수 있음 -> 원할한 handover 방해
      • carrier/device : tethering 기능을 잠그거나, tethering 기반 hotspot에 대해 제한된 data 요금제만을 제공
• PRISM : sender/receiver 모두에게 수정된 kerenl TCP stack, network의 custom PRISM proxy에 의존 -> 상당한 deployment overhead
  • WLAN architecture : WiFi Ad-hoc mode에 의존
    • Android, iOS에 사용할 수 없음
• COMBINE, MicroCast, Cool-Tether 등의 다른 scheme
  • layer-5의 app을 수정해야함
  • server : network 협업을 위해 HTTP byte-range request를 지원해야함
  • 일부는 특정 유형의 app traffic 전용으로 설계됨

Suboptimal Performance due to Fluctuating Network Conditions

• kibbutz ( tethering 관점 )
  • end-to-end path는 2가지 segment로 구성
    • WLAN
    • WWAN ( 이쪽의 throughput은 변동이 있음 )
  • WLAN측 성능 실험
    • 가시선(LoS) / 비가시선(NLoS)에 따라 physical distance가 달라지는 경우
    • phone -> phone 으로의 data fetching에서의 WLAN throughput 측정
  • 결과
    • WLAN throughput은 크게 달라짐
      • WWAN throughput보다 낮은 경우가 많았음
    • 이기종 link 특성 + 복잡한 상호작용 => WLAN, WWAN이 매우 다른 성능 나타냄
      • dynamic한 방식으로 bottleneck이 될 수 있음
  • 기본 tethering 매커니즘 : 단순한 layer-2/3 forwarding
    • 위의 이질성 + dynamic을 제대로 다룰 수 없음
    • tethering에서) 유효 data rate = WWAN, WLAN bandwidth의 최솟값
      • WWAN, WLAN을 분리하는 device에서 data를 적절히 buffering한다면 높일 수 있음
  • scheduling 결정을 내릴 때) 기존 scheme : 특정 시간에서의 WWAN, WLAN 사이의 bottleneck link의 성능만을 고려
    • workload 분산 최적화 X -> multipath 성능 저하

Excessive Energy Consumption

• 배터리 용량이 작은 wearable device 등에서의 문제점
• tethering 방식에서 congestion control = end-to-end
  • 한쪽이 bottleneck이라면 다른 쪽의 bandwidth가 줄어듬
  • 줄어든 만큼 radio-on 시간이 늘어남 -> energy 소비 증가
• app layer에서 작동하는 해법 : HTTP byte-range request 사이에 idle network period를 두는 것

MPBond Design

• MPBond : user가 mobile device를 공동으로 사용, app에 투명한 방식으로 internet에 접근할 수 있음
  • 1개의 primary device / 여러개의 helper device ( 다중 primary도 있는 듯 )
  • client app ( file downloader, video streaming 등 ) : primary에서만 실행됨
  • app의 TCP traffic : MPBond에 의해 투명하게 차단됨
    • primary의 자체 interface / forwarding이 있는 helper를 통해 전송되도록 schedule
  • 반대 방향 : MPBond 지원 remote server의 여러 subflow에 traffic 분산
    • content는 primary에서 합쳐짐
  • MPBond 지원 proxy 도입 : internet server로부터 완전히 투명해지기 위해 사용
    • 단일 path connection 설정
  • server : MPBond를 지원하는 remote server, proxy
  • MPBond : primary, helper에 OS service로써 구현
    • client측 app에서도 투명성 유지

1. Subflow management

• MPBond subflow의 상위개념 : MPTCP와 유사
  • 예외점
    • subflow가 다른 mobile device를 traverse
    • 수신된 part를 합치기 위해 primary와 helper가 local data를 주고받아야함
  • pipe : primary <-> helper 사이의 data channel
  • HS-path : helper <-> server 사이의 network path
  • PS-path : primary <-> server 사이의 network path ( helper 존재 X )
  • end-to-end subflow : PS-path 또는 HS-path + pipe를 통과
• WiFi, Bluetooth 등의 wireless 기술 사용 : 여러 pipe 동시지원
  • WLAN을 이용하여 helper를 WiFi AP 역할을 하는 primary에게 연결 or Bluetooth를 이용하여 helper를 primary에게 페어링하여 설정
  • scheduler : 동적으로 pipe를 고르거나 여러개를 사용하여 data rate를 높이려는 목적
    • 여러 요소를 반영하여 적합한 pipe 선택
  • pipe : 해체되거나 설정될 수 있음 ( MPTCP와 유사 )
    • user TCP 연결과 느슨하게 결합되어짐
    • data 전송에 방해 없이 pipe 간에 migration할 수 있음
• MPBond handshake 절차 : helper를 활용하는 primary <-> server 간의 subflow를 이용한 user TCP 연결을 설정 // MPTCP 방법을 따름
  • helper와 조정하기 위해 pipe를 통한 추가 control message 사용
  • HS-path + pipe가 포함된 subflow의 경우, primary : INIT_MP_JOIN message 전송
    • helper에게 client + server의 정보 제공
  • MP_JOIN message : 2번째 subflow 설정
  • ACK으로 MP_OK message 전송

Error Handling

• MPBond : MPTCP와 다르게, pipe failure도 처리해주어야 함
  • pipe가 고장나면 : subflow 해체, 보류중인 모든 data가 다른 subflow에 재주입
  • WWAN / WLAN link 오류로 인해 app data가 손실되는 일은 없을 것

2. Buffer Management and Helper-side Connection Split

• MPBond : 양 endpoint에 buffer 유지
  • network 변동 흡수
  • subflow의 이기종 특성 수용
• helper에도 buffer를 두었음
• MPBond의 모든 subflow는 2개의 TCP flow로 분할됨
  • primary <-> helper flow : pipe를 덮음
  • helper <-> server flow : HS-path를 덮음
• helper가 관여했다면, WWAN과 WLAN은 매우 다른 link 특성을 보임
  • TCP 분할 : TCP control loop를 줄임 => 이 상황에서의 성능 향상
  • 두 flow 사이에 buffer를 설정할 수 있음
    • subflow의 bottleneck 변화로 인한 부정적 성능 완화
    • primary와 helper가 가까워져 $Th_{pipe}>Th_{HS}$로 되는 경우 : helper에 buffer를 설치 => $Th_{pipe}$의 크기만큼 data 전달 가능 ( 더 빠른 data 전송 )

3. Pipe-aware Multipath Scheduler

• scheduler : traffic을 여러 path로 distribute하는 방법 결정
  • wireless 상황에서의 개선 연구는 많았지만, MPBond 적용에는 문제점이 있음
    • 대부분의 기존 mobile multipath scheduler : 2개의 path만을 다룸 ( WiFi, cellular )
      • MPBond가 처리하는 multipath로써의 확장 불가
    • 이전에는 pipe에 대한 연구가 없음
• Pipe-aware Multipath Scheduler ( PAMS ) 개발
  • 기존과 다른 차이점
    • subflow를 임의 개수만큼 scheduling 가능
    • scheduling에 MPBond의 TCP splitting, helper측 buffering 고려
  • 다양한 app에서 사용될 수 있음 ( data chunk 사용, 가능한 빠르게 전송해야함 )
    • file 전송
    • video-on-demand
    • web browsing
    • cloud 동기화
  • 다른 유형의 traffic pattern = real-time data streaming
    • live video streaming
    • low-latency game
  • 위의 app들에 대한 multipath의 이점
    • scheduling 알고리즘을 latency-favoring으로 전환해야함
    • multipath를 무작정 사용하면 QoE 패널티 발생
  • 이 논문에서는 latency에 민감한 traffic을 위한 scheduler는 만들지 않음
    • 사용하기 쉬운 interface를 통해 정책을 지정할 수 있도록 하여 handle
      • latency에 민감한 traffic은 단일 경로를 사용한다
      • 잠재적인 latency 팽창을 막기 위해, 우선순위를 높인다

MinRTT Considered Harmful

• 기본 MinRTT scheduler 직접 적용하여 성능문제 시연

  • primary : 2개의 subflow 설정

    • 근처 server로 직접 가는 flow / helper를 통해서 가는 flow

  • 각 link의 bandwidth

    Downlink	Bandwidth
    PS-path	8Mbps
    HS-path	10Mbps
    pipe	5Mbps

  • primary : MPBond를 이용하여 10MB file을 download

  • helper측 : buffer 존재 ( data를 저장 )

  • 결과

    • 3곳의 bandwidth는 모두 사용되어짐 ( 긍정 )
    • subflow는 동시에 끝나지 않음 ( 부정 )
      • helper를 통한 flow가 direct flow보다 4.5초 늦음
      • multipath 전송에서는, subflow가 동시에 끝나야함
        • 최적의 download 속도를 위한 필수조건
        • 이유 : 먼저 끝난 flow가 다른 flow를 지원할 수 있기 때문

• 불균형의 subflow 완료 원인 : scheduler가 PS-Path, HS-Path만을 모니터링

  • TCP splitting 매커니즘과 downstream pipe를 알지 못함
  • 두 subflow의 시간을 같게하는 것이 아닌, PS-Path/HS-Path의 완료 시간을 같게 맞춤
  • HS-Path bandwidth > pipe bandwidth이므로, helper측 buffer에 data 쌓임
    • 천천히 drain되며, 이것이 subflow 시간의 불균형 야기

• subflow가 동시에 끝나도록 하는 방법 : subflow availability 조건을 수정

  • helper subflow : HS-Path, pipe에 congestion window가 공간이 있는 경우 고려됨
    • minRTT : 전자만을 고려
  • 수정을 실제로 적용하니 subflow가 거의 동시에 끝남
  • pipe에 사용할 수 있는 CWND 공간이 필요 => helper측의 buffering 기능 상실 ( MPBond의 기능 상실 )
    • PAMS의 주요 과제 : **subflow 동시 완료를 달성하면서 helper측 buffering을 활성화**

Deriving the Pipe-aware Delay (PAD)

• downlink traffic을 위해 server에 있는 scheduler에 중점

• end-to-end packet delay 계산
  • 주어진 시간 $T$, packet이 주어진 subflow에 schedule되었을 때, packet이 receiver에 도달하기까지 걸리는 시간?
  • 단위
    • $B_s$ / $B_p$ : $T$에서 server / helper 측에 buffering된 byte 크기
      • TCP send buffer, user space buffer를 모두 포함
    • $Th_{ps}$ / $Th_{hs}$ / $Th_p$ : PS-Path / HS-Path / pipe 에서의 측정 downlink throughput
    • $OWD_{ps}$ / $OWD_{hs}$ / $OWD_p$ : 각각 상응하는 path의 one-way delay
  • direct subflow에서의 E2E delay = $OWD_{ps}+\frac{B_s}{TH_{ps}}$ ( prop delay와 que / trans delay 포함 )
  • helper가 존재하는 subflow : 2개의 buffer 포함
    • server측 buffer를 drain하는 시간 $T_1=\frac{B_s}{Th_{hs}}$
    • $T_1$ 시간 뒤에, helper측의 buffer level을 $B_p$ -> $B_p’$으로 변경
      • $B_p’=max{(0,B_p-Th_pT_1+B_s)}$
      • $T_1$의 시간이 지난 뒤, helper측 buffer에 남아있는 byte = $B_p’$
    • 남은 buffered data를 제거하는 시간 $T_2=\frac{B_p’}{Th_p}$
  • 전체 E2E delay = $T_1+OWD_{hs}+T_2+OWD_p$

• PAD 계산 \(\begin{cases} OWD_{ps}+\frac{B_s}{Th_{ps}},&\text{if }i=1\\ OWD_{hs}+\frac{B_s+B_p}{Th_p}+OWD_{p},&\text{if }i>1,\frac{B_p}{B_s}+1>\frac{Th_p}{Th_{hs}}\\ OWD_{hs}+\frac{B_s}{Th_{hs}}+OWD_{p},&\text{if }i>1,\frac{B_p}{B_s}+1≤\frac{Th_p}{Th_{hs}} \end{cases}\)

  • $i$ = subflow의 index ( $i=1$이라면 direct subflow )
  • $Th_{ps}$ / $Th_{hs}$ / $Th_p$ = 상응하는 path의 CWND와 RTT 사이의 ratio에 대한 exponential weighted moving average를 이용하여 추정
  • 실제로 $OWD$ 측정이 어렵다면, 근사값 $RTT / 2$를 사용
  • 2번째 식, 3번째 식은 $B_p’>0$, $B_p’≤0$인 경우로 나눠진 경우

The PAMS Algorithm

• PAD : subflow에서의 E2E delay 추정치 제공

  • 이것을 이용하여 scheduling을 결정해야함

• 가능한 방법 : minRTT -> minPAD로 수정하는 것

  • subflow가 idle인 한 최소 PAD로 subflow를 선택하는 것
  • subflow가 idle하다 = PS-Path나 HS-Path의 CWND 공간이 비어있다
  • 성능 : minRTT보다 뛰어남
  • 단점 : HS-Path의 CWND 공간을 모두 점유하려고 시도
    • subflow의 실제 capacity보다 더 많은 data를 scheduling할 수도 있음

• scheduling을 전략적으로 연기하여 좀 더 현명한 scheduling 결정을 내릴 수 있음

  • server meta buffer에 data가 많은 경우
    • = schedule되지 않은 remained data가 많은 경우
    • 모든 bandwidth utilization을 향상시켜야 함 : 모든 subflow를 busy 상태로 유지
    • PAMS : minPAD 적용
      • idle subflow가 있다면 최소 PAD를 가진 subflow를 즉시 고르고, busy 상태로 전환
  • server meta buffer에 data가 적은 경우
    • latency 낮추기 + 동시 subflow 완료가 더 중요
    • PAMS : idle subflow가 있더라도, latency를 줄이지 못한다면 skip
  • 단어
    • meta buffer : 아직 schedule되지 않은 data를 저장하는 buffer
    • per-subflow buffer : 이미 subflow에 schedule된 data를 저장하는 buffer

• PAMS 알고리즘 제작

  Input: S = A set of N subflows. The algorithm executes when at least one subflow is idle, i.e., its PS-Path or HS-Path had empty space in CWND.
  Output: Packet to transmit on a subflow [packet, subflow]
    
   1| packet <- GetNextPacket();
   2| Th[1..N] <- GetSubflowThroughput();
   3| PAD[1..N] <- GetPipeAwareDelay();
   4| Idle <- GetIdleSubflows();
   5| Busy <- GetNonIdleSubflows();
   6| target <- GetIdleSubflowWithMinRTT();
   7| Diff <- 0;
   8| for each subflow i in Busy do
   9|     if PAD[i] < PAD[target] then
  10|         Diff += (PAD[target] - PAD[i]) * Th[i];
  11| if Diff > GetUntrasmittedSize() then
  12|     return NULL;
  13| else
  14|     return [packet, target];
  

  • Idle / Busy : idle한 / non-idle한 subflow의 set
  • target : 최소 PAD를 가진 idle subflow
  • 8~14줄 : 이 algorithm의 핵심
    • target subflow가 완료되기 전에 현재의 busy subflows들을 통해 meta buffer의 모든 예약된 byte를 전달할 수 있는지의 여부 판별
    • busy subflow $i$에 대하여, buffer된 data는 PAD[i] 단위의 시간만큼 drain
      • target subflow가 완료되기 전에 scheduling되지 않은 추가 data를 전달할 수 있는 여유시간 = PAD[target] - PAD[i]
    • Th[i] : $i>1$인 경우, HS-Path와 pipe throughput의 최솟값
      • $i=1$인 경우는 direct path ( PS-Path ) 라서인가?
    • Di$ff$ : target subflow 완료 전에, 모든 busy subflow들로 전달할 수 있는 schedule되지 않은 byte 크기
      • Di$ff$ > 현재 schedule되지 않은 byte 크기라면 : 현재 packet의 scheduling을 연기, 이후에 현재 busy subflow를 통해 예약되도록 함
        • 전송시간 단축 효과
        • subflow 동시 완료 용이
      • 그렇지 않다면, target subflow에 packet을 바로 scheduling
        • bandwidth utilization을 높이는 효과
  • 이 알고리즘은 downlink traffic을 위해 만들어짐
    • uplink traffic에 대한 scheduler도 개념적으로 유사한 방법으로 개발

Data Reinjection

• reinjection : 이미 subflow $A$에 schedule된 data가 subflow $B$에 재주입되는 매커니즘
  • $A$의 예기치 않은 성능 저하하는 경우
  • $B$의 capacity가 갑자기 증가하는 경우
• MPTCP : 보수적이고 고정적인 reinjection 정책
  • 관련 subflow가 제거되는 경우
  • receiver buffer가 꽉 찬 경우
• MPBond : 여러 device, 이기종 network, helper측 buffering 등에 의해 network 성능이 dynamic하고 변동이 심함
  • 더 현명한 reinjection 결정이 필요
• MPBond reinjection scheme
  • schedule되지 않은 byte가 없는 경우 + $\frac{maxPAD-minPAD}{minPAD}>η$인 경우
  • $minPAD$ / $maxPAD$ : 모든 subflow들 중에서 최소 / 최대 PAD
  • $η$ : parameter
    • reinjection의 공격성 결정
    • η이 줄어들면 -> bandwidth utilization이 증가 / 더 자주 reinjection 발생
    • 경험에 의거하여 20%로 설정해두고 진행
  • 근거
    • PAMS가 모든 subflow 동시 완료를 위해 subflow의 buffer level ( $B_p$, $B_s$ ) 를 암시적으로 조정하므로, 모든 subflow의 PAD는 이상적으로는 유사해야함
      • 특정 subflow의 PAD가 너무 높거나 낮아지면 -> network 성능의 심한 변동 유발
      • 이 경우 subflow의 balancing을 위해 reinjection 실행
• MPBond : reinjection이 trigger되면 maxPAD의 subflow -> meta buffer로 $r$개의 ACK되지 않은, 가장 큰 sequence 번호를 가진 byte까지 이동
  • $r=(maxPAD-minPAD)\times B$
    • $B$ : maxPAD를 가진 subflow에서의 effective throughput
    • $r$ : PAD 관점에서, slow subflow가 the fastest subflow를 따라잡을 수 있는 방식으로 결정
  • $r$만큼의 “재호출된” byte : PAMS에 의해 다시 schedule

4. User/App Interfaces and Policy Engine

• MPBond : 2가지 type의 interface 제공 ( user / app developer )
• primary에 console이 내장되어있음 : user가 여러 상황을 선택할 수 있음
  • helper와의 pair / unpair
  • pipe 관리
  • MPBond를 사용하기 위한 app permission 주기
  • device의 runtime 상태를 monitor
  • 다양한 policy 구성
• API 제공 : 3rd-party app이 프로그래밍적으로 MPBond의 service를 이용할 수 있도록 함
  • device / pipe 관리
  • device / pipe 상태 query
  • pipe 구성 변경 등과 같은 중요한 event의 callback 기능
  • app data chunk의 경계 표시
    • GetUntransmittedSize() : 기본적으로 meta buffer에서 전송할 data의 총 크기를 반환
    • developer : app 계층 data chunk를 선택적으로 정의하여 현재 data chunk의 남은 byte를 반환하도록 할 수 있음
      • meta buffer 전부 보내는 것보다 각 data chunk의 전달이 빨라짐
• API 사용은 선택사항
  • MPBond : app에 대해 완전 투명성
  • API는 MPBond에 대한 보다 세분화된 manipulation, 상세한 monitoring 제공
    • Ex) data rate에 따라 bandwidth가 다른 pipe 사이로 dynamic하게 switch하여 QoE 요구사항을 충족하면서 energy 사용을 줄임
• MPBond : user에게 다양한 policy 유연하게 구성 가능
  • prototype이 지원하는 policy
    • 각 app에 대한 whitelist
      • 각 app에 대한 permission을 부여해야함
      • app이 MPBond를 이용해 접근할 수 있는 device/pipe set을 구성해야함
        • 일회성 작업
        • 뛰어난 유연성, 보안 강화
    • resource 사용량
      • MPBond : device를 비활성화할 수 있음
        • 배터리 수준이 threshold 미만으로 떨어진 경우
        • cellular 사용량이 사전 정의한 cap에 도달한 경우
    • 우선순위 지정
      • user : 특정 app에 대한 우선순위를 지정하는 rule을 구성할 수 있음

Dual Mode in MPBond

• MPBond : device가 primary / helper의 이중 역할을 가질 수 있도록 함
  • 다중 primary 공존 가능
  • dual mode : primary device가 다른 시간대에 traffic을 생성하는 경우, 협업 device들이 집단 bandwidth를 더 잘 활용할 수 있도록 함
  • 예시 : 2개의 device로 각각 서로 다른 DASH video를 보는 경우
    • 각 device의 개별 자체로는 충분한 bandwidth를 지원하지 못할 수 있음
    • 각 device : pairing하여 dual mode 실행
      • 자신이 primary로 video를 받으면서, 다른 device에게 content를 전달하는 helper의 역할 수행
    • 2개의 device : video chunk를 동시에 가져오지 않음 -> 다른 device가 가져오는 video chunk와 bandwidth 경쟁을 벌일 가능성이 적은 2개의 subflow로 download 가능
    • 각 device의 QoE가 개선됨
• prototype : 동일 device에서 primary / helper 등으로 여러 독립적인 MPBond instance를 실행함으로써 dual mode 실현
  • 한계 : 각 MPBond instance가 독립적인 schedule 결정
    • network 상태, traffic 패턴에 대한 global view가 없기 때문에, 차선책이 될 수는 있음
    • 모든 MPBond instance를 조정하는 “global manager”의 도입으로 해결 가능 ( 아직 구현되지 않음 )

Implementation

• 상용 스마트폰, wear OS에 구현
• C/C++ 사용하여 multipath TCP proxy 구현
  • MPTCP를 지원하지 않는 상용 internet server, middlebox 등에서의 실제 평가를 하기 위함
  • 8천줄의 C/C++, Java 코드 ( 기본 proxy system 제외 )
    • GitHub에 공개되어있음
• primary : 대부분의 logic이 MPBond server의 user space에 있음
  • MPBond proxy (helper) 와의 Ps-Path (pipe) 연결 수립
• 수정되지 않은 app을 지원해야함
  • netfilter를 이용한 경량 kernel module 구축
    • netfilter : client app traffic을 MPBond service로 가로채고 redirect
• WiFi pipe : primary / helper 간의 수명이 긴 TCP 연결로 구현
• Bluetooth pipe : Android Bluetooth socket API를 이용하여 구현
  • RFCOMM 연결 수립
• helper module : 배포하기 용이하도록 user space에 구현
  • proxy ( primary ) 와의 HS-Path ( pipe ) 연결 수립
• 각 subflow : 원형 큐 사용 -> user space에서 packet을 buffering
  • buffer : HS-Path, pipe의 kernel send/recv buffer와 함께 작동
  • 성능, energy 이점 제공
• pipe : 많은 user TCP 연결이 multiplex되는 수명이 긴 data channel
  • TCP 연결을 식별하기 위해 app payload 앞에 작은 header 붙임
    • TCP 연결 ID
    • message 길이
    • sequence 번호
• PAMS : MPBond proxy에 연결된 user space scheduling module
• PS-Path / HS-Path 정보 : Linux의 getsockopt API를 통해 server로부터 얻을 수 있음
• pipe throughput : primary에서 측정
  • 캡슐화된 control message를 통해 helper에게 전달
• 유연한 interface들 구현 : proxy로 보낼 pipe의 정보, 시간 결정
• prototyping하기 위해 out-of-band UDP channel 사용
  • HS-Path / PS-Path의 return path를 통해 pipe 관련 정보 전달
  • 나중에는 HS-Path / PS-Path ACK에 통합될 수 있는 TCP option으로 교체 예정
• user 정의 policy : 매 process마다 시행

Evaluation

• MPBond를 다양한 network, 다양한 device 설정 등에서 광범위하게 평가
  • 목적 : network-level 협업의 이점을 보여주기 위함
• micro-benchmark를 통해 MPBond의 주요 design 선택을 검토
• 최첨단 solution과의 정량적 비교
  • kibbutz, COMBINE
  • network 성능, energy 소비, QoE 등을 평가
  • 실제 LTE, WiFi network 상에서 스마트폰, 스마트워치 등으로 평가

1. Experimental Setup and Methodology

• 상용 Ubuntu 16.04 server에서 proxy 실행
  • MPBond, tethering 기반 MPTCP를 사용하는 kibbutz를 모두 지원
  • 4코어 3.6GHz CPU / 16GB 메모리
  • ‘decoupled CUBIC’ congestion control 알고리즘 사용
    • 각 path가 TCP CUBIC을 독립적으로 시행
  • server : file과 video content를 host
    • proxy에 근접해 있음
    • proxy와의 path는 bandwidth가 높음 -> E2E path의 bottleneck이 아님
• COMBINE : proxy가 필요하지 않음
  • 여러 mobile device가 HTTP byte-range request를 server로 직접 전송
  • 동일한 object의 서로 다른 범위의 chunk를 fetch
  • request : work-queue 알고리즘에 의해 schedule
    • 각 path의 chunk를 순차적으로 download
    • 그 chunk들을 primary한테 반환
  • 기본적으로 256KB 크기의 chunk로 기본 크기를 정함
    • 소형 file의 download에는 더 작은 chunk 크기 ( 128KB, 64KB ) 로도 시도하며 최상의 성능을 기록
• MPBond : PAMS 사용
• 사용한 mobile device
  • Pixel 2 ( phone )
  • Nexus 6P ( phone )
  • LG Urbane 2 ( smartwatch )
• emulated / real network 두 조건 모두에서의 MPBond 평가
  • network 상태를 emulate하기 위해, Linux tc ( traffic control ) 사용
    • 실제 WWAN, WLAN의 bandwidth로 조절
    • 상용 wireless network에서의 latency dynamic을 캡처
• 다른 장소에서 실제 LTE를 이용한 실험
• full-fledged energy model 사용 : battery의 영향력 이해 목적
  • network 전송에 따른 energy 소비량 추정

2. Microbenchmarks

• Pixel 2 with T-Mobile ( primary )
• Nexus 6P with AT&T ( helper )

Benefit of Helper-side Connection Split

• 주요 design : HS-Path와 pipe를 helper의 buffer로 분리

  • network 변동 흡수
  • 이기종 subflow의 특성 수용

• kibbutz와의 비교 : MPBond의 energy 및 성능 영향 이해

  • kibbutz : subflow에 대한 다양한 고정 scheduling ratio 사용
  • 4MB의 $p$%는 PS-Path로, 나머지 $1-p$%는 HS-Path와 pipe로 전송
    • offline에서 최적의 $p$의 값 도출 ( exhaustive searching 기법 )

• 안정된 network 상태에서의 비교 ( 초기상황 )

  subflow	bandwidth
  PS-Path	5Mbps
  pipe	5Mbps
  HS-Path	10Mbps

  • kibbutz와의 비교 ( 고정 scheduling ratio 사용 )
    • download 시간은 거의 동일 / energy 소비량 10~22% 줄임
      • helper측 연결 분할 : HS-Path로의 전송이 pipe의 전송보다 빠르게 완료
      • LTE 접속 시간이 단축되어 energy 소비 감소

• 변하는 network 상태에서의 비교

  • 처음 상태는 위와 동일 / 2초 뒤 HS-Path의 bandwidth를 1Mbps로 변경
  • helper측의 연결 split이 유효하면, download 시간과 energy 소비량이 모두 감소
  • HS-Path에 더 많은 data가 schedule되어있고, bandwidth가 갑자기 떨어지는 경우 더 좋은 성능
    • 분할된 flow 사이의 buffer : network 상태의 변동 흡수

Benefit of Flexible Feedback

• MPBond : HS-Path / PS-Path를 통해 pipe 정보를 공유

  • 간단하지만 효과적인 policy

  • 해당 path에 data 전송이 있을 경우에 pipe 정보 전송

  • “Flexible” 정책이라고 불림

    • HS-Path만을 통해 pipe feedback을 전송하는 것과 비교

    • 서로 다른 timing에 대한 평가

      • HS-Path 또는 pipe에 data 전송이 있는 경우 ( “fixed-always” )
      • HS-Path에만 data 전송이 있는 경우 ( “fixed-on-demand” )

    • 실험 ( 4MB file download )

      • 처음 상황 ( 위와 동일 )

      • 2초 뒤 : pipe의 bandwidth <- 10Mbps

    • 결과

      • fixed-always : HS-Path의 data 전송이 없는데도 정보 feedback 전송
        • helper의 radio를 항상 활성화 ( energy 소비 높음 )
      • fixed-on-demand : HS-Path의 data 전송이 있는 경우에만 feedback 전송
        • energy 소비 문제를 완화했음
        • pipe 정보는 최신을 유지하지 못함 -> 성능 저하 발생
      • flexible : HS-Path의 data 전송이 없다면 PS-Path로 feedback 전송
        • helper의 radio를 켜지 않아도 됨 -> energy 소비 저하
        • pipe의 정보를 최신으로 유지할 수 있음 -> 성능문제 해결

Estimating Pipe Buffering

• PAMS : packet의 pipe buffering 시간 추정
  • helper에 있는 buffered data, pipe throughput을 기준으로 측정
  • helper에 의해 발생하는 packet의 buffering delay를 직접 측정하지 않음
• 실험 ( 4MB file download )
  • 안정된 network 상태 ( 위와 동일 )
• 결과 ( 평균 소요시간 )
  • PAMS의 방식 : 3.6초 소요
  • 직접 buffering delay 측정 : 4.4초 소요
    • scheduler : 항상 부정확한 측정 buffering delay를 수신
    • scheduling 결정이 차선으로 이루어지기 때문

Reinjection Under Changing Network Condition

• reinjection : 변화하는 network 상황에서의 download 시간을 줄이는 방법
• 실험 ( 4MB file download )
  • 초기 상황은 위와 동일
  • 2초 뒤 : pipe의 bandwidth <- 1Mbps
• 결과
  • reinjection 활성화 : 4.8초
  • reinjection 비활성화 : 9.7초
• pipe의 bandwidth가 낮아짐 -> 동시 subflow 완료를 위해 pipe의 data가 PS-Path로 reinjection됨

3. Stable Network Conditions

• MPBond의 성능, energy 소비에 대한 평가 ( 안정된 network 상황 )

  • workload : 512KB ~ 2MB 크기의 file download
  • mobile device 개수를 다양하게 실험 ( 1~3 )
  • MPBond-Naive와의 비교 ( PAMS 대신 기본 minRTT scheduler 사용 )
  • 각 test : 20번의 download 반복 / 평균, 표준편차 기록
  • energy 계산할 때 : 포함된 모든 mobile device를 고려

• 결과 ( 공통 network bandwidth 설정 )

  path	bandwidth
  PS-Path	8Mbps
  HS-Path	10Mbps
  pipe	5Mbps

  • 각 device 개수 / 다른 scheme에 해당하는 7개의 군집이 있음

  • kibbutz와의 비교

    device 개수	download 시간	energy 소비
    2	5% ~ 11% 감소	10% ~ 14% 감소
    3	25% ~ 30% 감소	비슷

    • kibbutz : 구조적 한계에 의해 3개 이상의 추가 device를 활용할 수 없음

  • COMBINE과의 비교

    • MPBond : download 시간, energy 소비에서 훨씬 더 높은 성능

      device 개수	download 시간	energy 소비
      2	15% ~ 21%	28% ~ 38%
      3	12% ~ 26%	22% ~ 25%

  • MPbond-Naive와의 비교

    • energy 소비 비슷
    • 성능 더 높음
      • 차선의 scheduling 결정 사용 : subflow 완료 불균형

  • 개선

    • MPBond의 여러 design 선택에 기인
      • Layer 4의 system 및 pipe 구현
      • helper측 연결 분할 및 buffer
      • 신중하게 설계된 다중 scheduler

• 총 energy 소비량 세분화

  • MPBond-Naive : 실험에서 제외
  • 결과
    • 더 많은 device를 사용할수록 energy 소비 증가
    • COMBINE : primary의 energy 소비마저 증가
      • 효율적인 방식으로 workload를 분배하지 못하는 좋지 못한 scheduler design
    • MPBond : device를 많이 사용할수록 primary의 energy 소비가 줄어듬
    • kibbutz와의 비교
      • MPBond의 energy 향상 : 대부분 helper측에 있음
        • radio 활성화 시간을 줄이는 buffering 전략

• kibbutz / COMBINE과의 비교 ( 더 많은 bandwidth 조합 )

  • 2개의 device 사용

    • Pixel 2 ( primary ) / Nexus 6P ( helper )
    • pipe bandwidth <- 5Mbps

  • PS-Path, HS-Path를 다르게 하며 kibbutz에 대항한 MPBond의 energy 향상 실험

  • 결과

    • MPBond : HS-Path의 bandwidth가 높고 PS-Path bandwidth가 낮을 때 최고의 energy 이점

      • 1Mbps의 PS-Path / 18Mbps의 HS-Path

        file 크기	energy 소비
        512KB	31% 감소
        1MB	37% 감소
        2MB	47% 감소

      • download 시간 : kibbutz보다 약간 더 빠름

    • energy 절약 : 이기종 WWAN, WLAN link에서, 더 빠른 link의 radio-on time을 줄이는 helper측 buffering의 효과

  • PS-Path의 bandwidth를 변화하며 COMBINE과의 비교

    pipe	bandwidth
    PS-Path	5 / 8 / 11 / 14Mbps
    HS-Path	10Mbps
    pipe	5Mbps

    • MPBond : file download 시간을 14% ~ 46% 줄임
      • 24% ~ 57%의 energy 절감 실현
      • pipe와 PS-Path 사이의 이질성이 증가하면 MPBond의 향상성이 더 커짐

4. Varying Network Conditions

• MPBond의 성능 평가 ( 변화하는 network 상태 )

  • 위의 WWAN / WLAN bandwidth profile 채택

  • 결과

    scheme	download 시간	energy 소비
    kibbutz	21% ~ 23% 단축	18% ~ 25% 감소
    COMBINE	29% ~ 35% 단축	16% ~ 23% 감소

  • MPBond : 아래의 이유로 변화하는 network 상태에서 높은 network 활용도 달성

    • helper측 연결 split
    • vuffer 관리
    • PAMS scheduler

In-the-wild Experiments

• 실제 환경에서 실험

  • kibbutz와의 성능 평가 ( MPBond와 제일 유사 )

  • 2개의 위치 / 1분간의 download / 10회 반복

  • 100ms마다 순간 throughput 기록

  • 결과

    위치	중앙 bandwidth	byte당 energy
    1	13% 향상	19% 향상
    2	23% 향상	24% 향상

    • 낮은 throughput 기간을 많이 줄임 ( 5번째 백분위 수 throughput 90% 향상 )
      • 변동하는 WWAN / WLAN link capacity를 최대한 활용
        • buffer 관리
        • helper측 연결 split

5. Video Streaming Performance

• 지금까지의 실험의 workload : 대량 file download
• mobile network traffic을 지배하는 video streaming에서의 QoE, energy 효율 개선에 도움이 되는지실험
  • 다양한 scheme이 video bit rate에 미치는 영향 연구
    • Exoplayer 사용 / ABR video streaming
  • 3가지 video 설정
    • B2 : 2초 segment 길이의 Big Buck Bunny
    • T2 : 2초 segment 길이의 Tears of Steel
    • T6 : 6초 segment 길이의 Tears of Steel
    • B : 46kbps ~ 4.2Mbps에 이르는 20 bitrate / T : 253kbps ~ 10Mbps에 이르는 9 bitrate
    • 총 video 길이 -> B : 596s / T : 734s
• kibbutz와의 비교 ( 둘 다 video streaming app의 수정이 필요하지 않음 )
  • 비슷한 video bitrate / energy 소비 13% ~ 14% 줄임
  • 3개의 device를 사용하는 경우 : T2 / T6에서 video bitrate를 118% 향상
    • B2에서는 큰 변화 없음 ( 2개의 device로 최대 bitrate에 도달 가능 )
      • device당 energy 소비량은 감소 ( 3번째 device의 도움 )
  • T2 / T6 : 2가지 관찰 결과 제공
    • MPBond-Naive : 2개의 scheme보다 더 낮은 energy 소비량 / 낮은 video bitrate
    • MPBond : device 개수가 늘수록 bitrate 향상
      • bulk download하는 것만큼 각 device의 energy 소비를 줄이지는 못함
        • 더 높은 bitrate = 더 큰 video segment이기 때문
        • QoE와 data 사용량의 tradeoff

360-degree Video Streaming

• 360º video streaming : 기존 video streaming보다 더 큰 bandwidth 필요 ( MPBond의 이상적인 활용 사례 )
• 실험에서 video bitrate : 64Mbps로 고정
  • video player emilator 사용 ( 가지고 있는 device가 고화질 decode를 지원하지 않음 )
    • video content를 rendering하지 않고 download
  • video stall ratio ( 정지 시간 / video 길이 ) 를 QoE metric으로 사용
    • 단일 primary : 정지 비율 145%
    • helper 사용 : 27%
    • 3개의 device 사용 : 3%
      • 현실에서 종종 변동하는 LTE : 360º video의 높은 bandwidth 요구량을 항상 충족하지 못함
      • 2개 이상의 device를 지원하는 MPBond의 필요성 동기부여
  • device 개수를 1 ~ 3개로 다양하게 조정

6. Leveraging the Dual Mode

• LTE 연결 ( T-Mobile / AT&T ) 이 가능한 device ( Pixel 2 / Nexus 6P ) 를 휴대한 2명의 user 참여
  • 각 LTE의 bandwidth : 5Mbps로 제한
  • pipe : 조절되지 않음
• MPBond dual mode 향상성 확인 실험
  • 두 user가 동시에 작업 시행
    • 각 스마트폰 : 순차적 1MB chunk 요청
    • chunk 간격 시간 : 1 ~ 5초 사이의 랜덤으로 video streaming traffic을 emulate
  • MPBond dual mode / MPBond 없이 각각 chunk download하는 시간 비교
    • Pixel 2 : 32% 향상 / Nexus 6P : 29% 향상

7. Indoor Applicability

• 위의 실험 : MPBond의 주요 사용 사례에서 진행 ( 야외 cellular networking )

  • WiFi infra가 존재하는 실내 환경에서의 실험 진행

• WiFi infra가 있다면, WiFi / LTE를 이용한 MPTCP가 bandwidth aggregation에 쉽게 적용될 수 있음

• MPTCP와의 성능 비교 실험 ( 4MB file download )

  • 2곳의 indoor 장소에서 실험

    • A 위치 : -51dBm의 좋은 평균 WiFi 신호 강도
    • B 위치 : -68dBm의 좋지 않은 평균 WiFi 신호 강도

  • 2개의 scheme에 대하여 성능 / cellular data 사용량 비교

    • 1번 scheme
      • primary : MPBond
      • helper 존재
        • PS-Path, HS-Path : LTE
        • pipe : WiFi
    • 2번 scheme
      • MPTCP : WiFi
      • primary : LTE

  • 10회의 연속 실행

  • 결과

    scheme	위치	download 시간
    1	A	1.5s
    	B	1.2s
    2	A	1.0s
    	B	1.6s

    • 2번 scheme의 cellular data 사용량 : 1.6MB (A) / 3.3MB (B)
    1. MPBond : scheme 2보다 더 많은 cellular data 사용량
    2. WiFi 상태에 따라 scheme 2보다 성능이 좋을수도 (B) 안좋을수도 (A) 있음

• MPBond : WiFi 신호가 좋은 실내의 경우, context 정보를 활용하여 WiFi, LTE에 대한 일반 multipath인 scheme 2로 돌아갈 수 있음

  • scheme 사이의 자동 전환을 할 수 있는 상황 인식 framework는 구현되있지 않음

8. System Overhead and Energy Concerns

• remote server에서 큰 file을 download할 때, primary와 helper의 CPU utilization 측정
  • 비교대상 : kibbutz
  • 10회 실험 반복
  • => 평균 추가 CPU utilization은 primary / helper 모두 4%가 넘지 않음
• helper 역할을 할 때의 wearable device의 battery 방전 조사
  • 15분 분량의 video stream
  • 완전히 충전된 LG Urbane 2 스마트워치 사용
  • 10회 실험 반복
  • => 평균 7% 이하의 battery drop 보임
    • solution의 실현 가능성

• 이전 eveluation section의 energy 측정 결과 : power model 기반 ( 실제 hardware tool이 아님 )

  • model 부정확 등의 측정 오류를 이해하기 위해, 상용 power monitor 사용하여 실제 energy 소비량 측정

  • Samsung S5를 helper로 사용 ( power monitor에 꽂을 수 있음 )

  • Pixel 2를 primary로 이용

  • workload : 4MB file download

  • network 상태

    path	bandwidth
    PS-Path	8Mbps
    HS-Path	10Mbps
    pipe	5Mbps

  • power monitor : MPBond / COMBINE 경우의 helper측 energy 소비량 측정

    • 제한된 power monitor 수
    • helper측 : 대개 덜 강력함 / energy가 제한적임 ( wearable )

  • 10회 실험 반복

  • 결과

    • helper측 energy 소비량 : 2.3J ( MPBond ) / 3.4J ( COMBINE )
      • model에서 도출된 절대 energy number : 1.9J / 2.6J
      • 오차범위 최대 24%
    • model 기반 (27%), power monitor 기반 (32%) 상대 energy 절감 ( COMBINE에 비한 MPBond ) 차이 : 최대 5%까지 낮음

Discussion

MPBond over Homogeneous Cellular Links

• 위 실험들 : 다양한 ISP에 연결하는 mobile device로 수행됨
  • MPBond가 bandwidth aggregation에 이상적인 기회 제공
• MPBond의 primary / helper가 같은 cellular carrier를 사용하는 경우 ( AT&T ) 에서의 실험
  • 주택가 / 1분 동안의 download / 단일 device ( Nexus 6P ) 와의 비교 / 10회 반복
• 결과
  • Nexus 6P의 평균 throughput : 10.1Mbps
  • MPBond의 평균 throughput : 15.1Mbps
    • direct subflow : 8.2Mbps / indirect subflow : 6.9Mbps
  • helper를 추가하여 primary의 throughput이 감소하더라도, 전체 throughput에는 큰 이득이 있음
    • eNodeB가 항상 모든 resource block을 단일 UE에 할당하지 않기 때문
      • scheduling 정책 / 다른 단일 device의 존재 등 원인
• MPBond : 단일 device를 사용하는 것보다 더 좋은 throughput 제공

MPBond over Congested Networks

• MPBond : 단일 / 여러 carrier에 연결된 단일 device를 사용하는 것보다 wireless resource를 더 많이 공유
• 모든 사람이 MPBond를 사용할 때의 wireless spectrum의 혼잡이 생겼을 때의 상황?
  • zero-sum 상황 : 모든 user가 동시에 여분의 bandwidth를 가질 수 없음
  • 오늘날 Internet traffic은 급증함 -> MPBond 사용에 미치는 영향은 제한적일 것
  • MPBond user : 합리적인 cost로 다른 MPBond user들 사이에서 원하는 share를 얻을 수 있도록 helper device 수를 구성 가능
• 이 문제는 애초에 mobilde multipath / multi-device network 계층 협업의 문제임

Conclusion

• MPBond : 효율적인 network 계층 협업 framework
  • 개발
    • 연결 매커니즘
    • buffer 관리
    • packet scheduling
    • 정책 시행
  • 시연 / 평가 ( 성능 / energy 이점 )
    • 실제 mobile device / app / network