IETF Working Group

24
IETF WG Presentati on 1 Beth Johnson TCP over Satellite (tcpsat)

description

IETF Working Group. CSCI 344 Spring 1998. Presentation. Beth Johnson TCP over Satellite (tcpsat). TCP over Satellite. ( tcpsat). General Description. GOAL - To create an informational RFC describing the issues affecting TCP throughput over satellite links. ISSUES: - PowerPoint PPT Presentation

Transcript of IETF Working Group

Page 1: IETF Working Group

IETF WG Presentation 1

Beth Johnson

TCP over Satellite (tcpsat)

Page 2: IETF Working Group

TCP over Satellite

( tcpsat)

Page 3: IETF Working Group

IETF WG Presentation 3

General Description•GOAL - To create an informational RFC

describing the issues affecting TCP throughput over satellite links.

•ISSUES: - domains for each issue - network topology - satellite orbit LEO- ( Low Earth Orbit ) MEO-( Medium Earth Orbit ) GSO-( Geostationary Orbit ) - link rates - fixing protocol - fixing implementation

Page 4: IETF Working Group

IETF WG Presentation 4

Scope of working group•Transport layer issues affecting TCP over Satellite•Existing TCP options•Compliant implementation with known improved performance over satellite links•Recommendations of well understood protocol changes•Identification of protocol changes that are potentially promising

Page 5: IETF Working Group

IETF WG Presentation 5

URL and Mailing ListURLs:

http://www.ieft.org/html.charters/tcpsat-charter.html

http://tcpsat.lerc.nasa.gov/tcpsat/

Mailing List:

General Discussion:[email protected] Subscribe: [email protected] Body: subscribe tcp-over-satellite

Page 6: IETF Working Group

IETF WG Presentation 6

Enhancing TCP over Satellite Channels using Standard Mechanisms

•Satellite channel characteristics have an effect on the way transport protocols (ex. TCP) behave.•When protocols such as TCP perform poorly, channel utilization is low.•Improving TCP in the satellite environment

Page 7: IETF Working Group

IETF WG Presentation 7

Satellite Characteristics

•Delay in the delivery of a message over a satellite link due to finite speed of light and the altitude of communications satellites•Many communications satellites are located at GSO at an altitude of approximately 36,000 km.

-orbit period is the same as Earth’s-ground station can always “see”-one round-trip (RTT) would be about 558 ms

•Other orbits of communications satellites at LEO and MEO

-use constellations of satellites for constant coverage-propagation delay from several milliseconds to 80 ms

Page 8: IETF Working Group

IETF WG Presentation 8

Fundamental Characteristics

•Noise: The strength of a radio signal falls in proportion to the square of the distance traveled.

•Bandwidth: The radio spectrum is a limited natural resource.

- bandwidth available to satellite systems is limited

Page 9: IETF Working Group

IETF WG Presentation 9

Advantages of Satellite

•Natural broadcast capability•Multicast applications•Reach geographically remote areas•Reach mobile users

Page 10: IETF Working Group

IETF WG Presentation 10

Disadvantages of Satellites

•Long feedback loop•Large delay * bandwidth product (DBP)

- defines the amount of data a protocol should have “in flight”

•Transmission errors•Asymmetric use•Variable round trip times•Intermittent connectivity ( in non-GSO)

Page 11: IETF Working Group

IETF WG Presentation 11

Two non-TCP Mechanisms

•Path MTU Discovery: - used to determine the maximum packet size a connection can use on a given network path without being subjected to IP packet fragmentation- disadvantage is that it may cause a long pause before TCP is able to start sending data

•Forward Error Correction (FEC):- should be used to bring the performance of the link to at least

fiber quality

Page 12: IETF Working Group

IETF WG Presentation 12

Standard TCP Mechanisms

•Congestion Control algorithms:- slow start - initializing the congestion

window to one segment waits for corresponding

acknowledgement (ACK)

- congestion avoidance- fast retransmit- fast recovery

Page 13: IETF Working Group

IETF WG Presentation 13

Recommendations for TCP over Satellite

•Path-MTU Discovery•FEC•Fast Retransmit•Fast Recovery•TCP Large Window:

- window scaling- PAWS- RTTM

•TCP SACKS

Page 14: IETF Working Group

IETF WG Presentation 14

Requirements for TCP over Satellite

•Slow Start•Congestion Avoidance

Page 15: IETF Working Group

IETF WG Presentation 15

Ongoing TCP Research Related to Satellites

•Outlines mechanisms that may help the TCP better utilize the bandwidth provided by long-delay satellite environments

Page 16: IETF Working Group

IETF WG Presentation 16

Satellite Architectures

•Asymmetric satellite networks•Satellite link as last hop•Hybrid satellite networks•Point-to-point satellite networks•Point-to-multipoint satellite networks•Multiple satellite hops

Page 17: IETF Working Group

IETF WG Presentation 17

Connection Setup

•TCP uses a three-way handshake to setup a connection between two hosts•T/TCP bypasses the three-way handshake sends data and connection setup information•T/TCP requires changes in the TCP stacks of both the sender and receiver

Page 18: IETF Working Group

IETF WG Presentation 18

Slow Start•used to gradually increase the size of TCP’s sliding window•Larger Initial Window

- initial window be more than a single segment- triggers more ACKs opening window more rapidly- requires changes to the sender TCP stack

•Byte Counting- window increases based on the number of previously unacknowledged bytes ACKed, rather than on the number of ACKs received- leads to slightly larger line-rate bursts of segments

Page 19: IETF Working Group

IETF WG Presentation 19

Slow Start cont.-requires changes to the senders TCP stack

•Terminating Slow Start- use the packet-pai algorithm to determine a more appropriate value

for sstresh- requires changes to the senders TCP stack

Page 20: IETF Working Group

IETF WG Presentation 20

Spoofing•break a TCP connection between a client and a server into two parts:

- client and its gateway router over satellite/wireless link- gateway router and server over Internet/wired link

•gateway breaks incoming TCP connections in two by acting on clients behalf•allows the server to complete the transfer without delays of the satellite•allows the gateway to use more appropriate version of TCP over the satellite hop•requires modifications to the gateway routers

Page 21: IETF Working Group

IETF WG Presentation 21

Multiple Data Connections

•Start transmission uses an effective window of N segments rather than a single segment•Transfer increases the window by Nsegments per RTT rather than one segment•Larger over all window size•Overall window decrease in the face of dropped segments is reduced when using N parallel connections•The use of multiple parallel connections in a shared network, such as the Internet may lead to congestive collapse

Page 22: IETF Working Group

IETF WG Presentation 22

ACK Spacing•Bursts can be spread over time by making a gateway separate ACKs by at least two segments between ACKs•Allow the sender to transmit at the correct rate and thus avoid dropped segments•Implemented at the router

Page 23: IETF Working Group

IETF WG Presentation 23

TCP Header Compression

•Replaces the data in the TCP and IP headers that remains constant, changes slowly, or changes in a predictable manner•The sender first sends a full TCP header including in it a connection number that the sender will use to reference the connection•Receiver stores the full header and uses it as a template, filling in some fields from the limited information contained in later compressed headers•Requires changes at both the sender and receiving ends

Page 24: IETF Working Group

IETF WG Presentation 24

42nd IETF Meeting

• Los Angles, CA

• March 30 - April 3

• TCP over Satellite meets:

Tuesday, March 31

9:00 - 11:15