–co-existence or modifications to end-to-end protocols · 2008. 1. 15. · tcp • how does tcp...

#8 1

Victor S. FrostDan F. Servey Distinguished Professor

Electrical Engineering and Computer ScienceUniversity of Kansas2335 Irving Hill Dr.

Lawrence, Kansas 66045Phone: (785) 864-4833 FAX:(785) 864-7789

e-mail: [email protected]://www.ittc.ku.edu/

How to cope with last hop impairments?Part 3

End-to-End (TCP) vs ARQ#8

All material copyright 2006Victor S. Frost, All Rights Reserved

#8 2

How to cope with last hop impairments?

• Techniques for coping with multipath fading fading mitigation techniques, e.g., – Equalizers– Diversity– RAKE receivers– OFDM

• Techniques for coping with noise– Forward error detection/correction coding– Automatic Repeat reQuest (ARQ)– Co-existence or modifications to

end-to-end protocols

#8 3

End-to-end vs link error ARQ

• Most user devices use TCP as the transport layer– TCP includes flow control– TCP includes congestion control– TCP includes error recovery

• Initially using a Go-back-N• Newer implementations use a selective reject

– Thus TCP provides ARQ functionality– TCP is an end-to-end protocol

#8 4


• Question? Should access networks rely on:

• TCP or • Last hop ARQ/FEC mechanism or• Hybrids and modifications to TCP

#8 5


• Review TCP and noisy access network, e.g. wireless and powerline, issues

• Discuss merits of– Last hop FEC/ARQ– Enhancements

• Split-Connection• Indirect TCP• Snoop TCP

– Case study

#8 6

TCP

• Some services provided by TCP– Reliable transmission– Flow control– Congestion control – Connection management (not considered

here)

#8 7

TCP

• How does TCP provide services– Estimates RTT– Dynamically changes window size– Sender changes behavior based on its

state and observations– Link layer ARQ can impact TCP

performance

#8 8

TCP Flow control

From: “Computer Networks, 3rd Edition, A.S. Tanenbaum. Prentice Hall, 1996

WIN= receiver_advertised_window

#8 9

TCP

• The TCP sender infers loss of a sent packet if:– The time between the transmission and receipt of an ACK

is > Retransmission Timeout (RTO)– Or of receive duplicate ACK, i.e., if packet i fails but i+1

succeeds then sender does not get an ACK for i but gets a Ack for packet i+1, the sender infers loss of packet i.

– Duplicate ACK maybe received much faster than the RTO.

– Note that losing an ACK has the same impact as losing the packet.

• Cause of lost packet– Congestion– Errors

#8 10

RTO Estimation-Karn’s Algorithm• RTO is calculated based on RTT and RTT deviation• Karn’s algorithm:• Measure the RTT: sampleRtt• Obtain a smoothed RTT from:

– srtt = (1 – g) * srtt + g * sampleRTT• Obtain mean deviation of RTT from:• rtttvar = (1 – h) * rtttvar – h * |sampleRTT – srtt|• Use RTO = srtt + 4 rttvar• Recommended values for g, h• g = 0.125, h = 0.25• Note that a link layer ARQ with significant errors

or a wireless channel in a fade will cause RTO to artificially increase

#8 11

What is Congestion• Buffers at intermediate routers between source

and destination may overflow

Router

R bpsPacket flows from

many sources

• Congestion occurs when total arrival rate from all packet flows exceeds R over a sustained period of time

• Buffers at multiplexer will fill and packets will be lost

Modified from: Leon-Garcia & Widjaja: Communication Networks

#8 12

Phases of Congestion Behavior

1. Light traffic– Arrival Rate << R– Low delay– Can accommodate more

2. Knee (congestion onset)– Arrival rate approaches R – Delay increases rapidly– Throughput begins to

saturate3. Congestion collapse

– Arrival rate > R– Large delays, packet loss– Useful application

throughput drops

Thro

ughp

ut (b

ps)

Del

ay (s

ec)

R

R

Arrival Rate

Arrival Rate


#8 13

Window Congestion Control• Desired operating point: just before

knee– Sources must control their sending rates so

that aggregate arrival rate is just before knee

• Problem: source does not know what its “fair” share of available bandwidth should be


#8 14

TCP-Congestion

• TCP assumes packet loss is due to congestion

• If the network is congested then want to slow the source down to reduce congestion

• When the network congestion disappears then want to allow the source to send faster


#8 15

TCP-Congestion

• TCP uses Additive increase Multiplicative decrease (AIMD) algorithm

• TCP has four phases– Slow start– Congestion avoidance– Fast recovery– Fast retransmit

• The sender maintains two variables– cwnd-congestion window

• In bytes• Controls the number of bytes the sender can transmit

– Allowed_window=min(receiver_ advertised_window, cwnd)• Initial value = 1 Maximum segment size (MSS)

– ssthresh-slow start threshold

#8 16

Congestion Window• At light traffic: each segment is ACKed quickly

– Increase cwnd aggressively• At knee: segment ACKs arrive, but more slowly

– Slow down increase in cwnd• At congestion: segments encounter large delays (so

retransmission timeouts occur); segments are dropped in router buffers (resulting in duplicate ACKs)– Reduce transmission rate, then probe again

• Note this ignores the possibility of loss due to link layer errors


#8 17

TCP Congestion Control: Slow Start• Slow start: increase congestion window size by

one segment upon receiving an ACK from receiver– initialized at ≤ 2 segments– used at (re)start of data transfer– congestion window increases exponentially

ACK

Seg

RTTs124

8

cwnd


#8 18

TCP Congestion Control: Congestion Avoidance

• Algorithm progressively sets a congestion threshold– When cwnd > threshold,

slow down rate at which cwnd is increased

• Increase congestion window size by one segment per round-trip-time (RTT) – Each time an ACK arrives,

cwnd is increased by 1/cwnd– In one RTT, cwnd segments

are sent, so total increase in cwnd is cwnd x 1/cwnd = 1

– cwnd grows linearly with time RTTs12

4

8

cwnd

threshold


#8 19

TCP Congestion Control: Congestion

• Congestion is detected upon timeout or receipt of duplicate ACKs

• Assume current cwndcorresponds to available bandwidth

• Adjust congestion threshold = ½ x current cwnd

• Reset cwnd to 1• Go back to slow-start• Over several cycles expect

to converge to congestion threshold equal to about ½ the available bandwidth

Con

gest

ion

win

dow

10

5

15

20

0

Round-trip times

Slowstart

Congestionavoidance

Time-out

Threshold

#8 20

Fast Retransmit & Fast Recovery

• Congestion causes many segments to be dropped

• If only a single segment is dropped, then subsequent segments trigger duplicate ACKs before timeout

• Can avoid large decrease in cwnd as follows:– When three duplicate ACKs arrive,

retransmit lost segment immediately– Reset congestion threshold to ½ cwnd– Reset cwnd to congestion threshold + 3

to account for the three segments that triggered duplicate ACKs

– Remain in congestion avoidance phase– However if timeout expires, reset cwnd

to 1– In absence of timeouts, cwnd will

oscillate around optimal value

SN=1ACK=2

ACK=2ACK=2ACK=2

SN=2SN=3SN=4SN=5


#8 21

Fast Retransmit & Fast Recovery

From: TCP Packet Control for Wireless Networks, Wan Gang Zeng and LjiljanaTrajković, Communication Networks Laboratory Simon Fraser University

#8 22

TCP and Access Link Layer• Packet losses can be due to:

– Bit errors• Random• Burst from deep fades

– Handoffs due to mobility– Congestion

• Large link layer delays (while in the ARQ process) could cause time outs leading to unnecessary entry into the slow start phase

• Large link layer delay variation (while in the ARQ process) could cause time outs leading to poor RTO estimation

Figure modified from: Hari Balakrishnan, Venkata N. Padmanabhan, SrinivasanSeshan and Randy H. Katz, A Comparison of Mechanisms for Improving TCP Performance over Wireless Links, ACM SIGCOMM ‘96

Upstream

Downstream

#8 23

TCP and Access Link Layer

• Access networks are often asymmetric, downstream slow and up stream fast; delayed acks in the downstream can reduce throughput in the upstream direction

• Acks lost in the upstream can in interpreted as congestion on the downstream

• Asymmetry can also lead to Ack compression,– Suppose there is a packet loss in the upstream, – The upstream node is still receiving from the downstream and

generating Acks– Then Acks are queued waiting for the ARQ to complete– Once completed several Acks are sent back-to-back

(compressed)– Once these are received at the downstream node, a burst of

traffic can be generated.• Possible end-to-end reduction in performance when losses

not due to congestion

#8 24

TCP and Access Link Layer

• Interactions are complex– FEC– ARQ and incremental ARQ– Physical layer effects

• Handoffs• Fading

– Access network packet segmentation– Access network Upstream scheduling

(discussed later)– TCP congestion mechanism

#8 25

• General approaches– Hide losses from TCP– The sender transport layer learns the cause of

the loss• Congestion• No congestion, e.g., bit errors

• Approaches– Rely on link layer to hide losses– Split-connection– End-to-end

Solutions to TCP and Access Link Layer Issues

#8 26

A note on the “end-to-end” principle

• Whenever possible, communications protocol operations should be defined to occur at the end-points of a communications system, or as close as possible to the resource being controlled. (“END-TO-END ARGUMENTS IN SYSTEM DESIGN,” J.H. Saltzer, D.P. Reed and D.D. Clark M.I.T. Laboratory for Computer Science, 1981)

• This has lead to the end-to-end approached, these maintain the end-to-end semantics of TCP.

#8 27

Link layer only

• Hide the losses via– ARQ– FEC– Hybrid ARQ and FEC

#8 28

Link layer only

• Requires no changes in sender protocols• Maintains layered architecture• Many systems implement a link layer ARQ

independent of end devices– GSM– EV-DO– Iridium

• Disadvantage: May lead to protocol interactions

#8 29

Link layer only

• It can work in practice– If the added link layer delay from

retransmissions is small compared to the RTO then the impact of protocol interactions is small*

• Access network RTT small 1 km 3.33us• Link rate ~1 Mb/s small ack tx time• End-to-end RTT large 500 km 500*3.33us

– Frequent error on “slow” wireless link will increase the RTO

– When loss does occur and large RTO then impact can be significant

*Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan Seshanand Randy H. Katz, A Comparison of Mechanisms for Improving TCP Performance over Wireless Links, ACM SIGCOMM ’96

#8 30

Case study

Abdul Jabbar Mohammad, Said Zaghloul*, and Victor S. Frost

Information and Telecommunication Technology CenterElectrical Engineering & Computer Science

[email protected], 785-864-4833

TCP Performance over Multilink PPP in Wireless Networks:

Theory and Field Experiences

#8 31

Outline

• Motivation• Technology• Field Experiments• Analytic Prediction of TCP over

MLPPP with Call Drops

#8 32

Motivation• Polar Radar for Ice Sheet Measurements (PRISM)

– The communication requirements of PRISM field experiments in Greenland and Antarctica

• Data telemetry from the field to the University• Access to University and web resources from field• Public outreach

– Mainstream communication system for polar science expeditions, field camps in Arctic/Antarctic and other research purposes

– Government and security use• Solution:

– Implement a multi-link point-to-point Iridium communication system to combine multiple links to obtain a single logical channel of sufficient aggregate bandwidth.

#8 33

Technologies-Iridium

Intra-planner IS

L

Inter-planner ISL

Intra-planner IS

L

Inter-planner ISL

31.5 Khz with 41.5 Khz guard bandsChannel Bandwidth9-10 minInter-Satellite Handover

FEC 3/4Error Protection2.4 kbpsDigital Voice and Data RateFDMA / TDMAMultiple Access TechniqueSiemens GSM-D900Ground-Based Digital Switches

Ka band: Uplink: 29.1 – 29.3 GHz Downlink: 19.4 – 19.6 GHz

Ground Segment LinksKa band from 23.18 to 23.38 GHzInter Satellite Links FrequencyL-band from 1610 to 1626.5 MHzFrequencyFDMA/TDMAFrame Structure QPSKModulation Technique

31.5 Khz with 41.5 Khz guard bandsChannel Bandwidth9-10 minInter-Satellite Handover

FEC 3/4Error Protection2.4 kbpsDigital Voice and Data RateFDMA / TDMAMultiple Access TechniqueSiemens GSM-D900Ground-Based Digital Switches

Ka band: Uplink: 29.1 – 29.3 GHz Downlink: 19.4 – 19.6 GHz

Ground Segment LinksKa band from 23.18 to 23.38 GHzInter Satellite Links FrequencyL-band from 1610 to 1626.5 MHzFrequencyFDMA/TDMAFrame Structure QPSKModulation Technique

#8 34

Technologies-Protocols

#8 35

Technologies-Multi-Link Point-to-Point Protocol

• Multilink option are negotiated when establishing the connection.

• Packets may be fragmented.

Link 12

ML

PPP

ML

PPPMLPPP PDUs

Layer 3 Packet6

2

SenderReceiver

MLPPP PDUsreassembled

into the original layer 3 packet

MLPPP fragments have non-decreasing sequence

numbers

Network LayerNetwork Layer

MLPPP fragments layer

3 packets

4 5

1 6

3 7

Link 2

Link n

#8 36

Technology- Network Architecture

SUMMIT Camp, Greenland or WAIS camp in Antarctica

ITTC Network, University of Kansas

World Wide Web

User 2

User 3

User 1

ppp0 eth0

PPP Server

ppp0

eth0

PPP Client

P-T-P Satellite link

ITTC Default Router

(Default gateway)(Default

gateway)user 4

user 3

user 2user 1

Camp WI-FI

100 Mbps Ethernet

100 Mbps Ethernet

#8 37

Applications – Uploads and Downloads

Files were downloaded to support the science and operations of the camp. The importance of each file to the user is noted on a subjective scale of 1-10,10 being the most valuable.

82MBUpload for press releaseVideo of core, datasheet8

74.66MBDownload from Orinoco.comAccess point manager software

6

91MBUpload to University of Copenhagen

Drawing of machine spares to order

7

6500KBUpload to Kangerlussauq for press release

Pictures, press release of longest core in Greenland

9

8600KBUploadProposal submission5

9800KBDownloadGPS software4

9226KBDownload from Fairchild.comVoltage regulator data sheet3

7500KBDownload from ITTCMatlab Programs2

97.2MB Download from Agilent.comSpectrum Analyzer programmers Manual

1

ImpSizeDownloaded/uploadedTitle

#8 38

Eight Modem Iridium System: 2004/5 Field Experiments

The Modem/Computer box is a 19” rack mount 5U equivalent The front panel is 8.72’ tall and 19” wide. The sides are 8.34” tall and 24” deep.Weight approximately 45lbs. Reproduction cost= ~$18,000

Iridium

ModemsEthernet

USB

#8 39

Field Experiments – Antenna Setup

4 ft

10 ft

8 Antenna setup at SUMMIT camp in Greenland, July 2004

#8 40

Results – Throughput

Variation of throughput with number of modems

2.49

4.97

6.93

8.98

12.08

13.90

16.43

18.60

02468

101214161820

1 2 3 4 5 6 7 8Number of modems

Thro

ughp

ut (K

bps)

Average throughput efficiency was observed to be 95%

The above results are from the test cases where no call drops were experiencedIn event of call drops the effective throughput of the system will be less than the above values

#8 41

Results – Throughput

13.969:00:0055.23

15.475:15:0035.7

15.623:00:0020.6

14.122:30:0015.52

16.610:46:125.62

14.420:35:423.77

16.530:11:241.38

Effective Throughput in KbpsApprox. Upload TimeSize of file in MBFTP throughput observed during data transfer between the field camp and KU

Average throughput for FTP upload of large files was observed to be 15.38 KbpsDue to call drops, the efficiency was reduced to ~80%

#8 42

Results – Round Trip TimeVariation of RTT

0500

1000150020002500300035004000

1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96Time in sec

RTT

in m

sec

Variation of RTT

0

1000

2000

3000

4000

5000

6000

7000

1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96

Time in sec

RTT

in m

sec

Average RTT = 1.4 sec

Minimum observed RTT = 608 msec

Mean deviation = 800 msec

Round trip time during different times of the day

710608

748

1020820 760

920

1291 1232

1495

1952

14361244

801681

891

1304

995

587

1075930

0

500

1000

1500

2000

2500

8:40 9:02 10:34 11:14 11:45 11:56 12:45Time

RTT

in m

sec

min avg mdev

#8 43

Results – Reliability: 14th July 12-hr test

Uptime %

8995969797979798

Call drop pattern during 8 Iridium – 8 Iridium DAV mode test for 12 hrsPercentage uptime with full capacity (8 channels) is 89% and with at least one modem is 98%Total number of primary call drops during 12 hrs = 4

#8 44

Results – Reliability: 22nd July 32-hr test

Uptime %

8592939394949496

Call drop pattern during 8 Iridium – 8 Iridium DAV mode test for 32 hrs

Percentage uptime with full capacity (8 channels) is 85% and with at least one modem is

96%

Total number of primary call drops during 32 hrs = 24

#8 45

Results – Reliability: 19th July 6-hr test

Uptime %

6781858585858590

Call drop pattern during 8 Iridium – 8 PSTN data mode test for 32 hrs

Percentage uptime with full capacity (8 channels) is 67% and with at least one modem is

90%

Total number of primary call drops during 6 hrs = 9

#8 46

2005 WAIS Field Experiments

WAIS-WestAntarctica Ice Sheet

#8 47

2005 WAIS Field ExperimentsApplications –

Uploads and Download

Files were downloaded to support the science and operations of the camp. The importance of each file to the user is noted on a subjective scale of 1-10,10 being the most valuable.

9VariableRemote ssh access to field programs from KU

7VariableInternet/email access to all field personnel at WAIS camp

10VariableCritical data internet search by the drilling team

950 MBVirtual dashboard application

6VariableVideo conference

10500 KB/dayOutreach pictures, journal and weather data upload

44 MBPICO editor

1010 MBGPS troubleshooting manual

72 MBGIS scripts

510 MBC++ IDE

10500 KBModified code for SAR measurements

92 MBOscilloscope lab measurements

82.2 MBComponent data sheets

ImportanceSizeItem

#8 48

Analytic Prediction of TCP over MLPPP with Call Drops

• A call drop is the event of losing an established connection suddenly

• Connections are automatically re-established• It was observed that a call drop results in TCP

timeouts• Various reasons that might lead to call drops,

– Low signal level– Failure of the inter-satellite handovers

• Goal: Predict the throughput as a function of drop rate and other system parameters

• First step: Call Drop model

#8 49

Call Drops - Distribution• 394 call-drop measurements were

collected in the field • Call drop pdf~exponential• The single link

ICTD is a Poisson random process with a rate β

• A N Link bundle’s ICTD is a Poisson process with a dropping rate of:

λ=N βICTD PDF based on Greenland–Kansas measurements.

Estimated exponential distribution (0.02exp(-0.02t)) passes the chi-square goodness-of-fit test (5% significance level and 14 bins)

#8 50

Call Drops - Distribution• KS-

Greenland call dropping rate per link is 1/50 min-1

• KS-KS call dropping rate per link is 1/52 min-1

#8 51

TCP Performance Model• TCP transfer latency for fs bytes given the MSS

is

• To estimate TCP throughput (B) in packets/sec:a. Evaluate the throughput if no timeouts take place b. Extend the no timeout throughput using the empirical

call drops PDF to include timeouts• Main Assumptions

– Packet losses are due to ARQ failures (no timeouts)– Timeouts are caused by call drops only

(sec)BMSS

fT sd ⎥⎥

⎤⎢⎢⎡=

#8 52

Methodology• Modify exiting results to account for call drops:

J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, “Modeling TCP Reno performance: a simple model and its empirical validation,” IEEE/ACM Trans. Networking, vol. 8, pp. 133-145, Apr. 2000.

• For details of the modification see: Modeling TCP Long File Transfer Latency over Long Delay Wireless Multilink PPP, Said Zaghloul, Victor Frost, Abdul Jabbar Mohammad; IEEE Communications Letters, Vol. 9, No. 11; November 2005, pp. 988-990.

#8 53

Model Validation with Experiential data

File Transfers from Greenland to the University of Kansas (Summer 2004),

T0 = 60s, p = 5E-4, β = 1/50 min-1, MSS = 1448, RTT = 19s, Wmax= 47.9KB

3241875112Predicted Transfer Time (min)341113Error %

3151804611Measured Transfer Time (min)35.720.65.621.38File Size (MB)

3241875112Predicted Transfer Time (min)341113Error %

3151804611Measured Transfer Time (min)35.720.65.621.38File Size (MB)

12.733.215.424.113.498.1Prediction (min)123013211596Measured Time (min)

47.94134.728.322.016.1Wmax (KBytes)1.403.401.391.910.854.82File Size (MBytes)

876543Number of Links

12.733.215.424.113.498.1Prediction (min)123013211596Measured Time (min)

47.94134.728.322.016.1Wmax (KBytes)1.403.401.391.910.854.82File Size (MBytes)

876543Number of Links

#8 54

Increased Dropping Rates

• A software module was built and added to the developed link management software to increase “real” drop rate

• The added module generates call drops according to a Poisson process for any given dropping rate

#8 55

Split connections

• Terminate the TCP connection at the edge between the access network, e.g., wireless and the wired reliable network. Split at:– Access point– Base station

• Over the fixed network– Use standard TCP– Upon Loss assume congestion and backoff

• Over the wireless link can use– Standard TCP– “tuned” wireless TCP (e.g., I-TCP) – Upon loss assume link error and try harder

• Disadvantages– Loss of efficiency due to increased protocol overhead– Violates TCP “end-to-end” principle– Port/Socket complications – Complicates handoff due to state information at the access point or

base station where the protocol is “split”

#8 56

Split connections

TCP TCP*

Logical TCP Connection

SplitConnection

HostHost

AP

* Can be standard or special TCP

From: Professors Luiz DaSilva and Scott Midkiff:Mobile Networks: TCP in Wireless Networks

www.intel.com/education/highered/Wireless/lectures/lecture_11_tcp.ppt

#8 57

Split connections

From: B. Nath,www.cs.rutgers.edu/~rmartin/teaching/fall04/cs552/lectures/wireless.pdf

#8 58

Indirect TCP

WiredNetwork

FixedHost

MobileHost

TCPProxy

Standard TCP

StandardTCP

“Wireless” TCP*

Indirect TCP

(* Normal TCP or modified transport protocol)



#8 59

• Uses a split connection– End-to-end connection

is broken • One connection for the

wired part and • Another connection

for the wireless part– TCP on the access link

can be optimized for the specific environment

– TCP optimization is then placed close to where it is needed

Indirect TCPExample: Cellular Network

FH= Fixed HostMH= Mobile HostMSR = Mobile Support

Router

#8 60

Indirect TCP-Advantages

• Does not require changes to TCP at the hosts in the fixed network

• Errors from the wireless link are corrected at the TCP proxy and, thus, do not propagate through the fixed network

• New protocol affects only a limited part of the Internet

• Optimizations possible over wireless link• Variance in delay between proxy and mobile host

may be small, permitting optimized TCP• Opportunity for header compression, etc.• Opportunity for a different transport protocol



#8 61

Indirect TCP-Disadvantages• Loss of TCP’s end-to-end semantics• What happens if the proxy or the mobile host fails?• Handoff overhead can be significant• Overhead at the proxy for per packet processing, up to TCP

and back down the stack, should not be a major factor as – Increasing processing capabilities – Good design

• TCP proxy must be trusted• Obvious opportunities for snooping and denial of service• End-to-end IP-level privacy and authentication (e.g., using

IPSec) must terminate at the proxy• Split connect approaches have problems with security

Modified From: Professors Luiz DaSilva and Scott Midkiff:Mobile Networks: TCP in Wireless Networks


#8 62

Indirect TCP & Mobile IP

• An access point or router can act as a Mobile IP foreign agent and as the TCP proxy for Indirect TCP (I-TCP)

• If the mobile host moves to a different foreign agent, a handoff is needed for Mobile IP

• If the mobile host moves to a different proxy, a handoff of the full TCP state is needed for I-TCP– Buffered data– Sequence numbers– Port



#8 63

Snoop TCP: Overview• Provide reliable link layer that is TCP aware

– Snoop agent at the access point or foreign agent– Buffers data at the ends of the links for retransmissions

(instead of going back to TCP end points)– “Snoops” on acknowledgements and filters duplicate

acknowledgements

Standard TCP

WiredNetwork

FixedHost

MobileHost

SnoopAgent



#8 64

Snoop TCP: Operation (1)• Snoop agent monitors and buffers data sent from

fixed network to mobile host• Snoop agent monitors ACKs from the mobile host

– Can discard buffer data when acknowledged– Can retransmit data when …

• Delayed ACK, or• Duplicate ACK

– Timeout can be relatively short leading to a fast retransmission

• Snoop Agent discards duplicate ACKs from mobile host



#8 65

Snoop TCP: Operation (2)

• Snoop agent discards duplicate data that has already been sent by the agent and acknowledged

• Snoop agent cannot generate ACKsthat are sent back to the fixed host– Unlike split-connection schemes, Snoop

TCP preserves end-to-end TCP semantics



#8 66

Snoop TCP: Reverse Direction

• Snoop monitors traffic from mobile host back to fixed host and detects missing segments

• A negative ACK (NACK) is sent immediately to the mobile host

• Mobile host can retransmit missing segment, hopefully in time to avoid a TCP timeout at the fixed host



#8 67

Snoop TCP


#8 68

Snoop TCP: Advantages• Preserves end-to-end TCP semantics• Requires no changes in TCP for fixed hosts• No changes in TCP are required for the

mobile hosts, but reverse direction traffic can benefit from changes at mobile host

• On handoff Snoop state is built at new snoop agent

• High efficiency at moderate error rates• Automatic fallback to standard TCP

– No need to ensure that all foreign networks provide a Snoop agent

Modified from: Professors Luiz DaSilva and Scott Midkiff:Mobile Networks: TCP in Wireless Networks


#8 69

Snoop Performance2 Mb/s Wireless link


#8 70

Snoop TCP: Disadvantages• Does not fully isolate wireless link errors

from the fixed network• Mobile host must be modified to handle

NACKs for reverse (mobile to fixed) traffic

• Cannot snoop encrypted datagrams– Cannot use with privacy

• Retransmission of data from agent not authenticated due to protection from replay attacks– Cannot use with authentication



#8 71

End-to-End

• Use SACK (Window 2000 and beyond already use this)

• Explicit Loss Notification (ELN) is a mechanism that identifies the reason for the loss of a packet and communicates to the TCP sender.

• Use the explicit loss notification feature to distinguish between – Congestion losses – Error losses

#8 72

Explicit Loss Notification• Additional information : the receivers MAC layer

is able to detect packet corruption at the wireless link a cross layer mechanism

• Receiver informs the sender about packet corruptions

• The sender may avoid unnecessary window reductions

• The sender and the sequence number of the lost packet must be identified in order to return loss notifications– retrieve sender address and sequence number from the corrupted

packetModified from: Explicit Loss Notification to Improve TCP Performance over Wireless Channels , Gergő Buchholcz, Thomas Ziegler, Tien Van Do www.cost285.itu.edu.tr/tempodoc/TD_285_04_20_Buchholcz.ppt

#8 73

Explicit Loss Notification

• Uses acknowledgements to carry loss information– The sequence number of the corrupted packet

is returned in a new TCP header option field• Acknowledgements are generated when

intact TCP packets are received– When generating a new ACK the latest

notification is excluded while the last is included

– No additional acknowledgements• Reported lost packets are resent

immediatelySee: Explicit Loss Notification to Improve TCP Performance over Wireless Channels , Gergő Buchholcz, Thomas Ziegler, Tien Van Do www.cost285.itu.edu.tr/tempodoc/TD_285_04_20_Buchholcz.ppt

#8 74

0

20

40

60

80

100

120

140

0 2 4 6 8 10 12 14 16 18 20

Packet error rate (%)

Tota

l thr

ough

put (

kbps

)

TCP-ELNTCP-Newreno

Modified from: Explicit Loss Notification to Improve TCP Performance over Wireless Channels , Gergő Buchholcz, Thomas Ziegler, Tien Van Do www.cost285.itu.edu.tr/tempodoc/TD_285_04_20_Buchholcz.ppt

Explicit Loss Notification

#8 75

End-to-End Protocols • Advantages

– Maintains end-to-end semantics of TCP– Introduces no extra overhead at base

stations for protocol processing or handoff

• Disadvantages– Requires modified TCP– May not operate efficiently, e.g., for

packet reordering versus packet loss



#8 76

End-to-EndProactive and Proactive TCP

From: Tian, Y., K. Xu, and N. Ansari, TCP in wireless environments: problems and solutions.IEEE Radio Communications, 2005: p. S27-S32

•TCP Jersey uses •Available Bandwidth Estimation (ABE) •Congestion Warning (CW), implemented using Explicit Eongestion Notification (ECN)

•Proactive TCP’s actively measure network conditions and attempt to distinguish betweencongestive losses and wireless error induced losses

•Packet loss rates < order of 1%

*

*

#8 77

Summary of end-to-end vs link error ARQ

• TCP is a complex protocol– Minimal support from underlying protocols– Indirect observation of network environment– Large number of competing flows from different hosts– Congestion avoidance is still a research issue

• TCP does not perform well in a wireless environment where packets are usually lost due to bit errors, not congestion

• Schemes have been proposed to address TCP performance problems– Link-level recovery– Split protocols– End-to-end protocols



#8 78

References• Leon-Garcia & Widjaja: Communication Networks, McGraw Hill, 2004• “Computer Networks, 3rd Edition, A.S. Tanenbaum. Prentice Hall, 1996• TCP Packet Control for Wireless Networks, Wan Gang Zeng and Ljiljana

Trajković, Communication Networks Laboratory Simon Fraser University• Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan Seshan and Randy H.

Katz, A Comparison of Mechanisms for Improving TCP Performance over Wireless Links, ACM SIGCOMM ’96

• “END-TO-END ARGUMENTS IN SYSTEM DESIGN,” J.H. Saltzer, D.P. Reed and D.D. Clark M.I.T. Laboratory for Computer Science, 1981

• J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, “Modeling TCP Reno performance: a simple model and its empirical validation,” IEEE/ACM Trans. Networking, vol. 8, pp. 133-145, Apr. 2000.

• Modeling TCP Long File Transfer Latency over Long Delay Wireless Multilink PPP, Said Zaghloul, Victor Frost, Abdul Jabbar Mohammad; IEEE Communications Letters, Vol. 9, No. 11; November 2005, pp. 988-990.

• Professors Luiz DaSilva and Scott Midkiff:Mobile Networks: TCP in Wireless Networks www.intel.com/education/highered/Wireless/lectures/lecture_11_tcp.ppt

• B. Nath, www.cs.rutgers.edu/~rmartin/teaching/fall04/cs552/lectures/wireless.pdf

• Explicit Loss Notification to Improve TCP Performance over Wireless Channels , Gergő Buchholcz, Thomas Ziegler, Tien Van Do www.cost285.itu.edu.tr/tempodoc/TD_285_04_20_Buchholcz.ppt

#8 79

References• Abdelmoumen, R., M. Malli, and C. Barakat. Analysis of TCP latency over

wireless links supporting FEC/ARQ-SR for error recovery. in IEEE International Conference on Communications. 2004.

• Andrews, M., Instability of the proportional fair scheduling algorithm for HDR. 2002. p. 14.

• Balakrishnan, H., et al. A comparison of mechanisms for improving TCP performance over wireless links. in ACM Sigcomm August 1996. 1996. Stanford, CA.

• Barakat, C. and E. Altman, Bandwidth Tradeoff between TCP and Link-Level FEC. Computer Networks 2002. 39(2): p. 133-150.

• Bonald, T., Flow-level performance analysis of some opportunistic scheduling algorithms. European transactions on telecommunications 2005. 16(1): p. 65-75.

• Bonald, T. and A. Proutiere, Wireless downlink data channels: user performance and cell dimensioning in Proceedings of the 9th annual international conference on Mobile computing and networking. 2003, ACM Press: San Diego, CA, USA p. 339-352.

• Bonald, T. and A. Proutiere, QoS in multi-service wireless networks • A state of the art, in Design and Engineering of the Next Generation

Internet, towards convergent multi-service networks. 2004, Eurongi -Network of Excellence.

• Borst, S. User-level performance of channel-aware scheduling algorithms in wireless data networks. in Proceedings of IEEE INFOCOM '03. 2003. San Francisco, CA

#8 80

References• Chakravorty, R., et al. Performance optimizations for wireless wide-area networks:

comparative study and experimental evaluation. in Proceedings of the 10th annual international conference on Mobile computing and networking. 2004. Philadelphia, PA: ACM Press New York, NY, USA

• Chatterjee, M., G.D. Mandyam, and S.K. Das. Fast ARQ in high speed downlink packet access for WCDMA systems. in Proceedings in European Wireless Conference. 2002. Florence, Italy.

• Chockalingam, A. and M. Zorzi. Wireless TCP performance with link layer FEC/ARQ. in 1999 IEEE International Conference on Communications. 1999. Vancouver.

• Fattah, H. and C. Leung, An overview of scheduling algorithms in wireless multimedia networks. Wireless Communications, IEEE, 2002. 9(5): p. 76-83.

• Gyasi-Agyei, A. and S.-L. Kim, Cross-layer multiservice opportunistic scheduling for wireless networks. IEEE Communications Magazine, 2006. 44(6): p. 50-57.

• Leung, K.K., et al. Methods to improve TCP throughput in wireless networks with highdelay variability. in Vehicular Technology Conference. 2004.

• Tian, Y., K. Xu, and N. Ansari, TCP in wireless environments: problems and solutions.IEEE Radio Communications, 2005: p. S27-S32.

• Vacirca, F., A. De Vebductis, and A. Baiocchi, Optimal design of hybrid FEC/ARQ schemes for TCP over wireless links with Rayleigh fading. Mobile Computing, IEEE Transactions on, 2006. 5(4): p. 289-302.

• Yan, W., M. Zukerman, and R.J. Harris, PTT packet delay analysis for GPRS/GSM links.Communications Letters, IEEE, 2006. 10(6): p. 456-458.

• Zhang, H., Service Disciplines For Guaranteed Performance Service in Packet-Switching Networks. Proceedings of the IEEE, 1995. 83(10).

• Zhu, J. and S. Roy, Modeling TCP over selective repeat ARQ in wireless networks withnon-negligible propagation delay. IEEE, 2003: p. 1843-1847.

–co-existence or modifications to end-to-end protocols · 2008. 1. 15. · tcp • how does tcp...

Documents