<<

. 43
( 132 .)



>>


5.4.1 Slow start/congestion avoidance
Each sender uses a value called the congestion window to determine how many outstand-
ing bytes it can send that are unacknowledged. This value provides a limit on the total
number of bytes the sender can have in transit at any one time. This is because as soon
as data is acknowledged it must have been received at the far end, and therefore ¬nished
its journey across the network. The initial value of the congestion window is set to a
value less than twice the maximum sender segment size. This algorithm is split into two
phases, slow start and congestion avoidance.
During the slow-start phase, for each segment successfully acknowledged the congestion
window is increased by the maximum sender segment size. Consider that a communication
starts with a congestion window (CW) of 1500 bytes and a maximum segment size (MSS)
of 1500 bytes.
After 1500 bytes are sent and received, the congestion window becomes 3000. This
means the sender can now send two 1500-byte segments and the window will increase
to 6000 bytes (1500 for each segment acknowledged). The sender can now send four
1500-byte segments and the window will increase to 12 000 bytes.
This process continues until the congestion window reaches a value called the slow-
start threshold (SST). This second phase of the algorithm is called congestion avoidance.
Now the congestion window is increased by one maximum sender segment size for each
round trip time (RTT). For many implementations the following formula is used to update
the window for each non-duplicate acknowledgement received:

CW = CW + MSS — MSS/CW

This gives an acceptable approximation to the MSS per RTT. This is because the
difference between the delivery times for each whole congestion window™s worth of data
will approximate to the RTT time, since the next block cannot be sent until this block is
acknowledged.
At any time within the slow-start or congestion avoidance phases, the network may
become congested and a packet will get lost in transit (due to buffer over¬‚ow). The
sender will not receive an acknowledgement, timeout and proceed to retransmit. When this
happens the congestion control algorithm adjusts the congestion window and slow-start
threshold using the following formula:

CW = MSS
SST = MAX (¬‚ight size, MSS/2)
198 IP APPLICATIONS FOR GPRS/UMTS


31500 timeout
30000
28500
27000
25500
24000
22500
threshold
21000 congestion
Congestion window size




19500 avoidance
timeout
18000
congestion
16500 avoidance
15000
threshold
13500
12000
threshold
slow
10500
start
9000
slow
7500 start
6000
4500
3000
1500

2 8
4 6 10 12 18 20 22 24 26
14 16

Transmission number

Figure 5.26 Slow-start/congestion avoidance algorithm


where ¬‚ight size is the current amount of data outstanding in the network (sent but not
received). At this point the slow-start algorithm begins again. Note that the threshold can
be adjusted upwards or downwards depending on the value of ¬‚ight size. Figure 5.26
shows an example of the slow-start/congestion avoidance algorithm in operation.
At the start, the threshold is set to 12 000 and the congestion window is at 1500. In
the ¬rst slow-start phase, for each transmission burst the congestion window doubles in
size until it reaches the threshold of 12 000. At this point the window grows linearly until
transmission number 8, when a timeout occurs due to a packet loss. The threshold is now
set to half the data in ¬‚ight (from 18 000 to 9000), the window is set back to 1500 and
the slow start begins again. This time the window grows until transmission number 26,
where the timeout occurs again and the new threshold is set to 15 000.
One can see that the value of the slow-start threshold is the sender™s approximation of
the maximum value that the congestion window can be set to without causing congestion.
All the time this value is adjusted to re¬‚ect prevailing network conditions.



5.4.2 Fast retransmit/fast recovery (RENO TCP)
If a TCP segment is lost in transmission the receiver will lose part of the stream of
data. All of the following TCP segments cannot be delivered to the high layers until the
5.4 TCP AND CONGESTION CONTROL 199


missing segment is retransmitted. After a while the sender will timeout and then retransmit
the missing segment. The problem with this procedure is that it introduces delay as the
receiver waits for the missing segment.
When a TCP receiver receives a segment out of sequence, it should send an acknowl-
edgement number back to the sender indicating which sequence number is expected next.
This means if a segment is lost, the sender will receive duplicate ACKs for all the seg-
ments sent after the lost one due to the go back N ARQ mechanism regularly employed
by TCP/IP. It is also possible for duplicate ACKs to be sent if segments are reordered
within the network. A sender receiving three duplicate ACKs assumes this is caused by
a lost segment and retransmits the segment indicated by the ACK number. This is called
fast retransmit and serves to repair the loss.
When the missing segment has been acknowledged, instead of using slow start, the
congestion window and threshold are set as follows.
SST = MAX (¬‚ight size, MSS/2)
CW = SST

This procedure is called fast recovery. This is used because the sender receiving dupli-
cate ACKs is an indication that TCP segments are being delivered to the receiver and
therefore congestion has only been indicated for the missing segment.



5.4.3 Drop tail buffer management
In this case the router only drops packets when its buffers are full, where it drops the
incoming packets that cannot be stored in the buffer. This scheme is called drop tail and
has the advantage of being extremely simple as no complexity is needed at the router. It
does, however, have a number of drawbacks. It is possible that a number of transmitters are
increasing their speeds together until a time when they observe that the network becomes
heavily congested. At this point of congestion all of these ¬‚ows could lose packets and
the senders slow down together. This phenomenon, called global synchronization, has
the undesirable effect of reducing overall throughput, since the network load oscillates
from being highly congested to highly under-utilized. Drop tail is also not particularly
fair since ¬‚ows are curtailed regardless of their data rate.



5.4.4 Random early detection (RED)
With RED, the router tries to avoid the congestion before it starts. With this scheme
buffer lengths are monitored on a continuous basis. As the buffer starts to grow and get
nearer its limit, a packet is selected out of the buffer on a random basis for dropping.
The probability of picking a packet for dropping increases as the buffer size increases.
Since the packets are dropped at random from the queue, the chance of a stream having
a packet dropped is in exact proportion to the number of packets it has in the queue.
Faster streams will have more packets in the queue and be dropped ¬rst. RED provides
200 IP APPLICATIONS FOR GPRS/UMTS


a more gentle form of ¬‚ow control and avoids problems such as global synchronization.
It is also somewhat fairer than drop tail since the ¬‚ows that are more responsible for the
congestion are likely to be curtailed ¬rst.



5.5 TCP OPTIMIZATION FOR THE AIR
TCP as a protocol assumes that packet loss is due to congestion within the network. This
is reasonable in a wired network since the error rates of copper and ¬bre optic cables are
very low. When a packet gets lost, the TCP stack slows down the ¬‚ow of data so that the
network can recover from the congestion, which naturally is good if the loss was as the
result of congestion. However, it is undesirable if the loss was due to genuine packet loss
since the slow down will just reduce the utilization of the link. As such, with a wireless
link it makes better sense to send the packet again as soon as possible. To allow the TCP
protocol to handle the wireless link correctly, a number of different options have been
proposed. Two of them, wireless pro¬led TCP (proposed in the WAP 2.0 speci¬cation)
and the Berkeley snoop module, are discussed here.
Figure 5.27 shows the con¬guration with the wireless pro¬led TCP. The wireless pro-
¬led TCP stack is a modi¬ed TCP stack optimized for the wireless link. An example of
this modi¬cation is the way retransmissions are handled. With standard TCP if a trans-
mitted packet is lost and ten more packets are transmitted, these will arrive out of order
and all eleven packets must be transmitted again.
This standard mechanism is a version of ARQ, referred to as go back N, and prevents
the receiver having to buffer out-of-order packet transmissions. This process is adequate
for a high-bandwidth wired link which loses very few packets, but presents a major
problem for a link with low initial bandwidth that has a tendency to lose packets. With
wireless pro¬led TCP, the stack is able to send only the packet that was lost (this is
called selective repeat ARQ), saving on link bandwidth and improving the ef¬ciency of
the transmission. Note that with this con¬guration, the link is broken into two pieces, a
TCP link between the WAP device and the WAP proxy, which implements the wireless
pro¬led TCP, and another standard TCP link between the WAP proxy and the server on
the wired network. This means that wireless pro¬led TCP is only required beyond the
proxy, with no changes required to the servers being accessed.

Upper layer Upper layer
(HTTP) (HTTP)
Wireless Wireless
TCP TCP
profiled TCP profiled TCP

IP IP IP IP


Wireless Wireless Wired Wired

WAP Device WAP Proxy Server

Figure 5.27 Wireless pro¬led TCP
5.6 IP FOR GPRS AND UMTS R99 201


The Berkeley snoop module implements a cache in the IP software at the base station.
As packets come from the wired host they are stored in the cache and then forwarded
to the wireless host. If the base station at some time in the future receives a dupli-
cate acknowledgement from the wireless host this means that a packet has been lost in
transmission. If the packet is in the cache it is forwarded to the wireless host and the
acknowledgement is discarded. If the packet is not in the cache then the acknowledge-
ment is forwarded to the wired host for standard TCP handling. The snoop module is
implemented transparently, such that no modi¬cation is required for the two end points.
Also, the optimization is only provided for downlink traf¬c to the wireless station from
the wired host.



5.6 IP FOR GPRS AND UMTS R99
IP is used for GPRS/UMTS in two ways. First, it is used as a transport mechanism
by mobile users to carry their data between the UE and hosts on the Internet or other
network. Second, it is used between network devices to support the GPRS tunnelling
protocol (GTP). This is shown in Figure 5.28; the advantage of this con¬guration is that
it isolates the operator™s network, keeping it secure from hackers operating from both the
mobile and the ¬xed network end. This diagram is modi¬ed on the UTRAN side from
that used in GSM/GPRS as described in Chapter 4.
In R99 of UMTS the role of IP is limited to the packet switched domain. The basic
network con¬guration is shown in Figure 5.29. The UTRAN network transport is based
on asynchronous transfer mode (ATM) and uses ATM Adaptation layer 2 (AAL2) for
user plane traf¬c with signalling carried over AAL5. Within the circuit switched core,
the network is based on a GSM core with the transport being circuit switched (i.e. ISDN,
SDH etc.). The IP protocol is used as transport in the packet switched domain between
the serving GPRS support node (SGSN) and the gateway GPRS support node (GGSN)
and over the Iu interface between the radio network controller (RNC) and the SGSN (i.e.
the Iu-PS).
Figure 5.30(a) shows how IP is used as a transport mechanism in the user plane. The
GTP protocol is used to carry user GPRS traf¬c between the RNC and the external data
network. Notice that for R99 all user plane traf¬c between the circuit core network and


External IP
User IP User IP
network
PDCP PDCP GTP GTP GTP GTP
RLC RLC UDP UDP UDP UDP
MAC MAC IP IP IP IP L1/L2
AAL5/ AAL5/
WCDMA AAL2/ATM L1/L2 L1/L2
ATM ATM
UE RNC SGSN GGSN
Uu Iub Iu Gn

Figure 5.28 GTP tunnelling for user IP (release 99)
202 IP APPLICATIONS FOR GPRS/UMTS


Circuit Core

PSTN/ISDN/
CSPDN
UTRAN
3G MSC/VLR GMSC


HLR AuC EIR
UE
Data Network
IP
RNC
WBTS

<<

. 43
( 132 .)



>>