Side_1_360

is to complete the transaction by exchanging a
few segments in each direction, thereby reducing
overhead by explicit connection establishment
and release.

A 32 bit incarnation number is introduced
(called Connection Count, CC). This is intro-
duced as a TCP option. The CC values are
increased for successive connections. The
receiver of a segment can check against its list
whether or not the received segment is a new
one. Thus, the receiver has to keep a list of the
latest used CC values for all clients (for a while,
e.g. given by twice the Maximum Segment Life-
time, MSL). The CC number is also echoed in
the return segment in order for the sender to cor-
relate the response with the original request.

An ordinary TCP establishment sequence would
then not be needed, see Figure 13. A minimal
sequence consists of three segments; firstly a
request – SYN segment (say CC= k); secondly
a reply – SYN segment (say CC= n, CC.echo
=k); and thirdly an acknowledgement segment.
In case the second segment is not a segment con-
taining the corresponding flags set, an ordinary
TCP establishment and sequence is entered.
When a transaction consists of three segments
only, estimating the RTTcould be based on sev-
eral transactions.

5.8 TCP on Asymmetrical

Configurations

When there is an asymmetrical configuration for
the transfer rate, TCP may face additional chal-
lenges. This is particularly the case when the
path from the receiver to the sender (reverse
direction) for sending TCP ACK segments has a
significantly lower rate than the other way (for-
ward direction). Both low rate and short buffers

in the reverse direction may lead to TCP ACKs

not arriving at the sender in time for not restrict-

ing the sending rate. Two key issues have to be

addressed: i) manage bandwidth usage on the

reverse link, e.g. to limit the number and trans-

mission capacity for transferring ACKs; and ii)

avoid any adverse impact of infrequent ACKs.

Some approaches to deal with the former are,

ref. [ID_pilc]:

• TCP header compression; reducing the size of
  the header.


• ACK filtering; drop ACKs that may not be
  needed, e.g. by dropping ACKs in the buffer
  when a new ACK arrives.


• ACK congestion control; having a mechanism
  that indicates to the receiver that the ACK
  path is congested and the receiver’s response
  to such an indication, e.g. using Random Early
  Detection (RED) and Explicit Congestion
  Notification (ECN), see [Jens01].


• ACKs first scheduling; placing ACKs first in
  the buffer.


• Back pressure and fair scheduling; limiting
  the amount of data packets in the reverse
  direction.

Commonly, several of these techniques have to

be combined.

Receiving ACKs infrequently might lead to

the sender halting its transmission. This can be

tackled either end-to-end or locally at the con-

strained link. Some approaches to handle infre-

quent ACKs are, ref. [ID_pilc]:

Figure 13 Message sequence

for establishing an ordinary

TCP connection and for the

complete transaction/TCP

transfer

SYN-flag, ACK-flag, FIN-flag, seq =

y, ack = x + 1, CC = n, CC.echo =

k, data2

SYN-flag, seq = x

SYN-flag, ACK-flag, seq =

y, ack = x + 1

ACK-flag, ack = y + 1

source destination

seq = sequence number

ack = acknowledgement number

Ordinary TCP

connection

establishment

...................

SYN-flag, FIN-flag, seq = x, CC = k

, data1

ACK-flag, FIN-flag, ack = y + 1,

CC = k

Transaction

TCP