Multipath TCP in Smartphones: Impact on performance, Energy, and CPU Utilization 논문 reading(1)

요약

이 논문은 실제 안드로이드 애플리케이션에 대한 광범위한 실험 연구를 통해 스마트폰에서 MPTCP(Multipath TCP)의 잠재적 이점과 함정을 탐구합니다.
업로드, 다운로드 집약적, 네트워크 집약적, 대화형 등 다양한 유형의 애플리케이션과 다양한 네트워크 조건을 고려하고 MPTCP가 성능, 에너지 소비 및 CPU 활용률에 미치는 영향을 연구합니다.
우리의 결과는 스마트폰 앱에서 MPTCP의 이점이 이론적으로 예상보다 낮다는 것을 보여준다. 실제로 몇몇 경우 MPTCP는 성능과 에너지 소비 모두에 해를 끼칠 수 있다. 우리의 연구 결과는 스마트폰 설계자와 모바일 앱 개발자에게 사용자 경험을 개선하고 스마트폰 배터리 수명을 연장하는 통찰력을 제공할 수 있습니다.

1 INTRODUCTION

다중 경로 TCP(MPTCP)는 엔드 호스트가 여러 NIC를 동시에 사용하고 경로 다양성을 활용할 수 있도록 하는 새로운 표준화된 전송 프로토콜입니다.
MPTCP를 사용하면 TCP를 통해 실행되도록 설계된 수정되지 않은 애플리케이션이 하나의 종단 간 연결을 통해 서로 다른 경로를 통해 데이터를 교환할 수 있습니다. 스마트폰은 일반적으로 와이파이와 셀룰러 인터페이스를 모두 포함하기 때문에 MPTCP에 자연스럽게 적합합니다.
산업계와 학계의 큰 관심에도 불구하고, 스마트폰에서 MPTCP의 진정한 잠재력은 완전히 이해되지 않았습니다. 이론적으로 MPTCP는 SPTCP(단일 경로 TCP)보다 높은 처리량과 견고성을 제공할 수 있지만, 처음에는 데이터 센터 네트워크용으로 설계되었으며 WiFi 및 셀룰러 네트워크를 통해 사용할 경우 이점이 동일하지 않을 수 있습니다. 실제로 랩톱을 사용한 초기 실험 연구에 따르면 짧은 흐름의 경우 MPTCP가 더 빠른 경로를 통해 SPTCP보다 성능이 떨어질 수 있습니다.
또한 스마트폰에서 MPTCP를 사용하면 두 가지 방법으로 장치 에너지 소비에 상당한 영향을 미칠 수 있습니다.한편으로는 두 NIC의 결합된 사용으로 인해 추가적인 에너지 비용이 발생할 수 있으며, 다른 한편으로는 데이터 전송 시간을 단축하여 에너지 소비를 줄일 수 있습니다. 더 중요한 것은 MPTCP가 실제 스마트폰 앱에 미칠 수 있는 영향과 교차 계층 상호 작용으로 인한 에너지 소비에 대한 잠재적인 영향이 아직 완전히 이해되지 않았다는 것입니다.
이 작업은 실제 Android 앱에 대한 광범위한 실험 연구를 통해 스마트폰에서 MPTCP의 잠재적 이점과 함정을 탐색하여 격차를 메웁니다.
우리는 다양한 유형의 앱과 다양한 네트워크 조건을 고려하고 MPTCP가 성능, 에너지 소비 및 CPU 활용률에 미치는 영향을 조사합니다.
우리의 결과는 스마트폰 앱에서 MPTCP의 이점이 이론적으로 예상되는 것보다 낮다는 것을 보여줍니다. 실제로 몇몇 경우 MPTCP는 성능과 에너지 소비 모두에 타격을 줄 수 있습니다. 특히 MPTCP는 주로 데이터 집약적인 앱의 성능을 향상시키며, 주로 두 네트워크(WiFi 및 셀룰러)가 유사한 성능을 보이는 위치에서 향상시킵니다. 반면, 이기종 네트워크 조건에서 데이터 집약적인 애플리케이션의 성능을 저하시킬 수 있으며, 일반적으로 대화형 애플리케이션의 성능에 부정적인 영향을 미칩니다.
또한 MPTCP는 종종 두 네트워크의 결합된 사용으로 인해 더 높은 에너지 비용을 초래합니다. 실제로 MPTCP가 성능과 에너지 효율을 모두 개선하는 시나리오는 거의 발견되지 않았으며, 경우에 따라 두 메트릭 간의 균형이 관찰되었습니다. 반면, 대부분의 경우 MPTCP는 성능과 에너지 비용을 모두 낮추었습니다. 마지막으로 [21]의 작업과 마찬가지로 MPTCP는 일반적으로 CPU 활용률을 증가시킵니다.
그러나 활용률이 증가한다고 해서 에너지 소비가 증가하는 것은 아닙니다. 대부분의 경우 SPTCP에 비해 MPTCP의 에너지 소비가 더 높은 것은 네트워크 에너지가 더 높기 때문입니다.
이 논문은 다음과 같이 구성되어 있습니다. § 2는 실험 방법론을 설명합니다. § 3과 4는 각각 데이터 집약적인 애플리케이션과 대화형 애플리케이션의 경우 MPTCP가 성능, 에너지 소비 및 CPU 활용률에 미치는 영향을 분석합니다. § 5는 우리의 연구에서 얻은 결과와 교훈을 요약합니다. § 6에서는 관련 작업에 대해 설명합니다. 마지막으로, § 7에서 논문을 마무리합니다.

2 METHODOLOGY

측정을 위해 [11–13]과 유사한 방법론과 공개적으로 사용 가능한 자동화된 테스트 프레임워크 [10]을 몇 가지 수정 사항과 함께 사용했습니다.
Android 4.4.4를 실행하는 Nexus 5 스마트폰을 MPTCP v0.89.5가 포함된 수정된 Linux 커널과 함께 사용했습니다. MPTCP는 전체 MPTCP 모드에서 사용되었습니다 [23]. 우리는 전체 메시 경로 관리자, 기본 RTT 기반 스케줄러[24] 및 표준 리아 결합 혼잡 제어 알고리즘을 사용했습니다.
오늘날의 애플리케이션 서버는 MPTCP를 지원하지 않으므로 MPTCP 지원 SOCKS5[20] 프록시 서버를 통해 인터넷에 액세스하도록 스마트폰을 구성했습니다.
SOCKS 서버는 ShadowSocks [5]를 사용하며 최소 암호화 체계를 사용하여 오버헤드를 줄이도록 구성되어 있습니다. 전화기는 표준 ShadowSocks 클라이언트를 사용합니다. 이 구성은 Korean Telecom[1]의 Gigapath 프로젝트뿐만 아니라 많은 이전 작업[11–13, 22]에서 사용되었으며 매우 적은 런타임 오버헤드가 발생하는 것으로 확인되었습니다.

2.1 Applications

우리는 여러 범주에 걸쳐 있는 7개의 인기 있는 안드로이드 앱을 사용했습니다.

데이터 집약적인 애플리케이션은 다음과 같습니다.
대량 데이터 전송 앱(Dropbox, SpeedTest)과 스트리밍 앱(YouTube, Spotify)을 고려했습니다. Dropbox를 사용하여 자동화된 테스트 프레임워크는 20MB의 랜덤 데이터가 포함된 새 파일이 업로드될 때마다 업로드됩니다. SpeedTest를 사용하여 앱이 실행되고 보고된 다운링크 대역폭이 기록됩니다. 유튜브를 사용하여 동일한 HD 비디오(빅 벅 버니)를 세 번 재생하고 화질은 자동으로 설정하여 매 번 25초 동안 시청합니다. Spotify를 사용하여 75초 동안 새로운 음악(Shuffle play 기능)을 재생합니다.

대화형 앱은 다음과 같습니다.
브라우징(Firefox)과 두 개의 소셜 네트워킹 앱(Facebook 및 Facebook Messenger)을 고려했습니다. 파이어폭스를 사용하여 프레임워크는 빈 캐시로 다음 12개 사이트의 메인 페이지를 순차적으로 탐색합니다.
imgur, 위키피디아, 구글, 페이스북, 유튜브, 야후, 바이두, 아마존, 트위터, nytimes, flickr, qq.
Facebook에서는 먼저 뉴스 피드를 업데이트한 다음 새 상태를 게시하고 설명과 사진을 공유하며 텍스트 설명과 함께 새 체크인을 수행하는 동일한 순서로 세 번 반복합니다. 마지막으로 Messenger를 사용하여 연락처 목록의 맨 위 연락처로 문자 메시지와 사진을 보내고 세 번 반복합니다. Facebook과 Messenger의 경우 위치 서비스도 실행됩니다.

2.2 Measurements

우리는 서로 다른 네트워크 특성을 가진 네 곳에서 실험을 실행했습니다. 각 위치의 업링크/다운링크 대역폭(속도 테스트로 측정)은 표 1에 나와 있습니다. 참고로, WдLb 위치의 WiFi 대역폭(50-60Mbps)은 WbLд 위치의 LTE 대역폭(18-25Mbps)보다 훨씬 높습니다. 실험에 사용된 셀룰러 제공자의 경우, 테스트 위치에서 달성 가능한 최대 처리량은 약 25Mbps입니다.
또한 WдL 위치의 경우 두 네트워크에 대해 유사한 대역폭으로 실험을 수행하기 위해 WiFi 대역폭을 18-25Mbps로 제한했습니다.
또한 애플리케이션 계층의 실제 처리량은 여러 가지 이유로 인해 애플리케이션마다 다를 수 있습니다. 예를 들어, 애플리케이션이 사용 가능한 전체 대역폭을 활용하지 못할 수 있습니다.
또한 다음과 같은 네 가지 네트워크 구성을 고려했습니다. WiFi 전용(WiFi), LTE 전용(LTE), WiFi를 기본 서브플로우(MP-WiFi)로 하는 MPTCP 및 LTE를 기본 서브플로우(MP-LTE)로 하는 MPTCP입니다. 각 위치에서 4개의 네트워크 구성 각각에 대해 각 애플리케이션을 5회 반복했습니다. tcpdump를 사용하여 전화기의 모든 패킷을 캡처하고 몬순 전력 모니터를 사용하여 장치의 총 에너지 소비를 측정했습니다[4].

2.3 Metrics

본 연구에서는 바이트당 에너지, 성능 및 정규화된 CPU 활용률의 세 가지 메트릭을 사용합니다.

2.3.1 바이트당 에너지입니다. 바이트당 에너지(µ J/B)는 TCP/MPTCP 재전송을 제외하고 전화기와 프록시 서버 간에 교환된 총 바이트 수로 나눈 에너지 소비량의 비율입니다. 직관적으로, 주어진 데이터 전송 크기에 대해 열악한 네트워크 조건은 양호한 네트워크 조건에 비해 재전송 바이트 수와 바이트당 에너지 비용 증가를 초래합니다.
이 작업에서 우리는 네트워크 활동 에나와 관련된 에너지 소비에만 관심이 있습니다. 몬순으로 단일 패킷 전송/수신의 전력 소비량을 측정할 수 없기 때문에 데이터 버스트만 고려합니다.
데이터 버스트는 다음 두 조건을 만족하는 시간 간격 [ti,tj], ti <tj로 정의됩니다. (i) [ti,tj]의 연속 패킷은 도착 시간 ∆ T ≤ Tmax이고 (ii) [ti,tj]의 총 패킷 수는 N ≤ Nmax입니다.
주어진 앱에 대한 버스트 간격을 식별하기 위해, 우리는 그림 1a-1g의 예에서 보듯이 tcpdump에 의해 캡처된 패킷 추적과 전원 모니터에 의해 캡처된 전원 추적을 수동으로 동기화합니다.
유일한 예외는 Firefox입니다. 여기서는 페이지 로드 시간(페이지당 하나의 데이터 버스트)을 기준으로 데이터 버스트를 식별합니다(페이지당 하나의 데이터 버스트).앱의 특성이 다르기 때문에 임계값 Tmax와 Nmax는 표 2와 같이 앱마다 다른 값을 가집니다.
예를 들어, 그림 1c는 YouTube(25-38초)에서 항상 최소 1000개의 패킷(표 2의 Nmax = 1000)을 포함하는 매우 큰 다운링크 데이터 버스트를 하나만 보여줍니다. 대조적으로, 그림 1g은 Messenger에서 몇 가지 작은 데이터 버스트(Nmax = 10)를 보여줍니다.
동기화된 모든 데이터 전력 추적에 대해, 우리는 데이터 버스트와 겹치는 전력 추적의 세그먼트에서 네트워크 활동 에나와 관련된 에너지를 계산합니다. 예를 들어, 그림 1c의 YouTube의 경우 25-38초 동안의 에너지 소비만 고려합니다.
Messenger에서 버스트 크기가 매우 작기 때문에, Messenger 트레이스 동기화의 잠재적인 오류는 다른 앱에 비해 Ena 추정에서 더 높은 오류를 발생시킵니다. 이러한 이유로, 우리는 각 Messenger 데이터 버스트를 각 측면에서 0.1초씩 확장합니다. 즉, 알고리즘이 [ti,tj]를 데이터 버스트로 식별하는 경우 에너지 계산에서 [ti - 0.1,tj + 0.1] 간격을 고려합니다.
또한 네트워크 활동과 관련된 총 에너지 소비를 다음 두 부분으로 세분화합니다.

Ena = Ecpu + Edat a

여기서 Ecpu는 네트워크 활동 간격 동안의 CPU 에너지 소비이고, Edata는 데이터 전송 에너지입니다.
Edata는 격리할 수 없는 다른 하드웨어 구성요소(예: 화면, GPU)로 인해 실제로 에너지를 포함할 수 있습니다. 이러한 구성 요소의 에너지 소비는 특정 응용 분야에서 일정할 것으로 예상됩니다.
[8, 21, 33]의 방법론에 따라 Nexus 5용으로 개발한 CPU 전력 모델을 사용하여 데이터 버스트 Ecpu 동안의 CPU 전력 소비를 추정합니다.
이 모델은 Nexus 5의 4개 코어 각각에 대한 CPU 주파수 및 활용률을 입력으로 사용합니다. 우리는 이러한 값을 100ms마다 기록하는 앱을 작성하고 사후 처리에서 모델에 대한 입력으로 로그를 사용했습니다. [21]에 나타난 바에 따르면 100ms 로깅 간격은 무시해도 될 정도의 오버헤드로 양호한 정확도를 제공합니다. Ecpu는 각 100ms 간격에 걸쳐 모델이 예측한 에너지 값의 합입니다.
셀룰러 인터페이스는 데이터 전송 중 에너지 소비 외에도 테일 에너지 비용이 발생한다는 것은 잘 알려져 있습니다 [7, 19].
데이터 버스트 동안 잠재적인 테일 전력 소비는 Edata에서 이미 고려되고 있지만, 각 데이터 버스트의 끝에는 추가적인 테일 에너지가 존재하지만, 이는 우리가 고려하지 않습니다. 따라서, 최근 [8, 21] 연구에 따르면 LTE 테일 베이스 전력이 과거보다 훨씬 낮은 것으로 나타났지만, § 3, ≥ 4의 LTE 및 MP-LTE에 대한 에너지 결과는 (약간) 보수적입니다.

2.3.2 성능입니다. 다음을 위해 다양한 성능 메트릭을 사용합니다.
서로 다른 특성으로 인해 서로 다른 앱을 사용할 수 있습니다.
Speed test 성능 지표는 앱에서 보고하는 다운로드 대역폭입니다.
Dropbox 업로드 처리량을 다음의 합계로 계산합니다.
식별된 데이터 버스트의 바이트 수(TCP/MPTCP 재전송 바이트는 무시)를 데이터 버스트 기간의 합으로 나눈 값입니다.
YouTube, Spotify 다운로드 처리량은 식별된 데이터 버스트의 바이트 합계(TCP/MPTCP 재전송 바이트 무시)를 데이터 버스트 기간의 합계로 나눈 값으로 계산합니다. 처리량이 높을수록 비디오/오디오 품질이 높아집니다.
Firefox Firefox Developer Tools [2] 및 Navigation Timing API [3]를 사용하여 12페이지 각각에 대한 페이지 로드 시간 PLT를 계산했습니다.

PLT = loadEventEnd − responseStart

여기서 responseStart는 브라우저가 서버로부터 첫 번째 응답 바이트를 수신한 직후의 시간이고 loadEventEnd는 현재 페이지의 로드 이벤트가 완료된 시간입니다.
정의에는 DNS 조회, TCP 핸드셰이크 및 HTTP GET 요청 전송 시간이 포함되지 않습니다. 최종 메트릭은 다음과 같이 정의된 N 페이지에 대한 가중 페이지 로드 시간(WPLT)입니다.

여기서 PLTi는 i번째 페이지와 Si의 페이지 로드 시간입니다.
i번째 페이지의 크기(바이트)입니다. 즉, 더 큰 페이지에 더 큰 가중치를 할당합니다.
Facebook, Messenger 우리는 평균 왕복 시간(RTT)을 성능 지표로 사용합니다. 직관적으로, RTT가 짧으면 응답 시간이 단축되고 사용자 경험이 향상됩니다. TCP 접근법에 따라, 우리는 재전송된 세그먼트의 RTT를 계산에 포함하지 않습니다. 2.3.3 정규화된 CPU 사용률. i번째 코어, i = 1, 2, 3, 4에 대한 정규화된 CPU 활용률 메트릭 NUI를 다음과 같이 정의합니다.

여기서 ui, fi는 각각 i번째 코어의 사용률과 주파수이며, fmax = 2, 265.6KHz는 Nexus 5의 최대 CPU 주파수입니다.
또한
를 정의하고 데이터 버스트 간격에 대한 NU의 평균 값을 표시합니다. 다음에서는 정규화된 CPU 사용률(예: 그림 2d)을 계산된 총 지속 시간(초)으로 표시하는 그래프에 주석을 달았습니다. 매우 짧은 기간 동안의 높은 CPU 활용률이 높은 CPU 에너지 소비로 이어지지 않을 수 있다는 것이 직관입니다.