Side_1_360

the round-trip delay. An observation is that the

receiver’s window should be at least as great as

this product. If this window is too small, the

sender has to pause in the transmission waiting

for the data to be acknowledged. This could

result in poor utilisation of the transmission link.

On the other hand there is rarely only one single

sender-receiver connection present at any major

link.

As transmission rates increase, the bandwidth-

delay product may very well increase for an end-

to-end connection. This may ask for additional

features in TCP in order to efficiently utilise

high rate links. Due to the window mechanism

TCP performance does not only depend on the

transfer rate but also on the round-trip delay.

The bandwidth-delay product gives a measure

of the amount of data that can “fill the transfer

link” see Figure 12. Note that the bandwidth

may not be symmetric. Additional TCP perfor-

mance challenges arise as this product gets

larger.

Three fundamental problems are, ref.

[RFC1323]:

• Limit of the window size: Using 16 bits to
  specify the window size limits the largest
  size to 64 kbyte. This can be circumvented by
  introducing an additional TCP option, called
  window scale. Then the TCP window can be
  interpreted as a 32 bit value by considering
  the scaling factor that is given in the window
  scale field of a TCP SYN segment. This
  means that the scaling is fixed in each direc-
  tion at the establishment of the connection.
  When scaling the window, the value in the
  field is right-shifted a number of positions
  according to the value in the window scale
  field (binary shift). This is the same as saying
  that the scale factor is given as a power of two
  and coded logarithmically. Say scaling by
  8=2^3 means sending the value 3.


• Loss recovery: As more data could be under
  way for a large bandwidth-delay product, a
  dropped packet may have large impact on
  the resulting throughput and more data might
  be scheduled for retransmission. Selective
  acknowledging packets and selective retrans-
  mission could alleviate this.
  
  
  • Estimating round-trip delay: Having an accu-
    rate estimate of the round-trip delay is essen-
    tial to avoid unnecessary retransmission at the
    same time as dropped packets are retransmit-
    ted without delaying the sender too much.
    Therefore, the retransmission timeout interval
    (RTO)has to be set properly based on esti-
    mates of the round-trip time (RTT). An addi-
    tional TCP option including a timestamp
    allows for improved estimates of RTT. Then
    the sender assigns a timestamp to the packet
    and the receiver returns this timestamp in the
    ACK segment (timestamp echoing). This
    implies that the timestamps returned are
    related to the ACKs that advance the window
    avoiding the introduction of “artificial delays”
    due to sequence buffering in the receiver
    (when ACKs are delayed and several seg-
    ments are to be acknowledged, this rule is
    not followed).
  
  
  
  

Two further mechanisms are described in

[RFC1323]; Round Trip Time Measurement

(RTTM) and Protect Against Wrapped Se-

quences(PAWS). The former addresses estimat-

ing round-trip delays, basically by introducing

time stamps in the segments.

When large amounts of packets can be on the

way, it may happen that sequence numbers are

to be used several times for the same connection

within a short time. This could cause sequence

numbers to be wrapped-around and also that

“old” packets arrive after the retransmitted ones,

possibly being mistaken for a packet belonging

to a following round of sequence numbering.

The PAWS mechanism has been proposed to

avoid this. The same mechanism as RTTM is

used, i.e. timestamps inserted into the segments.

Basically, if a segment is received for which the

timestamp is too old, this segment is dropped.

What is considered as too old is found by com-

paring the segment’s timestamp with the time-

stamp of the recent segment updating the

counter for the RTTM mechanism.

5.7 TCP and Short Transactions

For many applications a small amount of infor-

mation is to be exchanged by the end-points. An

example may be a message containing status

information of a network element reported to a

management system. Having to establish and

release (as well as maintain) a TCP connection

for such exchanges would imply additional over-

head in terms of messages and delays.

An extension to TCP for supporting (short)

transactions more efficiently is described in

[RFC1644]. Transactions are commonly used for

the client-server oriented end-user applications

as well as for several control and management

procedures. The objective of the TCP extension

Figure 12 Bandwidth-delay
product

Capacity, C

Bandwidth-delay product = C • t [volume]

Round-trip delay, t