performance enhancing proxy for satellite...

Performance Enhancing Proxy for Satellite Communications

2014. 05. 07.

Jae-Hyun Kim

[email protected]

Wireless Internet aNd Network Engineering Research Lab.

http://winner.ajou.ac.kr

School of Electrical and Computer Engineering

Ajou University, Korea

Contents

Introduction of PEP

Approach in Application Layer

Approach in Transport Layer

Approach in Network Layer

Summary

2

Introduction of PEP

3

Introduction of PEP

PEP (Performance Enhancing Proxy) [1]네트워크 에이젼트로 종단 간 통신 성능을 향상시키기 위해 사용

일반적으로 PEP는 WAN 게이트웨이 기지국이나 위성 모뎀에 적용

적용 기술 Application layer: 데이터 압축, 캐싱

Transport layer: TCP 최적화, TCP/IP헤더 압축

Network layer: IP 라우팅 최적화

관련 표준 [1-4] RFC 3135, 3449

SCPS-TP

PEP Negotiation Protocol (DVB-RCS2)

4

[1] J. Border et al., "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, 2001.

[2] H. Balakrishnan et al., "TCP Performance Implications of Network Path Asymmetry", RFC 3449, 2002.

[3] SPACE COMMUNICATIONS PROTOCOL SPECIFICATION (SCPS)—TRANSPORT PROTOCOL(SCPS-TP), CCSDS 714.0-B-2, 2006.

[4] Digital Video Broadcasting (DVB); Second Generation DVB Interactive Satellite System (DVB-RCS2);Part 3: Higher Layers Satellite Specification,

ETSI TS 101 545-3 2012.

Environments of Satellite Communication

Challenge제한된 대역폭

위성에서 제공할 수 있는 대역폭이 제한됨

긴 전파 지연 시간

Round trip delay: 500ms (mesh 구조)

패킷 손실

강우감쇄, On-the-move (OTM), 재밍, etc.

5

패킷 손실 (전파 감쇄, 재밍)

긴 전파 지연 시간

패킷 손실 (OTM)

125ms

제한된 대역폭

t

f

Reference model of PEP

Splitting connection [5-6]위성링크를 따로 분리해서 PEP 기술 적용

위성 링크에 최적화 된 파라미터 적용

6

Source Destination(PEP) (PEP)

Classical TCP

Applications

Transport

Network

Data link

Physical

S-Network

Data link

Physical

Modified TCPClassical TCP Classical TCP

Applications

Transport

Network

Data link

Physical

Data link

Physical

Network Network

Data link

Physical

Classical TCPModifiedTCP

Data link

Physical

S-Network

PEP PEP

Satellite linkWired link Wired link

•Data compression•Data Caching•TCP optimization•Header compression•Routing optimization

[5] C. Caini, et al.,"PEPsal: A Performance Enhancing Proxy for TCP Satellite Connections",IEEE Aerospace and Electronic Systems Magazine, 2007.

[6] P. Davern et al.,"HTTPEP: a HTTP Performance Enhancing Proxy for Satellite Systems",International Journal of Next-Generation Computing, 2011.

Commercial Products

7

상용 제품의 제공 기능

<Cisco 1841 >

< Comtech Turbo IP G2 >

< XipLink >

TCP optimization

Optimal initial window size

Large maximum window size

Selective acknowledgments

Advanced congestion control

Acknowledgment spoofing

Fast retransmit

Data bundling and header optimization

Caching

Header compression

Packet packing

Lossy transcoding of JPEG image

Compression of HTTP data

<Newtec EL 820 PEP-Box Terminal >

< ViaSat Compact XPEP > < Rockwell Collins IPTM-2050 >

< Advantech wireless PEP> < MediaSputnik 2402 series>< Riverbed skipware>

Commercial Products

제품 기능 비교

8

CiscoComtech

Xiplink NewtecRiverbed

ViasatAdvantech

Rockwall

Mediasputnik

SCPS-TP X O O X O O X X O

OptimizedTCP

O O O O O O O O O

DataCompression

X O O O O X X O X

Header Compression

O O O X O X O X X

Caching O O O O O X O X X

Approach in Application LayerData CachingData Compression

9

Overview

Data Caching Data caching : 데이터나 명령어를 캐시 기억 장치에 일시적으로저장하는 것

네트워크 내에서 자주 쓰이는 데이터를 프록시 서버에 저장

Data caching을 통해 종단간 네트워크에 부하되는 데이터 양 감소

Data Caching 관련 기술Web/FTP/DNS Caching

SDR (Scalable Data Referencing)

Data Compression데이터를 더 작은 저장 공간에 효율적으로 저장하기 위한 기술

데이터 트래픽을 압축하여 전송

Data Compression 관련 기술MSR(Molecular Sequence Reduction)

10

Data Caching

DNS caching자주 사용되는 domain과 IP 주소 정보를 캐싱

효과

DNS 정보와 IP 주소를 매핑하는 시간을 단축하여 응답시간 단축

Web/FTP caching네트워크에서 자주 사용되는 웹페이지 정보나 FTP 데이터를 프록시 서버에 캐싱

효과

네트워크에 부하되는 데이터를 감소하여 WAN performance 향상

11

WAN

Client 1 Client 2

DNS Server

Server

1) 웹사이트에

2) 해 하는 IP 주소 정보

3) Domain과 IP

주소 정보를 캐싱

4) 서버에

5) 서버에

WAN

Client 1Client 2

Server

1) Request

2) Caching

3) Response

4) Request

5) Response

Data Caching

캐싱 정책 Reactive caching

LRU(Least Recently Used)

• 가장 오랫동안 사용되지 않은 파일 교체

LFU(Least Frequently Used)

• 가장 적게 사용된 파일 교체

MRU(Most Recently Used)

• 가장 최근에 사용한 파일에 우선순위

MFU(Most Frequently Used)

• 자주 읽는 파일에 우선순위

FIFO(First In First Out)

• 가장 처음 기록된 페이지 교체

Proactive caching

MPV(Most Popular Videos)

• cache the most popular videos from MPV list, subject to cache size

• cache content of each cell site is identical

• conventionally used by Internet CDNs

12H. Ahlehagh, et al, “Video Caching in Radio Access Network: Impact on Delay and Capacity,” in Proc. WCNC, April 2012.

Data Caching

모바일 네트워크에서 Caching시 고려사항 Where to cache?

EPC, RAN, D2D

What to cache?

Only a small amount of popular content is accessed by a large portion of users

How to cache?

Web caching, Redundancy elimination (Chunk-level, TCP-level, Packet-level)

13X. Wang, et al., “Cache in the Air: Exploiting Content Caching and Delivery Techniques for 5G Systems,” IEEE Comm. Mag., Feb. 2014.

Data Caching

모바일 네트워크에서 Caching시 고려사항 Where to cache?

Cooperative caching policies for EPC and RAN caching

14

Data Caching

SDR (Scalable Data Referencing)[7] Riverbed 상용 제품의 핵심 기능

중복되는 데이터를 제거함으로 WAN Traffic을 획기적으로 감소

SDR 알고리즘

네트워크에서 자주 사용되는 데이터를 캐시에 저장

캐시에 저장된 데이터 중 변경된 부분이 있는 경우 변경된 데이터만추가 전송

15[7] Riverbed SDR, http://aramidesign.com/portfolio/flash/riverbed/flashDemo.swf

End User Server

End User Server

Caching

변화된 데이터 전송

Caching

Data Caching

Performance of SDR [8]평균 15~20배 네트워크 처리율 향상

16[8] Riverbed WAN Optimizer Performance, http://www.riverbed.com/assets/media/documents/briefs/PerformanceBrief-Riverbed-

Solidworks.pdf

Data Compression

MSR(Molecular Sequence Reduction)[9] Juniper Networks사 WX Framework의 주 기술

반복되는 데이터 패턴을 압축하여 낭비되는 네트워크 자원 감소

MSR algorithm Data stream 내의 반복되는 데이터 패턴에게 index를 부여

데이터 전송 시 해 데이터 패턴의 index를 전송하고 수신단에서복조

17[9] Juniper Network MSR, http://forums.juniper.net/jnet/attachments/jnet/wx/19/1/analyzing_msr_techbrief.pdf

1001111001100101011010001110011111

10011010111010101001010100100010100111110010101110100110101110101010010101001000101001111100101011101001101011101010100101010010001010011111001010111010011010111010101001010100100010100111110010101110

10011010

000101101011010

01110101101001110

10011010111010101001010100100010100111110010101110100110101110101010010101001000101001111100101011101001101011101010100101010010001010011111001010111010011010111010101001010100100010100111110010101110

10011010

000101101011010

01110101101001110

100 0001011001110

User Server

반복되는 데이터 압축Data stream

Data stream

Data Compression

Performance of MSRMSR을 이용한 주 Application 별 데이터 감소율

18

Application MSR Data Reduction

E-mail 75%

MS SQL 80%

File Sharing 81%

HTTP servers 96%

Search servers 84%

Image servers 70%

Approach in Transport LayerSCPS-TPWireless TCPHeader Compression관련 연구 수행내용 (NC-PEP)

19

Overview of SCPS

20

CCSDS [10] Consultative Committee for Space Data Systems

1982년도에 세계 여러 나라들의 우주개발기구에서 공동으로 설립 미국 (NASA), 러시아 (RFSA), 일본 (JAXA)등 총 11개국 멤버로 참여

우리나라 (KARI) 외 28개국에서 참여(Observer)

규모: 145개 회사 참여, 552개 mission에 참여, 표준이 반영된 143개의제품 출시

Scope 미래지향적 우주 정보 시스템 표준 개발

다양한 우주 기관 및 우주 체계 간의 협력 체계 증진 및 상호운용성 지원

SCPS Space Communications Protocol Specification

목적 위성에서 IP 통신 시 발생하는 문제점 극복

지상 Internet(FTP/TCP/IP) 지원을 위한 프로토콜 개발

[10] OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS, CCSDS 130.0-G-2, 2007.

CCSDS SCPS-TP (1/5)

21

SCPS-FP

SCPS-TP

SCPS-SP

SCPS-NP

SCPS-FP

SCPS-TP

SCPS-SP

SCPS-NP

주요 기능 [11] Full/best-effort/minimal reliability 통신 지원

대역폭, 전송지연, 에러율의 다변화 에서 효율적인 동작

멀티케스팅의 UDP(Connectionless 통신) 지원

우주 기반 동작환경에서 효율적인동작

서비스의 우선순위 지원 패킷 기반의 어플리케이션 지원

적용 기술 Selective NACK TCP Vegas ECN-Echo Window Scaling Header compression

[11] SPACE COMMUNICATIONS PROTOCOL SPECIFICATION (SCPS)-TRANSPORT PROTOCOL(SCPS-TP), CCSDS 714.0-B-2, 2006.

ECN: Explicit Congestion Notification

FP: File transfer Protocol

TP: Transport Protocol

SP: Security Protocol

NP: Network Protocol

CCSDS SCPS-TP (2/5)

22

Selective NACK Error Hole 크기

Bit-Vector

SNACK Bit-Vector1st Hole

CCSDS SCPS-TP (3/5)

TCP Vegas [12]네트워크 혼잡 회피를 RTT에 의해서 수행 (RTT 무선 단 채널 에러와거의 무관)

Define & update every RTT Expected throughput(ET) =

W(i) / RTTmin

Actual throughput (AT) = W(i) / RTT(i)

Diff = ET – AT (note diff>0)

Congestion control of TCP-Vegas based on diff If diff < α increase CWND linearly

If diff > β(>α) decrease CWND linearly

If α < diff < β unchange CWND

23[12] L. Brakmo, S. O’Malley, and L. Peterson, “TCP Vegas: New Techniques for Congestion Detection and Avoidance,” ACM SIGCOMM, 1994

cwnd cwnd/2 + 3

time

cwnd

SS CA SS CA CA

Duplicate ACK

CA

cwnd 1

Timeout

SS

SStime

cwnd

CA

Reno

Vegas

SS: Slow startCA: Collision avoidanceCWND: Congestion window

CCSDS SCPS-TP (4/5)

ECN-Echo [13] Congestion 발생 예상되면 라우터에서 ECN-Echo를 TCP 송신자에게 전달

네트워크 혼잡과 무선단에서 패킷 손실을 구별 가능

Window Scaling [14] CWND를 최대 1 gigabyte까지 증가하여 사용 가능 (default:

2~65,535 bytes)

최대 TCP 처리율을 높일 수가 있음

24

CWND: Congestion window

𝑀𝑎𝑥. 𝑇𝐶𝑃 𝑇ℎ𝑟𝑜𝑢𝑔ℎ𝑝𝑢𝑡 =𝑀𝑎𝑥. 𝐶𝑊𝑁𝐷

𝑅𝑇𝑇

[13] V. Jacobson et al., "TCP Extensions for High Performance", RFC 1323, 1992.

[14] K. Ramakrishnan et al.,"The Addition of Explicit Congestion Notification (ECN) to IP" RFC 3168, 2001

CCSDS SCPS-TP (5/5)

25

헤더 압축연 되는 데이터그램은 50%이상의 중복된 헤더 정보를 가짐

특정 헤더를 사용할지안 할지 결정

헤더압축

Wireless TCP

Wireless TCP 개요 [15]

26

Wireless TCP(TCP 가속기술)

Connection management related

approaches

Wireless loss related

approaches

Split connection

End-to-end connection

LocalizationExplicit

notification

[15] B. Sardar and D. Saha, "A survey of tcp enhancements for last-hop wireless networks," Communications Surveys & Tutorials, IEEE, vol. 8, pp.

20-34, 2006.

Wireless TCP

위성 환경에서 TCP 성능 (아주대)긴 전송 지연과 패킷 손실에 의해 TCP 처리율 크게 감소됨

27

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 110

1

2

3

4

5

6x 10

6

RTT

TC

P T

hro

ug

hp

ut

(bit

s/se

c)

10-5

10-4

10-3

10-2

10-1

0

2

4

6

8

10

12x 10

5

PER (Satellite link)

TC

P T

hro

ug

hp

ut

(bit

s/se

c)

<RTT에 따른 TCP 처리율, PER = 0%> <PER에 따른 TCP 처리율, RTT = 500ms>

시뮬레이션 환경• Metric: 위성 링크로 연결된 소스 노드와 목적 노드 사이의 TCP Throughput 측정• Max. Contention window size: 65,535bytes• Segment size: 1500bytes

(sec.)

Wireless TCP

Split connection [16-17]유선망 부분과 무선 망 부분을 분할하여 서로 다른 TCP 세션을 사용

28

TCP

Network

Link

PHY

Application

TCP

Network

Link

PHY

Application

Modified TCP

Network

Link

PHY

Application

Modified TCP

Network

Link

PHYData Data

ACKACK

Wired Wireless

FH BS MH

※ FH: Fixed hostBS: Base stationMH: Mobile host

Split connection

장점

• FH와 BS 사이에는 기존 TCP 사용 FH 수정 불필요

• 무선단에 최적화된 TCP 방식 적용 가능 TCP Peach, TCP Veno, TCP Hybla (End-to-

end connection)

단점

• 기존 TCP의 End-to-End semantic 위배• 기지국에서 세션마다 버퍼 필요• Forward 링크와 Reverse 링크가 서로 다르면 적용

어려움

[16] A. Bakreand B. Badrinath, “I-TCP: Indirect TCP for Mobile Hosts,” IEEE ICDCS 1995.

[17] K. Brown, S.Singh, “M-TCP: TCP for Mobile Cellular Networks,” ACM Comp. Commun. Rev., 1997.

Wireless TCP

Split connection 관련 연구[16-17] Indirect TCP [16]

유선망에서는 표준 TCP 사용, 무선망에서는 무선 TCP 사용

M-TCP [17]

유선망에서는 표준 TCP 사용, 무선망에서는 패킷 해더 압축 사용

무선망에서 패킷 손실이 발생하면 유선망 TCP를 persist 모드로 동작

• 수신 버퍼 크기를 0으로 설정하여 패킷 전송 잠시 중지

• 전송률은 유지

29

Wireless TCP

End-to-end connection [18-22] TCP congestion avoidance 알고리즘 수정

30

장점

• 무선단에서 발생한 패킷 손실이 전송률에 영향을 주지 않음 전송률 측정에 RTT (TCP Vegas), ACK 수신 inter-

arrival time (TCP Westwood), dummy 패 킷 (TCP

Peach) 활용 Congestion에 의한 패킷 손실과 무선 채널에러에 의한

패킷 손실을 차등하여 Congestion Control (TCP Veno)

• 무선 환경에 적합하게 TCP CWND tuning

TCP Hybla

단점

• 기존 소스 노드의 TCP 수정 필요 기존 시스템의 교체 필요

[18] I. F. Akyildiz, et al., "TCP-Peach: a new congestion control scheme for satellite IP networks,” IEEE/ACM Transactions on Networking, vol. 9, pp. 307-321, 2001.

[19] M. Gerlaet al., “TCP Westwood: Congestion Window Control Using Bandwidth Estimation,” IEEE GLOBECOM 2001

[20]E. H. K. Wu and M. Z. Chen, “JTCP: Jitter-Based TCP for Heterogeneous Wireless Networks,” IEEE JSAC 2004.

[21] C. P. Fu and S.C. Liew, “TCP Veno: TCP Enhancement for Transmission Over Wireless Access Networks,” IEEE JSAC 2003.

[22] C. Caini and R. Firrincieli, “TCP Hybla: a TCP enhancement for heterogeneous networks,” International journal of satellite communication and networking, 2003.

TCP

Network

Link

PHY

Application

TCP

Network

Link

PHY

Application

TCP

Network

Link

PHY

Application

Data Data

ACKACK

Wired Wireless

FH BS MH

E2E connection

Wireless TCP

End-to-end connection 관련연구 (1/2) TCP-Vegas [12]

가용 가능한 패킷 전송률을 패킷 왕복 시간(RTT)의 변화율을 이용하여 측정하여 사용

TCP-Peach [18] Dummy 패킷 전송을 통하여 최대 패킷 전송률에 도달하기까지의 시간을감소함

패킷 손실이 발생하면 Dummy 패킷 전송을 이용한 fast recovery

TCP-Westwood [19] ACK 패킷을 수신하는 inter-arrival 시간을 이용하여 사용 가능한 패킷 전송률을 측정

JTCP [20] 패킷 전송 지터를 이용하여 사용 가능한 패킷 전송률 측정

TCP-Veno [21]• Congestion에의한패킷손실과무선채널에러에의한패킷손실을차등하여

Congestion Control

» Minimum RTT보다일정수준 (N) 이상의 RTT이면서패킷손실Congestion, 이외의경우무선채널에러

31

Wireless TCP

End-to-end connection 관련연구 (2/2) TCP Hybla [22]

RTT가매우긴위성통신에서성능을향상하기위해 reference RTT

(RTT0)의기준에맞춰 Max. Congestion Window증가 및 Congestion

Control 파라미터수정

32

0/

H

H

H

RTT RTT

MCWS MCWS

ICWS ICWS

ssthresh ssthresh

Slow Start

Congestion Avoidance

Wireless TCP

Localization (TCP Snoop) [23-25] BS에서 TCP의 중복 ACK를 감지하면 빠른 재전송

33

장점

• 소스노드와 목적노드에서 기존 TCP 사용• 무선단에서 발생한 패킷 손실 빠르게 복구 가능 중복 ACK에 의한 TCP 전송률 감소 없음

• 기존 TCP의 End-to-End semantic 유지

단점

• TCP-aware 링크 단 구현 필요• 기지국에서 세션마다 버퍼 필요• Forward 링크와 Reverse 링크가 서로 다르면 적용

어려움

TCP

Network

Link

PHY

Application

TCP

Network

Link

PHY

Application

TCP

Network

Link

PHY

Application

Data Data

ACKACK

Wired Wireless

FH BS MH

Snooping

[23] B. S. Bakshiet al., “Improving Performance of TCP over Wireless Networks,” ICDCS, 1997.

[24] N. Vaidyaand M. Mehta, “Delayed Duplicate Acknowledgments: A TCP-Unaware Approach to Improve Performance of TCP over

Wireless,” Texas A&M University, Tech. Report, 1999.

[25] S. Vangalaand M. Labrador, “The TCP SACK-Aware-Snoop Protocol for TCP over Wireless Networks,” IEEE VTC 2003.

Wireless TCP

Localization 관련 연구 SNOOP [23]

링크 단에서는 TCP 데이터 패킷을 감지하여 버퍼에 저장

중복 TCP ACK를 감지하면 링크단에서 재전송 수행

중복 ACK 전달하지 않고 삭제

Delayed Duplicate ACK [24]

TCP의 delayed duplicate ACK를 감지하여 재전송 수행

TCP-SACK-Aware SNOOP [25]

Selective ACK를 사용하는 TCP에도 재전송 기능 지원

34

Wireless TCP

Explicit notification [26-27] BS에서 중복 ACK 수신 시 무선 단에서 손실된 패킷에 대한 중복

ACK에 무선 단 패킷 손실 비트를 마킹하여 전송

35

장점

• 무선 단에서 발생한 패킷 손실에 의한 TCP 전송률감소가 없음

단점

• TCP-aware 링크 단 구현 필요• 기지국에서 세션마다 버퍼 필요• Forward 링크와 Reverse 링크가 서로 다르면 적용

어려움

TCP

Network

Link

PHY

Application

TCP

Network

Link

PHY

Application

TCP

Network

Link

PHY

Application

Data Data

ACKACK

Wired Wireless

FH BS MHExplicit notification

[26] Hari Balakrishnan and Randy H. Katz, “Explicit Loss Notification and Wireless Web Performance”, IEEE Globecom1998.

[27] S. Biazand et.al, “TCP over wireless Networks using multiple acknowledgements”, Tech. report of Texas A&M Univ. 1997.

Wireless TCP

TCP 가속 기술 비교

36

Categories Split ConnectionEnd-to-End

ConnectionLocalization

Explicit

Notification

Distinction Between

Congestion and Link

Error

Supported Supported Supported Supported

Deployment Easy Difficult Easy Difficult

End-to-End

Semantic Not Maintained Maintained Maintained Maintained

Very long RTT

(Satellite

Communication)

Supported Supported Not supported Not supported

PEP 적합 PEP 적합

Wireless TCP

Open Source (PEPsal) [5] The open source TCP splitting solution for the GNU/Linux

operating systems

TCP Splitting connection

• Enhanced TCP : TCP Hybla 적용

37

사용자 PC( 도우 기반)Iperf client

PEP client(리 스 기반)PEPsal client

DummyNet(리 스기반)

PEP Server(리 스 기반)PEPsal client

사용자 PC( 도우 기반)

Iperf 서버

Standard TCPEnhanced TCPPEPsal의 경우

TCP Hybla 사용

Standard TCP

[5] C. Caini, et al.,"PEPsal: A Performance Enhancing Proxy for TCP Satellite Connections",IEEE Aerospace and Electronic

Systems Magazine, 2007.

Wireless TCP

성능 분석 모델 (아주대) [28] Splitting connection

Localization (TCP Snoop)

38

TCP Sender TCP ReceiverPEP PEP

Satellite LinkWired Link Wired Link

Conventional TCP Conventional TCPModified TCP for satellite network

<Splitting connection>

TCP Sender TCP ReceiverPEP

Satellite LinkWired Link Wired Link

Conventional TCP<Localization>

[28] 노홍준,고광춘,이규환,김재현,임재성,송예진, "차기군위성통신체계를위한자원할당및 IP 네트워킹", 한국통신학회 논문지, 제 38권 11호, 939-954,

2013년 11월

Wireless TCP

성능 분석 모델 (Splitting connection) MCWS(Maximum Congestion Window Size) 증가

위성링크에서발생하는긴전송지연을 MCWS를증가시켜서 TCP 최대네트워크처리율을높임

ICWS(Initial Congestion Window Size) 증가 Timeout이나 Fast Retransmission 발생 시 Congestion Window가 MCWS에 도달 하는 시간이 단축됨

평균 CW 크기가 증가되어 TCP의 평균 네트워크 처리율을 높임

Selective ACK (SACK)

다수의패킷에러정보를 SACK을이용하여전달하여재전송가능

TCP Veno [21]

Congestion에의한패킷손실과무선채널에러에의한패킷손실을차등하여 Congestion Control

• Minimum RTT보다일정수준 (N) 이상의 RTT이면서패킷손실Congestion, 이외의경우무선채널에러

TCP Hybla [22]

RTT가매우긴위성통신에서성능을향상하기위해 reference RTT (RTT0)의기준에맞춰 MCWS 증가및 Congestion Control 파라미터수정

39[21] C. P. Fu and S.C. Liew, “TCP Veno: TCP Enhancement for Transmission Over Wireless Access Networks,” IEEE JSAC 2003.

[22] C. Caini and R. Firrincieli, “TCP Hybla: a TCP enhancment for heterogeneous networks,” International journal of satellite

communication and networking, 2003.

Wireless TCP

성능분석 (Splitting connection)긴 전송 지연과 패킷 손실에 의한 성능저하를 극복 가능

40

10-5

10-4

10-3

10-2

10-1

0

5

10

15x 10

5


TC

P T

hro

ug

hp

ut

(bit

s/se

c)

TCP

LICW

LICW & SACK

LMCW

TCP Hybla

TCP Veno

LICW: Large Initial Congestion Window

LMCW: Large Maximum Congestion Window

시뮬레이션 환경• Metric: 위성 링크로 연결된소스 노드와 목적 노드 사이의 TCP Throughput 측정

• Segment size: 1500bytes• RTT: 500ms• LMCW: 90 kbytes• LICW:45 kbytes• RTT0(TCP Hybla): 350ms

Wireless TCP

성능분석 (Splitting connection)

41

기술 특징 Trade-off Factor

Large MCWS • 긴 RTT에 의해 TCP Throughput이 낮아지는현상을 극복 가능

• PER이 일정 수준 높아지면 기존 TCP와 비슷한 성능을 나타냄

• MCWS값이 증가할수록 PEP에서 최대 지원할 수 있는session 수 감소

Large ICWS • PER에 의해서 TCP Throughput이 낮아지는 현상 완화 가능

• ICWS값이 증가할수록 TCP의congestion control성능 저하

SACK • 기존 TCP에서는 PER이 높아지면 평균 CW크기도 줄어들기 때문에 큰 효과가 없음

• PER이 높은 환경에서도 ICWS 증가 등으로 평균 CW 크기가 증가하면 효과 상승

TCP-Veno • 무선 패킷 손실에 의한 TCP 성능 저하 완화

TCP-Hybla • 긴 RTT 및 무선 패킷 손실에 의한 TCP 성능저하 극복 가능

• 다수의 session이 존재할 때,RTT0값이 감소할수록congestion 발생할 확률이 증가

Wireless TCP

성능분석 (TCP Snoop)성능향상이 미미함

위성링크의 긴 전송지연 때문에 PEP에서 빠른 재전송이 거의 무의미함

Snooping 기법은 유선링크에서 전송 지연 길고 무선 링크에서 전송 지연이 짧은 환경에 적합함

4210

-510

-410

-310

-210

-10

2

4

6

8

10

12x 10

5


Th

rou

gh

pu

t (b

its/

sec)

TCP

TCP with Snoop

Header Compression (1/5)

Van Jacobson의 알고리즘[29] 이전에 전송한 TCP/IP 헤더에서변화한 부분만 전송 무손실 링크 단(유선 망)에서만적용 가능

Perkins 알고리즘 [30] Frame 의 첫번에 전송한 TCP/IP헤더에서 변화한 부분만 전송 손실 있는 링크단 (무선 망) 고려

CRTP [31] Van Jacobson 알고리즘 기반

Twice 알고리즘을 사용하여 헤더 에러 복구 가능 Sequence number 와 UDP

checksum 사용

43

[29] V. Jacobson, "Compressing TCP/IP Headers", RFC 1144, 1990.

[30] S. J. Perkins et al.,"Dependency Removal for Transport Protocol Header Compression over Noisy Channels," in Proc. IEEE ICC 1997, 1997

[31] S. Casner et al., "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC2508, 1999.

<Van jacobson 알고리즘>

<Perkins 알고리즘>

Frame

CRTP: Compressed Real-time Transport Protocol


Robust Header Compression (ROHC) [32] Introduced RFC3095 and RFC 4815 Increase channel efficiency by reducing overhead Robust at unreliable link

Three different mode : Unidirectional mode(U-mode), Bidirectional Optimistic mode(O-mode), and Bidirectional Reliable mode(R-mode)

Compression example VoIP (in the active period)

• payload 5,11~32 bytes ([email protected]~12.2kbps)+ header 40/60 bytes (RTP 12+UDP 8+IPv4 20/IPv6 40) payload 32 bytes + header 4~6 bytes

44

Wireless Link

Payload RTP UDP IP

Compressor

De-Compressor

Framing/Error Detection

RoHC Context

Payload H

Compressed

Header

RoHC Context

PayloadIP RTP UDP

Compressor

De-Compressor

Framing/Error Detection

Sender Receiver

[32] G. Pelletier et al., "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite ",

RFC5225, 2008.


Header Fields Classification

45

Type Description

Inferred” They are never sent and they can

be known by other component in

the header

Static* Send only once, their values

never change during the stream

Static-

def**

Send only once, they give the

definition of the stream

Static-

known^

They are never sent and their

values are known

Changing< Header fields with a changing

value. The change can be

periodic or randomly. They are

always send

Ver

*ToS< Flow ID**

Length”Next

Header*Hop Limit<

Source Address**

Destination Address**

Source Port** Destination Port**

Length” Checksum<

Ver^ P* E* CCnt< M< P.Type< Sequence Number<

Timestamp<

Source Synchronization Indentification(SSRC)**

Source Contribution Identification (1st)<

Contributing source (CSRC)<

Source Contribution Identification (last)<

Application Data

0 15 31

IPv6

UDP

RTP


Header Fields Classification

46

Type Description

Inferred” They are never sent and they can

be known by other component in

the header

Static* Send only once, their values

never change during the stream

Static-

def**

Send only once, they give the

definition of the stream

Static-

known^

They are never sent and their

values are known

Changing< Header fields with a changing

value. The change can be

periodic or randomly. They are

always send

Static Info

ROHC header

Application Data

1 byte

3~5 bytes


ROHC compression with U,O,R operation mode

47

관련 연구 수행 내용 (NC-PEP)

NC-PEP [33]목적

패킷 전달 신뢰성을 향상하고 기존의 전송 제어 프로토콜과 호환되어동작하는 네트워크 코딩이 적용된 PEP 기술을 제안

• PEP에서 랜덤 선형 네트워크 코딩 (RLNC: Random Linear Network Coding)을 이용하여 TCP 세그먼트에서 Redundancy 세그먼트를 생성하여 전송

48

유선링크 유선링크위성링크

TCP 발신자

TCP 수신자

NC-PEP(발신자측)

NC-PEP(수신자측)

Figure: 제안하는프로토콜의시스템모델

[33] 이규환, 김재현 "위성통신에서신뢰성향상을위한랜덤선형네트워크코딩기술," 한국통신학회논문지, 제 38권 B호, pp.700-706, 2013년 9

월.


동작과정

49

Figure: 제안하는프로토콜의동작과정

RLNC 묶음

RTT

TCP 발신자

TCP 수신자

NC-PEP(발신자측)

NC-PEP(수신자측)

네이티브 세그먼트NC-R 세그먼트

•네이티브세그먼트 가공되지않은순수한 TCP세그먼트

• Network-coded redundancy(NC-R)) 세그먼트 RLNC를이용하여네이티브세그먼트로부터생성 NC-PEP에서 위성 링크에서 신뢰성을 향상하기 위하여 추가적으로전송

• B and R

B는 RLNC묶음의크기 R은 RLNC묶음으로부터생성하는 NC-R세그먼트의수

•발신측 NC-PEP

네이티브세그먼트를수신측 NC-PEP에전달 RLNC 묶음에 해당하는 네이티브 세그먼트들에서 RLNC를이용하여 NC-R 세그먼트를 생성하여 수신 측 NC-PEP에 전송

•수신측 NC-PEP

네이티브세그먼트를 TCP수신자에게전달 네이티브세그먼트가위성링크에서손실되면 NC-PEP는 NC-

R 세그먼트의 수신을 기다렸다가 RLNC를 이용하여 손실 된세그먼트를복구


성능 평가 Segment 손실률, TCP 처리율

NC-R 세그먼트 전송으로 네이티브 세그먼트 손실률이 낮아지고, 그에의해 TCP 처리율이 향상됨

50

0 0.05 0.1 0.15 0.2 0.250

20

40

60

80

100

Segment loss rate (p)

TN

C

TCP Reno

NC-PEP(B = 6, RF = 3)

NC-PEP(B = 12, RF = 6)

NC-PEP(B = 12, RF = 3)

0 0.05 0.1 0.15 0.2 0.250

0.05

0.1

0.15

0.2

0.25

Segment loss rate(p)

pN

C

TCP Reno

NC-PEP (B = 6, RF = 3)

NC-PEP (B = 12, RF = 6)

NC-PEP (B = 12, RF = 3)

/RF R B<네이티브세그먼트손실률> <TCP 처리율>

B: RLNC 의묶음개수R: redundancy packet 수

Approach in Network LayerRouting

51

군 위성 연동망 구조 및 특징

위성/타체계 연동망 참조망 구조(1/2)

52

타체계연동

육군작전사령부 공군작전사령부 해군작전사령부

합참

TICN

Link-16

Link-11

위성망

군단

함대사

타체계: TICN, Link-16, Link-11, 각 군의 지휘통제체계 및 정보처리시스템 (ex.

KJCCS, MIMS, KNCCS, KNTDS, AFCCS, MCRC, etc.), C4I 체계

iBGP (AS 내부)

위성망관리구조

위성링크

eBGP (AS↔AS)

OSPF

BGP

비행단

군 위성 연동망 구조 및 특징

위성/타체계 연동망 참조망 구조(2/2)운용국(합참) 중심의 Hub/Spoke 구조

53

운용국(합참)

분산망

통합망

Hub분산망 Hub

Hub/Spoke

분산망

망관리/제어

트래픽

군 위성 연동망 운용 방안

네트워크 계층 관련 연구 이슈차기 위성망 및 연동망 구조 상위 설계

타체계 특성 및 상호운용성에 대한 고찰 필

위성망 IP 주소 체계 연구

타체계와 연동 및 경로선택 용이한 주소체계

망 내 가입자 수 증가에 따른 효율적 주소 할

Broadcast, Multicast 등에 따른 IP 주소 할

위성 연동망 라우팅 프로토콜 적용 방안

이동성 보장을 위한 Dynamic 라우팅 적용

라우팅 프로토콜 Cost Metric 설정

위성 운용 방안(Load balancing, Back-up link)에 따른 Cost metric 사용 방안

54

연구 이슈

경로 정보 유지 및 업데이트단말 간 연결 유지를 위한 라우팅 제어 메시지 전송

단말의 이동에 따른 동적 경로 정보 업데이트 메시지 전송

55

- Case 1: 주기적인 제어 메시지 전송 OSPF: Hello 메시지 (44bytes)

BGP: Keepalive 메시지 (19bytes)

- Case 2: 단말의 이동 및 채널 state 변경 OSPF: LSU 메시지

OSPF 메시지 역할

Hello-인 라우터와의링크연결상태확인-주기적으로교환: Default 10초

Data Description- AS 또는 area에대한구조정보제공- Master device에의해 slave device에전달

Link State Request (LSR) - Link state 정보를업데이트

Link State Update (LSU) - Link state에대한정보제공

Link State

Acknowledgement (LSA)- LSU의수신에대한 ACK

BGP 메시지 종류

Open- BGP 라우터간 TCP 연결을설정하기위한파라미터전송

Keepalive- BGP 연결유지-주기적으로교환: Default 60초

Update- BGP 라우터간오류발생시, 오류원인전달

Notification -라우팅정보전송

<OSPF 제어메시지종류 [34]> <BGP 제어메시지종류 [35]>

[34] J. Moy, “OSPF Version 2,” RFC 2328, Apr. 1998.

[35] Y. Rekhter, T. Li, and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” RFC 1771, Jan. 2006.

연구 이슈

단말 이동성에 따른 경로 정보 업데이트 및 IP 주소 할당경로 정보 관리를 위한 제어 메시지 교환 (아주대)

56

성능분석환경

채널모델: AWGN

변조방식: 4-QAM, 16-QAM, 64QAM, 256QAM

Hello packet size: 44bytes (최소크기)*

Hello packet 전송주기: 10초

Hello packet 최대전송횟수: 4회

군단내라우터수: 200 대

0 5 10 15 20 25 3010

15

20

25

30

35

40

Eb/No (dB)

Am

ou

nt

of

ex

ch

an

ge

d H

ell

o p

ac

ke

ts (

MB

)

M=4

M=16

M=64

M=256

•나쁜채널환경: 35MB

•좋은채널환경: 14MB

제어 메시지 교환 양 (10초)

• 제어 메시지 전송량 감소

• 위성 링크 자원 할당 방안

연구 이슈


연구이슈

연구 이슈 별 성능 향상 예상 지표라우팅 제어 메시지 감소 방안 연구

제어 메시지 발생량

경로 정보 신뢰성

라우팅 제어 메시지 전송을 위한 위성 채널 자원 할

Channel utilization

전송 신뢰성

유효 경로 유지 방안 연구

경로 정보 신뢰성

57

Summary

58

Summary

59

Application layer필 기술 (Optional) : 데이터 압축, 데이터 캐싱

Transport layer필 기술 (Mandatory) : TCP 최적화, 헤더 압축

Network layer필 기술 (Mandatory) : 라우팅 제어 메시지 최적화

Thank you !

Q & A

60

References

[1] J. Border et al., "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, 2001.

[2] H. Balakrishnan et al., "TCP Performance Implications of Network Path Asymmetry", RFC 3449, 2002.

[3] SPACE COMMUNICATIONS PROTOCOL SPECIFICATION (SCPS)—TRANSPORT PROTOCOL(SCPS-TP), CCSDS 714.0-B-2, 2006.

[4] Digital Video Broadcasting (DVB); Second Generation DVB Interactive Satellite System (DVB-RCS2);Part 3: Higher Layers Satellite Specification, ETSI TS 101 545-3 2012.

[5] C. Caini, et al.,"PEPsal: A Performance Enhancing Proxy for TCP Satellite Connections",IEEE Aerospace and Electronic Systems Magazine, 2007.

[6] P. Davern et al.,"HTTPEP: a HTTP Performance Enhancing Proxy for Satellite Systems",International Journal of Next-Generation Computing, 2011.

[7] Riverbed SDR, http://aramidesign.com/portfolio/flash/riverbed/flashDemo.swf

[8] Riverbed WAN Optimizer Performance, http://www.riverbed.com/assets/media/documents/briefs/PerformanceBrief-Riverbed-Solidworks.pdf

[9] Juniper Network MSR, http://forums.juniper.net/jnet/attachments/jnet/wx/19/1/analyzing_msr_techbrief.pdf

[10] OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS, CCSDS 130.0-G-2, 2007.

[11] SPACE COMMUNICATIONS PROTOCOL SPECIFICATION (SCPS)-TRANSPORT PROTOCOL(SCPS-TP), CCSDS 714.0-B-2, 2006.

[12] L. Brakmo, S. O’Malley, and L. Peterson, “TCP Vegas: New Techniques for Congestion Detection and Avoidance,” ACM SIGCOMM, 1994

[13] V. Jacobson et al., "TCP Extensions for High Performance", RFC 1323, 1992.

[14] K. Ramakrishnan et al.,"The Addition of Explicit Congestion Notification (ECN) to IP" RFC 3168, 2001

[15] B. Sardar and D. Saha, "A survey of tcp enhancements for last-hop wireless networks," Communications Surveys & Tutorials, IEEE, vol. 8, pp. 20-34, 2006.

[16] A. Bakreand B. Badrinath, “I-TCP: Indirect TCP for Mobile Hosts,” IEEE ICDCS 1995.

[17] K. Brown, S.Singh, “M-TCP: TCP for Mobile Cellular Networks,” ACM Comp. Commun. Rev., 1997.

[18] I. F. Akyildiz, et al., "TCP-Peach: a new congestion control scheme for satellite IP networks,” IEEE/ACM Transactions on Networking, vol. 9, pp. 307-321, 2001.

[19] M. Gerlaet al., “TCP Westwood: Congestion Window Control Using Bandwidth Estimation,” IEEE GLOBECOM 2001

[20]E. H. K. Wu and M. Z. Chen, “JTCP: Jitter-Based TCP for Heterogeneous Wireless Networks,” IEEE JSAC 2004.

61

References

[21] C. P. Fu and S.C. Liew, “TCP Veno: TCP Enhancement for Transmission Over Wireless Access Networks,” IEEE JSAC 2003.

[22] C. Caini and R. Firrincieli, “TCP Hybla: a TCP enhancement for heterogeneous networks,” International journal of satellite communication and networking, 2003.

[23] B. S. Bakshiet al., “Improving Performance of TCP over Wireless Networks,” ICDCS, 1997.

[24] N. Vaidyaand M. Mehta, “Delayed Duplicate Acknowledgments: A TCP-Unaware Approach to Improve Performance of TCP over Wireless,” Texas A&M University, Tech. Report, 1999.

[25] S. Vangalaand M. Labrador, “The TCP SACK-Aware-Snoop Protocol for TCP over Wireless Networks,” IEEE VTC 2003.

[26] Hari Balakrishnan and Randy H. Katz, “Explicit Loss Notification and Wireless Web Performance”, IEEE Globecom1998.

[27] S. Biazand et.al, “TCP over wireless Networks using multiple acknowledgements”, Tech. report of Texas A&M Univ. 1997.

[28] 노홍준,고광춘,이규환,김재현,임재성,송예진, "차기 군 위성통신 체계를 위한 자원 할당 및 IP 네트워킹", 한국통신학회 논문지, 제38권 11호, 939-954, 2013년 11월

[29] V. Jacobson, "Compressing TCP/IP Headers", RFC 1144, 1990.

[30] S. J. Perkins et al.,"Dependency Removal for Transport Protocol Header Compression over Noisy Channels," in Proc. IEEE ICC 1997, 1997

[31] S. Casner et al., "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC2508, 1999.

[32] G. Pelletier et al., "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite ", RFC5225, 2008.

[33] 이규환, 김재현 "위성 통신에서 신뢰성 향상을 위한 랜덤 선형 네트워크 코딩 기술," 한국통신학회논문지, 제 38권 B호, pp.700-706, 2013년 9월.


[35] Y. Rekhter, T. Li, and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” RFC 1771, Jan. 2006.

62

performance enhancing proxy for satellite...

Documents