Protocol Tracing in GPRS

Andrei Gurtov

6.03.2003Workshop on Internet Access over 2.5G3G Networks

Barcelona, Spain

2/21

Outline

Delay spikes in GPRS and their effect on TCPMulti-layer protocol tracing in GPRSTCP and TFRC during intersystem (vertical) handovers

3/21

Delay Spikes in GPRS during Handovers

A. Gurtov, Effect of Delays on TCP Performance, In Proceedings of IFIP Personal Wireless Communications (PWC'01), August 2001.

A. Gurtov, Making TCP Robust Against Delay Spikes, University of Helsinki, Department of Computer Science, No C-2001-53, November 2001.

4/21

Delay Spikes in GPRS during Handovers

02

468

10

1214

0 50 100 150 200 250 300 350

Ping sequence number

RTT

, sec

onds

5/21

Effect of Delay Spikes on TCP -R.Ludwig

• Delay spikes cause spurious

timeouts in TCP

• Unnecessary go-back-N

retransmissions

• Too aggressive congestion

control in short run,

underutilization in long run

• The Eifel algorithm detects a

spurious timeout and responds by

preventing go-back-N and CC 35000

40000

45000

50000

55000

41 46 51 56 61 66Time of Day (s)

Sequ

ence

Num

ber

Snd_DataSnd_AckRcv_DataRcv_Ackhiccup

(3)

(1)

(2)

TCP

TCP+Eifel

6/21

Papers on the Eifel Algorithm

• R. Ludwig and R. H. Katz. The Eifel algorithm: Making TCP robust against spurious retransmissions. ACM CCR 30(1), January 2000

• A. Gurtov, R. Ludwig, Responding to Spurious Timeouts in TCP, IEEE INFOCOM'03.

• A. Gurtov, R. Ludwig, Evaluating the Eifel Algorithm for TCP in a GPRS network, In Proceedings of European Wireless, February 2002.

7/21

IETF Documents on TCP Enhancements

H. Inamura, G. Montenegro, R. Ludwig, A. Gurtov, F. Khafizov, TCP over Second (2.5G) and Third (3G) Generation Wireless Networks, RFC3481.

R. Ludwig, A. Gurtov, The Eifel Response Algorithm for TCP, draft-ietf-tsvwg-tcp-eifel-response-03.txt , work in progress.

A. Gurtov, On Treating DUPACKs in TCP, draft-gurtov-tsvwg-tcp-delay-spikes-01.txt, work in progress.

8/21

Multi-Layer Tracing in GPRS

A. Gurtov, M. Passoja, O. Aalto, M. Raitola, Multi-Layer Protocol Tracing in a GPRS Network, In Proceedings of IEEE Vehicular Technology Conference (VTC'02), September 2002.

J. Korhonen, O. Aalto, A. Gurtov, H. Laamanen, Measured Performance of GSM HSCSD and GPRS, In Proceedings of the IEEE International Conference on Communications (ICC'01), June 2001.

9/21

Multi-Layer Tracing in GPRS

Stationary/mobile measurements in test/live networks=>Compare to earlier results presented in ICC´01=>Find out any remaining inefficienciesEnd-to-end TCP tracing (tcpdump)=>Throughput, RTT, goodput, network buffers, delaysLLC tracing at Gb interface (NetHawk)=>Fragmentation, mobility signallingRLC tracing at Abis interface (NetHawk)=>Retransmissions, radio channel allocation

10/21

Testbed

Abis

Abis

Mobile client tcpdump

BSC

Firewall

Fixed servertcpdump

BTS SGSNGGSN

BTS

BSC

Gb

Nethawk

11/21

Stationary TCP Throughput is Optimal

0

10

20

30

40

50

60

T 3 9 m R 5 2 0 m N 8 3 10 T 2 8 0

Thro

ughp

ut, k

pbs

M IN M A X A V G 9 0 % T C P M A X Line ra t e

0

10

20

30

40

50

60

T39m R520m N8310 T280

Thro

ughp

ut, k

pbs

MIN MAX AVG 90% TCP MAX Line rate

Downlink

Uplink

Very little space for TCPimprovements (perhaps header compression?)

12/21

Buffering of User Data in GPRS

Networks use huge drop-tail buffers of 50-150 KB=>’the more the better’ buffering approach in telecom?Terminals use buffers of 3KB-32KBProblems with too large buffer=>Large RTT (> 10 sec)=>Significant losses during routing area updates=>Delivering unnecessary data after aborting transfersProblems with too small buffers=>High loss rate reduces throughputOptimal buffer size is about 10 KB (2*bandwidth*delay)

13/21

Fast Reset for TCP

When the user clicks from a web page to another, TCP connections

from the old page are aborted

Buffered packets in the network are delivered unnecessary

TCP receiver generates RST for packets on aborted conn.

The idea of ’Fast Reset’

• Look for RST packets in the bottleneck buffer

• Delete packets that belong to aborted connections in other direction

Seems to provide substantial efficiency savings (e.g. 100%) without

affecting robustness

Seems to works for all applications using TCP, not just Web

14/21

Major Findings from Tracing

Packets have to wait for channel (TBF) allocation 80-200 ms• Extended TBF release [Wiemann et al, Ericsson]

Unnecessary retransmissions at the RLC layer• Control RLC SACK frequency and introduce a guard timer [Walke]

Inefficient fragmentation of TCP segments into LLC frames• Set larger frame size

Tracing of cell reselections: duration, frequency & loss• Duration 3-6s; most packets get lost in downlink, few in uplink

GPRS performance got better in two years of time• More stability, higher throughput, lower RTT

15/21

RLC Trace of Bulk TCP Transfer

0

20

40

60

80

100

120

5.0 5.5 6.0 6.5 7.0 7.5 8.0 8.5 9.0 9.5 10.0 10.5 11.0 11.5 12.0Time, s

RLC

sequ

ence

num

ber

DL RLC data block

DL RLC ACK

UL RLC data block

Uplink Channel Assignment

UL Channel Request

TCP ACKs

TBF alloc. delay 200ms

TBF upkeeping

Unnecessary RLCretransmissions

TCP segments

16/21

LLC/TCP Trace of Cell Reselection

0

50

100

150

200

250

300

350

80 85 90 95 100 105 110 115 120 125 130

Time, s

LLC

fram

e nu

mbe

r

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

100000

TCP

sent

byt

es

LLC snd_data

TCP snd_data

TCP snd_ack

Cell reselections

TCP recovers with timeout and slow start

TCP recovers with fast retransmit (and spurious timeout)

17/21

Summary of Tracing Results

Max throughput in downlink 43 kbps, in uplink 21 kbps Unloaded RTT 0.6-0.8 s, under load 5-10 sIn general, smaller network buffers are neededExtended channel (TBF) release reduces RTTRLC fixes to avoid unnecessary data retransmissionsLarge frame size in UNACK LLC mode to avoid

inefficient fragmentation of TCP/IP packetsCell reselections are the main problem=>take 3-15 s, occur every minute while driving in a city=>cause packet losses in downlink, but rarely in uplink

18/21

Ongoing Work: Vertical Handovers

Handovers between GPRS, UMTS, WLAN, LANVertical handovers cause up to two orders of magnitude

change in link characteristics Trigger error losses, delay spikes, reordering and

duplicationSlowly-responsive congestion control (TFRC) provides

smooth rates for streamingHow TCP and TFRC behave and share bandwidth in

presence of vertical handovers?

19/21

Ongoing Work: Vertical Handovers

Mobile IP testbed with GPRS, UMTS, WLAN, LANTraces of TCP and TFRC over intersystem handoversFindings:

• TFRC is not always fair towards TCP

• ACK compression affects TFRC smoothness

• TFRC gets over 200 packets in network when 3 is enough

• As expected, TFRC overshoots and underutilizes bandwidth

during vertical handovers

20/21

Ongoing Work: Vertical Handovers

Continue experiments using an NS2 model of ideal handover

Concentrate on fundamental changes in link characteristics, not on avoidable disruptions such as delays

Two enhancement mechanisms are evaluated: overbuffering and an explicit handover notification

A Fast Reset algorithm is proposed to make overbuffering more feasible

21/21

Thank you!

More information on http://www.cs.helsinki.fi/~gurtov