TCP over ATM over Satellite Research Issues

From: Raj Jain ([email protected])
Date: Sun May 03 1998 - 19:00:22 EDT


Aron/Mark/Vern,

Per our discussion at the December IETF meeting, attached is the draft
text for TCP over ATM over Satellite issues for inclusion in the
research i-d. The text was written by my student Rohit Goyal,
[email protected] and follows a format similar to your current draft.

------------------------------------------------------------------------

1. Satellite-ATM Network Architecture
-------------------------------------

In this section, we briefly overview the basic architecture of a
Satellite-ATM network. We first present a brief overview of the QoS
guarantees in ATM networks. This gives the reader an idea of the kinds
of guarantees that are expected of a satellite-ATM network. We then
describe the various components of the architecture and overview their
functionality.

1.1 Quality of Service in ATM Networks
--------------------------------------

ATM networks carry traffic from multiple service categories, and
support Quality of Service (QoS) requirements for each service
category. The ATM-Forum Traffic Management Specification 4.0 [TM4096]
defines five service categories for ATM networks. Each service
category is defined using a traffic contract and a set of QoS
parameters. The traffic contract is a set of parameters that specify
the characteristics of the source traffic. This defines the
requirements for compliant cells of the connection. The QoS parameters
are negotiated by the source with the network, and are used to define
the expected quality of service provided by the network. For each
service category, the network guarantees the negotiated QoS parameters
if the end system complies with the negotiated traffic contract. For
non-compliant traffic, the network need not maintain the QoS
objective.

The Constant Bit Rate (CBR) service category is defined for traffic
that requires a constant amount of bandwidth, specified by a Peak Cell
Rate (PCR), to be continuously available. The network guarantees that
all cells emitted by the source that conform to this PCR will be
transferred by the network with minimal cell loss, and within fixed
bounds of cell delay and delay variation. The real time Variable Bit
Rate (VBR-rt) class is characterized by PCR, Sustained Cell Rate (SCR)
and a Maximum Burst Size (MBS) in cells that controls the bursty
nature of VBR traffic. The network attempts to deliver cells within
fixed bounds of cell delay and delay variation. Non-real-time VBR
sources are also specified by PCR, SCR and MBS, but are less sensitive
to delay and delay variation than the real time sources. The network
does not specify any delay and delay variation parameters for the
VBR-nrt service.

The Available Bit Rate (ABR) service category is specified by a PCR
and Minimum Cell Rate (MCR) which is guaranteed by the network. The
bandwidth allocated by the network to an ABR connection may vary
during the life of a connection, but may not be less than MCR. ABR
connections use a rate- based closed-loop feedback-control mechanism
for congestion control. The network tries to maintain a low Cell Loss
Ratio by changing the allowed cell rates (ACR) at which a source can
send. The Unspecified Bit Rate (UBR) class is intended for best effort
applications, and this category does not support any service
guarantees. UBR has no built in congestion control mechanisms. The UBR
service manages congestion by efficient buffer management policies in
the switch. A new service called Guaranteed Frame Rate (GFR) is being
introduced at the ATM Forum and the ITU-T. GFR is based on UBR, but
guarantees a minimum rate to connections. The service also recognizes
AAL5 frames, and performs frame level dropping as opposed to cell
level dropping.

In addition, the ITU-T has specified four QoS classes to be used to
deliver network based QoS [I35696]. It is imperative that a broadband
satellite network be able to support the various QoS services
specified by the standards. Most importantly, the network should be
able to support TCP/IP based data applications that constitute the
bulk of Internet traffic. Most of the parameters currently specified
in the standards are relevant only to terrestrial networks. These
values are being re-evaluated for Satellite-ATM networks. For example,
the ITU-T specifies a maximum cell transfer delay of 400 ms for the
ITU Class 1 stringent service [I35696]. This class is expected to
carry CBR traffic for real-time voice communications over
ATM. However, the 400ms maximum delay needs to be reviewed to ensure
that it properly accounts for the propagation delays in geosynchronous
satellite networks. The peak-to-peak cell delay variation of QoS Class
1 is also specified to be a maximum of 3 ms by the ITU-T
[I35696]. This value may be too stringent for many satellite systems.
As a result, the QoS parameters are under careful consideration by
ITU-4B [I4B97] In this context, the ITU-4B preliminary draft
recommendations on transmission of Asynchronous Transfer Mode (ATM)
Traffic via Satellite is in the process of development.

1.2 Architectural Issues
------------------------

A satellite-ATM network can be represented by a ground segment, a
space segment, and a network control center. The ground segment
consists of ATM networks that may be further connected to other legacy
networks. The network control center (NCC) performs various management
and resource allocation functions for the satellite
media. Inter-satellite links (ISL) in the space segment provide
seamless global connectivity to the satellite constellation. The
network allows the transmission of ATM cells over satellite,
multiplexes and demultiplexes ATM cell streams from uplinks and
downlinks, and maintains the QoS objectives of the various connection
types. The satellite-ATM network also includes a satellite-ATM
interface device connecting the ATM network to the satellite
system. The interface device transports ATM cells over the frame based
satellite network, and demultiplexes ATM cells from the satellite
frames. The device typically uses a DAMA technique to obtain media
access to the satellite physical layer. The interface unit is also
responsible for forward error correction techniques to reduce the
error rates of the satellite link. The unit must maintain ATM quality
of service parameters at the entrance to the satellite network. As a
result, it translates the ATM QoS requirements into corresponding
requirements for the satellite network. This interface is thus
responsible for resource allocation, error control, and traffic
control. Details about Satellite-ATM architecture models can be
obtained from [KOTA97, PONZ97, WUPI94].

This architectural model presents several design options for the
satellite and ground network segments. These options include

1. No on-board processing or switching.
2. On-board processing with ground ATM switching.
3. On-board processing and ATM switching.

About 53% of the planned Ka-band satellite networks propose to use
on-board ATM like fast packet switching [PONZ97]. An overview of the
network architectures of some of the proposed systems can be found in
[WUPI94]. In a simple satellite model without on-board processing or
switching, minimal on-board buffering is required. However, if
on-board processing is performed, then on-board buffering is needed to
achieve the multiplexing gains provided by ATM. On-board processing
can be used for resource allocation and media access control
(MAC). MAC options include TDMA, FDMA, and CDMA and can use contention
based, reservation based, or fixed media access control. Demand
Assignment Multiple Access (DAMA) can be used with any of the MAC
options. If on- board processing is not performed, DAMA must be done
by the NCC. On-board DAMA decreases the response time of the media
access policy by half because link access requests need not travel to
the NCC on the ground any more. In addition to media access control,
ABR explicit rate allocation or EFCI control, and UBR/GFR buffer
management can also be performed on-board the satellite. On- board
switching may be used for efficient use of the network by implementing
adaptive routing/switching algorithms. Trade-offs must be made with
respect to the complexity, power and weight requirements for providing
on-board buffering, switching and processing features to the satellite
network. In addition, on-board buffering and switching will introduce
some additional delays within the space segment of the network. For
fast packet or cell switched satellite networks, the switching delay
is negligible compared to the propagation delay, but the buffering
delay can be significant. Buffering also results in delay variations
due to the bursty nature of ATM traffic.

1.2 Satellite-ATM Error Characteristics
----------------------------------------

Inherently, satellite channels produce random single bit errors in the
data being transmitted. The Bit Error Rate (BER) depends on the
Signal-to-Noise ratio at the receiver. Thus, for an acceptable level

of error rate, a certain minimum signal-to-noise ratio must be
maintained at the transmitter. Forward Error Correction (FEC)
techniques provide a solution to counter the high BER in satellite
channels. However, the use of FEC techniques changes the error
characteristics of satellite channels to 'bursty' errors. This change
can adversely affect the operation of ATM, AAL and transport protocols
over the satellite physical layer frames. Studies need to be performed
to analyze the characteristics of TCP/IP over satellite-ATM channels.

2 TCP over ABR
--------------

2.1 Service Overview
--------------------

ABR mechanisms allow the network to divide the available bandwidth
fairly and efficiently among the active traffic sources. In the ABR
traffic management framework, the source end systems limit their data
transmission to rates allowed by the network. The network consists of
switches that use their current load information to calculate the
allowable rates for the sources. These rates are sent to the sources
as feedback via resource management (RM) cells. The ABR traffic
management model is a rate-based end-to-end closed- loop model.

There are three ways for switches to give feedback to the sources.
First, each cell header contains a bit called Explicit Forward
Congestion Indication (EFCI), which can be set by a congested
switch. Such switches are called binary or EFCI switches. Second, RM
cells have two bits in their payload, called the Congestion Indication
(CI) bit and the No Increase (NI) bit, that can be set by congested
switches. Switches that use only this mechanism are called relative
rate marking switches. Third, the RM cells also have another field in
their payload called explicit rate (ER) that can be reduced by
congested switches to any desired value. Such switches are called
Explicit Rate switches. RM cells are generated by the sources and
travel along the data path to the destination end systems. The
destinations simply return the RM cells to the sources.

Explicit rate switches normally wait for the arrival of an RM cell to
give feedback to a source. However, under extreme congestion, they are
allowed to generate an RM cell and send it immediately to the
source. This optional mechanism is called backward explicit congestion
notification (BECN).

At the time of connection setup, ABR sources negotiate several
operating parameters with the network. The first among these is the
peak cell rate (PCR). This is the maximum rate at which the source
will be allowed to transmit on this virtual circuit (VC). The source
can also request a minimum cell rate (MCR) which is the guaranteed
minimum rate. The network has to reserve this bandwidth for the
VC. During the data transmission stage, the rate at which a source is
allowed to send at any particular instant is called the allowed cell
rate (ACR). The ACR is dynamically changed between MCR and PCR. At
the beginning of the connection, and after long idle intervals, ACR is
set to initial cell rate (ICR). A complete list of parameters used in
the ABR mechanism is given in [TM4096] .

ABR switches can use the virtual source/virtual destination (VS/VD)
feature to segment the ABR control loop into smaller loops. In a
VS/VD network, a switch can additionally behave both as a (virtual)
destination end system and as a (virtual) source end system. As a
destination end system, it turns around the RM cells to the sources
from one segment. As a source end system, it generates RM cells for
the next segment. This feature can allow feedback from nearby switches
to reach sources faster, and achieve hop-by-hop control.

2.1 Nature of TCP Traffic at the ATM Layer
------------------------------------------

At the ATM layer, the TCP traffic is considered bursty. Initially,
there is a short active period (the first packet is sent) followed by
a long idle period (nearly one round-trip time, waiting for an
ACK). The length of the active period doubles every round-trip time
and the idle period reduces correspondingly. Finally, the active
period occupies the entire round-trip time and there is no idle
period. After this point, the TCP traffic appears as an infinite (or
persistent) traffic stream at the ATM layer. When sufficient load is
not experienced at the ABR switches, the switch algorithms typically
allocate high rates to the sources. This is likely to be the case when
a new TCP connection starts sending data. The file transfer data is
bottlenecked by the TCP congestion window size and not by the ABR
source rate. In this state, we say that the TCP sources are
window-limited.

The TCP active periods double every round trip time and eventually
load the switches and appear as infinite traffic at the ATM layer. The
switches now give feedback asking sources to reduce their rates. The
TCP congestion window is now large and is increasing. Hence, it will
send data at rate greater than the source's sending rate. The file
transfer data is bottlenecked by the ABR source rate and not by the
TCP congestion window size. In this state, we say that the TCP sources
are rate-limited.

The ABR queues at the switches start increasing when the TCP idle
times are not sufficient to clear the queues built up during the TCP
active times. The queues may increase until the ABR source rates
converge to optimum values. Once the TCP sources are rate-limited and
the rates converge to optimum values, the lengths of the ABR queues at
the switch will start decreasing. If sufficient buffering is available
to hold this transient queue, then TCP achieves maximum possible
throughput.

2.2 TCP Performance over ABR
----------------------------

Cell loss will occur in the network if the ATM switches do not have
sufficient buffers to accommodate this queue buildup. Clearly TCP
achieves maximum throughput over ABR when there is no cell loss. When
cell loss does occur, the cell loss ratio (CLR) metric, which
quantifies cell loss, is a poor indicator of loss in TCP
throughput. This is because TCP loses time (through timeouts) rather
than cells (cell loss). If the ABR rates do not converge to optimum
values before the cell loss occurs, the effect of the switch
congestion scheme may be dominated by factors such as the TCP
retransmission timer granularity. Intelligent cell drop policies at
the switches can help to significantly improve the throughput. This is
further discussed in the TCP over UBR section.

The TCP throughput loss over ABR can be avoided by provisioning
sufficient switch buffers. It has been shown that the buffer
requirement for TCP over ABR is bounded and small [JAIN96]. In
particular, the buffer requirement for zero TCP loss over ABR can be
bounded by a small constant multiple of the product of the round trip
time and bandwidth of the connection. However, note that, even after
ABR sources converges to optimum rates, the TCP congestion window can
grow till it reaches its maximum (negotiated) value. In such cases,
TCP overloads the ABR source and the queues build up at the source end
system. If the source queues overflow cell loss will occur, and
performance will degrade. In this case, the cell loss occurs outside
the ABR network.

3 TCP over UBR
--------------

3.1 Service Overview
--------------------

The Unspecified Bit Rate (UBR) service provided by ATM networks has no
explicit congestion control mechanisms [TM496]. However, it is
expected that many TCP implementations will use the UBR service
category. TCP employs a window based end-to-end congestion control
mechanism to recover from segment loss and avoids congestion collapse.
Several studies have analyzed the performance of TCP over the UBR
service. TCP sources running over UBR with limited network buffers
experience low throughput and high unfairness [FANG95, GOYAL97, LI95,
LI96]

Several design options available to UBR networks and end-systems for
improving performance. Intelligent drop policies at switches can be
used to improve throughput of transport connections. Early Packet
Discard (EPD) [ROMANOV95] has been shown to improve TCP throughput but
not fairness [GOYAL97]. Enhancements that perform intelligent cell
drop policies at the switches need to be developed for UBR to improve
transport layer throughput and fairness. A policy for selective cell
drop based on per-VC buffer management can be used to improve
fairness. Providing guaranteed minimum rate to the UBR traffic has
also been discussed as a possible candidate to improve TCP performance
over UBR.

In addition to network based drop policies, end-to-end flow control
and congestion control policies can be effective in improving TCP
performance over UBR. The fast retransmit and recovery mechanism
[FRR], can be used in addition to slow start and congestion avoidance
to quickly recover from isolated segment losses. The selective
acknowledgments (SACK) option [MATHIS96] has been proposed to recover
quickly from multiple segment losses [FLOYD95]. A change to TCP's
fast retransmit and recovery has also been suggested in [FALL96] and
[HOE96]

2.2 Buffer Management
---------------------

The basic UBR service can be enhanced by implementing intelligent
buffer management policies at the switches. The Early Packet Discard
policy [ROMANOV95] maintains a threshold R, in the switch buffer. When
the buffer occupancy exceeds R, then all new incoming packets are
dropped. Partially received packets are accepted if possible. It has
been shown [GOYAL97] that EPD improves the throughput of TCP over UBR
but can result in unfairness among the TCP connections.

Several schemes have been proposed [GOYAL97, SIU97] that use per-VC
accounting to maintain the current buffer utilization of each UBR
VC. Selective Drop and Fair Buffer Allocation are examples of such
schemes. A fair allocation is calculated for each VC, and if the VC's
buffer occupancy exceeds its fair allocation, its subsequent incoming
packet is dropped. These schemes maintain a threshold R, as a
fraction of the buffer capacity K. When the total buffer occupancy
exceeds R*K, new packets are dropped depending on the VC_i's buffer
occupancy Y_i. In the Selective Drop scheme, a VC's entire packet is
dropped if (X > R) AND (Y_i* N_a / X > Z ) where N_a is the number of
active VCs (VCs with at least one cell the buffer), and Z is another
threshold parameter (0 < Z <= 1) used to scale the effective drop
threshold. The Fair Buffer Allocation scheme is similar to Selective
Drop and uses the following formula: (X > R) AND (Y_i*N_a / X > Z*((K
- R)/(X - R)))

2.3 Guaranteed Rate
-------------------

Providing a rate guarantee to the UBR service category can ensure a
continuous flow of TCP packets in the network. UBR with guaranteed
rate requires no additional signalling requirements or standards
changes, and can be implemented on current switches that support the
UBR service. Guaranteed rate service is intended for applications
that do not need any QoS guarantees, but whose performance depends on
the availability of a continuous amount of bandwidth. The goal of
providing guaranteed rate is to protect the UBR service category from
total bandwidth starvation, and provide a continuous minimum bandwidth
guarantee. In the presence of high load of higher priority Constant
Bit Rate (CBR), Variable Bit Rate (VBR) and Available Bit Rate (ABR)
traffic, TCP congestion control mechanisms are expected to benefit
from a guaranteed minimum rate.

2.4 Guaranteed Frame Rate
-------------------------

Guaranteed Frame Rate (GFR) has been recently proposed in the ATM
Forum as an enhancement to the UBR service category. Guaranteed Frame
Rate will provide a minimum rate guarantee to VCs at the frame
level. The GFR service also allows for the fair usage of any extra
network bandwidth. GFR requires minimum signaling and connection
management functions, and depends on the network's ability to provide
a minimum rate to each VC. GFR is likely to be used by applications
that can neither specify the traffic parameters needed for a VBR VC,
nor have cability for ABR (for rate based feedback control). Current
internetworking applications fall into this category, and are not
designed to run over QoS based networks. These applications could
benefit from a minimum rate guarantee by the network, along with an
opportunity to fairly use any additional bandwidth left over from
higher priority connections. In the case of LANs connected by
Satellite-ATM backbones, network elements outside the ATM network
could also benefit from GFR guarantees. For example, IP routers
separated by a Satellite-ATM network could use GFR VCs to exchange
control messages.

3 References
------------

[TM4096] Shirish S. Sathaye, ``ATM Traffic Management
Specification Version 4.0,'' ATM Forum 95-0013, April 1996.

[I35696] ITU-T Recommencation I.356, ``B-ISDN ATM Layer Cell
Transfer Performance,'' Geneva, October 1996.

[I4B97] ITU-R 4B Preliminary Draft Recommendation, ``Transmission of
Asynchronous Transfer Mode (ATM) via Satellite,'' Geneva, January
1997.

[KOTA97] S. Kota, R. Goyal, R. Jain, ``Satellite ATM Network
Architectural Considerations and TCP/IP Performance'', Proceedings of
the 3rd Ka Band Utilization Converence, Italy, 1997.

[PONZ97] C. Ponzoni, ``High Data Rate On-board Switching,'' 3rd
Ka-band Utilization Conference, Italy, 1997.

[WUPI94] William Wu, Edward Miller, Wilbur Pritchard, Raymond
Pickholtz, ``Mobile Satellite Communications,'' Proceedings of the
IEEE, Vol. 82, No. 9, September 1994.

[FALL96] Kevin Fall, Sally Floyd, ``Simulation-based Comparisons
of Tahoe, Reno, and SACK TCP,'' Computer Communications Review, July 1996

[FANG95] Chien Fang, Arthur Lin, ``On TCP Performance of UBR with EPD
and UBR-EPD with a Fair Buffer Allocation Scheme,'' ATM FORUM 95-1645,
December 1995.

[FLOYD95] Sally Floyd, ``Issues of TCP with SACK,''
Lawrence Berkeley Labs, Technical report, December 1995

[GOYAL97] Rohit Goyal, Raj Jain, Shivkumar Kalyanaraman, Sonia Fahmy,
Bobby Vandalore, ``Improving Performance of TCP over the ATM-UBR
Service,'' To appear in Computer Communications,

http://www.cis.ohio-state.edu/~jain

[HOE96] Janey C. Hoe, ``Improving the Start-up Behavior of a
Congestion Control Scheme for TCP,'' Proceedings of SIGCOMM'96, August
1996.

[JAIN96] Raj Jain, Shiv Kalyanaraman, R. Goyal, S. Fahmy, ``Buffer
Requirements for TCP over ABR,'' ATM Forum 96-0517, April 1996.

[LI95] Hongqing Li, Kai-Yeung Siu, and Hong-Ti Tzeng, ``TCP over ATM
with ABR service versus UBR+EPD service,'' ATM FORUM 95-0718, June
1995.

[LI96] H. Li, K.Y. Siu, H.T. Tzeng, C. Ikeda and H. Suzuki ``TCP over
ABR and UBR Services in ATM,'' Proc. IPCCC'96, March 1996.

[MATHIS96] M. Mathis, J. Madhavi, S. Floyd, A. Romanow, ``TCP
Selective Acknowledgment Options,'' Internet RFC 2018, October 1996.

[ROMANOV95] Allyn Romanov, Sally Floyd, ``Dynamics of TCP Traffic over
ATM Networks,'' IEEE JSAC, May 1995.

Rohit Goyal
Department of Computer and Information Science
The Ohio State University, 2015 Neil Ave, DL 395
Columbus, OH 43210
Ph: 614 688 4482. Fax: 614 292 2911
Email: [email protected]
URL: www.cis.ohio-state.edu/~goyal



This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:42 EST