tcpcongest

Modeling and Verification of TCP Congestion Control
Based on Colored Petri Nets*
Ganfeng Bao
Bell Labs Research China, Lucent Technologies
15F, 30 Han Dian Nan Lu, Beijing China 100080
baogf@lucent.com
Fang Liu
Bell Labs Research China, Lucent Technologies
15F, 30 Han Dian Nan Lu, Beijing China 100080
fliu@lucent.com
Li Hong
Dept. of Communication Science & Engineering
Fudan University
220 Han Dan Road, Shanghai China 200433
hli@fudan.ac.cn
*
0-7803-7952-7/03/$17.00 ©©©© 2003 IEEE.
Abstract - There are different TCP congestion control
implementations running on different operating systems.
The implementation errors are easily introduced and have
been reported by a RFC. It is a challenging task to ensure
that TCP protocol is correctly and completely
implemented according to the specification. This paper
focuses on TCP congestion control modeling and
verification. A verification environment is presented and
a formal model of the TCP congestion control is
established using colored Petri nets. The controllable and
observable events in the verification environment are
encoded in the model. The verification is performed by
searching the occurrence graph of the model. A
randomized algorithm is adopted to verify the TCP
congestion control implementations.
Keywords: Colored Petri Nets, TCP, Congestion Control
1 Introduction
TCP is the most famous transport protocol in the
Internet. It offers connection-oriented, reliable, byte
stream data transfer [9]. Today’s most popular application
protocols, like FTP and HTTP, are built on it. Though
TCP is widely used in Internet, new features are still
proposed and implemented. There are a lot of TCP
implementations due to two main reasons. Firstly new
functions are continually proposed and integrated into
available TCP implementations, which leads to different
TCP versions, e.g., TCP Tahoe, TCP Reno and TCP
SACK, etc. Secondly the TCP implementations are closely
related to the operating systems. Different operating
systems need different TCP implementations. TCP
protocol is quite a complex protocol and the
implementation errors are easily introduced. The RFC
2525 [8] indicates several implementation errors classified
into four categories, i.e., congestion control, performance,
reliability and resource management. In the congestion
control category, nine problems (including no initial slow
start, extra additive constant in congestion avoidance and
failure to back off retransmission timeout, etc.) are
reported. The TCP implementation needs to be verified
according to the specification.
TCP, like most other Internet protocol specifications,
is described in the form of natural languages. This can be
easily understood, but it often contains ambiguities. A
formal model is needed to describe the TCP protocol.
Some researchers have tried to establish the formal TCP
model. For example, Figueiredo and Kristensen [2]
established TCP’s colored Petri nets model. But it is
mainly used to study TCP’s performance. Han and
Billington [3] modeled TCP’s connection management
based on TCP specification’s finite state machine. The
formal model in this paper focuses on TCP’s congestion
control feature.
In order to detect errors, some tools for testing TCP
implementations have been developed. RFC 2398 [6]
mentions some TCP testing tools. Some of these tools are
trace analyzers or performance monitors, such as TReno
and Ttcp. The others are testers, such as Orchestra and
Packet Shell. Both of them need to be combined with a
formal verification model. This paper gives a formal
model based on an environment especially designed for
TCP congestion control feature verification.
In the testing area, there are two testing methods:
passive testing and active testing [5]. The passive testing
consists of collecting traces of the messages exchanged
between an operating implementation and its environment,
and verifying the implementation behaviors. In active
testing, the implementation under test (IUT) is placed in a

dedicated testing environment. According to the test cases,
one or more tester sends inputs to the IUT, observes the
corresponding outputs and compares them with the
expected outputs. Paxson provided a pioneering work in
the passive testing on TCP implementations [7]. He tried
to capture packets in real and congested environment, then
examined and analyzed the obtained traces. Since it is
hard for the passive testing to detect errors with satisfied
coverage, the tester should be involved more in the testing
environment, which means that an active testing
environment is preferred. This paper follows this direction
in spite of the difficulty arisen from the complexity of
TCP protocol.
We intend to verify the TCP congestion control
implementations, not TCP congestion control feature itself.
Hence we should establish a verification environment at
first. A colored Petri net model is established based on the
environment. Finally the verification is performed with the
help of a randomized algorithm.
The rest of the paper is organized as follows. Section
2 explains the verification environment for TCP
congestion control implementation. Section 3 focuses on
the formalization of TCP congestion control. Section 4
presents the TCP implementation verification algorithm.
Finally Section 5 sums up the present work and points out
the future work.
2 The Verification Environment
This section introduces the basic concepts of TCP
congestion control feature and then the verification
environment.
2.1 TCP Congestion Control
When the load offered to a network is more than it
can handle, congestion builds up. TCP tries to control the
congestion by dynamically manipulating the size of
congestion window. This congestion window, together
with the receiver side’s advised window, gives an upper
bound to the number of outstanding data bytes per
connection. TCP contains four intertwined congestion
control algorithms: slow start, congestion avoidance, fast
retransmit, and fast recovery [1], [10].
TCP uses slow start whenever it starts sending data
on a newly established connection. The algorithm starts
the congestion window at the size of single segment, and
sends it. If the communication is successful and an
acknowledgement arrives before the retransmission timer
expires, it adds one segment to the congestion window
size. Continue adding one segment to the congestion
window each time that an acknowledgement arrives. Thus
it will continue to increase exponentially until it reaches
the slow start threshold.
Once the congestion window reaches the slow start
threshold, TCP switches to execute the congestion
avoidance algorithm, which slows down the rate of the
growth of congestion window by increasing only one
segment per round trip time. The congestion avoidance is
performed until the network congestion is detected.
The fast retransmit avoids returning to the expensive
slow start after the retransmission. It tries to send the lost
segment as soon as possible. It is assumed that the cause
for the duplicate acknowledgements is just a reordering of
segments and the number of the duplicate
acknowledgements is very small (typically no more than
3). If more duplicated acknowledgements are received, the
TCP sender concludes that the segment indicated in the
duplicate acknowledgements has been lost. Immediately
the sender retransmits the segment that appears to be lost.
After fast retransmit sends the missing segment, the
TCP congestion control turns to fast recovery. At this
point, the sender reduces its congestion window by half
plus the duplicated acknowledgements. Also half of the
original congestion window is saved to slow start
threshold. For each additional duplicated
acknowledgement, the sender increases congestion
window by one and send a new segment whenever
possible. When a new acknowledgement is received for
the retransmission segment, congestion avoidance is
performed instead of slow start.
2.2 The Verification Environment
The verification environment for TCP congestion
control implementations can be passive or active. The
passive environment does not need to be involved in
TCP’s kernel implementations; hence it is relatively easy.
But there exist two problems. Firstly, the underlying
physical networks are extraordinary diverse with a wide
range of delay, throughput, and packet loss rate. It is hard
to ensure that the collection of data have covered all the
possible situations for the verification purpose. Secondly,
some situations are hard to be explained. Hence some
ambiguities have to be included [7]. Though difficult, it is
worth to perform the active verification for the complex
protocol like TCP.
The verification environment is complicated by the
limited observability and controllability of protocol
implementation from outside. This means that in most
cases we cannot directly place the TCP protocol
implementation into a predetermined state. Besides we in
general cannot directly observe the state of the TCP
protocol implementation. In our verification environment,
we introduce an intermediator which tries to involve more
in controlling and observing TCP segments.

The verification environment includes two TCP ends.
The intermediator is placed between these two TCP ends.
The intermediator works like a "bad" router - incoming
packets may be delayed, dropped, duplicated, reordered
and bandwidth-constrained, etc. In normal cases, the
intermediator observes the segments from one TCP end
and forwards the segments to the other, as shown in Figure
1. It can also drop some segments to let the TCP sender
retransmit them.
Figure 1. The verification environment for the TCP
congestion control implementation
3 TCP Congestion Control Model
The use of natural languages in specifications gives
the illusion of being easily understood, but leads to
lengthy specifications that often contain ambiguities and
are difficult to check for their completeness and
correctness. Therefore a formal model is needed.
3.1 Colored Petri Nets
Petri net and colored Petri nets (CPN) have been
used extensively for modeling and verification of
protocols [4]. The CPN allows data to have different types
and values (“colors”) while original Petri nets allow only
boolean (“black and write”) data. Each place is typed by a
“color set”, and may contain data items (tokens) of the
type. The state of a CPN is called a marking, consisting of
tokens distributed on each place of the model. Transitions
can have associated predicates and actions on the variables.
The predicates control the firing of the transitions, i.e. a
transition can take place only if its associated predicate
evaluates to true for the current marking, and the
associated action can modify the value of the variables. A
CPN is a compact specification of an expanded full
ordinary Petri nets.
The CPN tool used in this paper is Design/CPN,
which supports complex data types (color sets) and
complex data manipulations (arc expressions and guards) -
both are specified in the functional programming language
Standard ML. Design/CPN also supports hierarchical
models. The state space of a CPN model is known as
occurrence graph or reachability graph. See [11] and [12]
for the detailed information on Design/CPN.
3.2 TCP Congestion Control High Level Modeling
The CPN model is based on the verification
environment. The two TCP ends are assumed to have
finished the connection establishment. The receiver’s
buffer is big enough to store all the incoming segments.
The model is used to verify the TCP implementation.
Hence the observable and controllable events for the
intermediator should be encoded in the model. At present
the intermediator supports two actions, i.e., forward and
drop.
The model is organized into two hierarchical levels,
as shown in Figure 2. The top level named
TCPCongestControl is refined by three sub-models in the
low level. Each sub-model processes a TCP congestion
control algorithm, i.e. slow start, congestion avoidance,
and fast recovery. Fast retransmission is not described in a
sub-model because it is just an action to transfer a possible
lost segment and can easily be represented by a transition.
The high level model is shown in Figure 3, which
provides an abstract view of the TCP congestion control
feature. The place GlobalVar stores the global variables.
The place SlowStartState, CongestAvoidState and
FastRecoverState model the execution state of the TCP
congestion control algorithms. A token in these state
places means the corresponding TCP congestion control
algorithm is performed. There are three substitution
transitions named SlowStart, CongestAvoid and
FastRecover. A substitution transition is a transition
created to be linked with another CPN sub-model that is
actually simulated when the substitution transition
executes. Each of them implements a certain TCP
congestion control algorithm. The places associated with a
substitution transition need to be assigned to places with
the same function in the sub-model. For example, the
place GlobalVar in Figure 3 are assigned to the place with
the same name in Figure 5.
Figure 2. The hierarchy for the CPN model
TCP End A TCP End BIntermediator

Figure 3. High level CPN model
3.3 The Global Declaration
The global declaration is shown in Figure 4. A color
set EXEC represents the execution state of TCP
congestion control algorithms. A TCP segment is modeled
as a record with the sequence number (seq) and the
acknowledgement number (ack).
A color set GVAR is defined by transmission control
block (TCB) and other variables. TCB is used to maintain
the state of a TCP connection. The TCB variables includes
cwnd, sshresh, snd_una, snd_nxt and rcv_nxt. The
variable cwnd represents the congestion window. The
variable sshresh is the slow start threshold. The variable
snd_una records the sequence number of the segment that
has been sent but has yet to be acknowledged. The
variable snd_nxt stores the sequence number of the next
segment to be sent. The variable rcv_nxt stores the
sequence number of the next segment to be received.
The other variables in GVARinclude Q_aout, Q_bin,
Q_bout, Q_ain, Q_cdropa, frag, dup and duptime. The
queue Q_aout stores the segments which have been sent
out from TCP End A. Other queues, i.e., Q_bin, Q_bout,
Q_ain, can be explained similarly by their name. The
queue Q_cdropa is used to store the segments sent from
TCP End A and will be dropped by the intermediator.
Note that the model just forwards the segment sent from B
to A. It can also drop the segments sent from B to A. But
from the sender’s viewpoint, only one segment is dropped
and the segment should be retransmitted. As the sender
plays the main role in TCP congestion control, we
simplify the model by just considering the dropped
segments from one direction. The variable frag stores the
segment fragment when the reordering occurs. The
variable dup and duptime are used to process the
duplicated acknowledgements.
The global constants include MSS (the maximum
segment size) and num (the number of segments needed to
be sent in the model). The variable v and e are the instants
of GVAR and EXEC, respectively. There are also some
functions that implement the TCP congestion control
algorithms. These functions are not listed and explained in
detail due to the length limitation of the paper.
Figure 4. Global declarations
3.4 TCP Congestion Control Low Level Modeling
The SlowStart sub-model (shown in Figure 5)
describes the TCP slow start behavior. The transitions in
this level describe the observable events or controllable
actions by the intermediator in the verification
environment. For example, transition A2C means the TCP
End A sends a segment to intermediator (namely C). If the
intermediator decides to forward the segment, the
following transition sequence, i.e., C2B, B2C, C2A and
A2U, forms a regular flow of a segment. If the
intermediator drops the segment one time instead of
forwarding it, the following transition sequence will be
CdropA, AretranC, C2B, B2C, C2A and A2U.
When the congestion window (cwnd) becomes larger
than the slow start threshold (ssthresh), the state changes
from SlowStartState to CongestAvoidState. The
congestion avoidance is described in Figure 6. The
transition Congest takes the action that fulfils the state
change. Before the sender receives three duplicate
acknowledgements, the transition Congest_c is executed.
After the sender receives three duplicate
acknowledgements, the transition FastRetran is executed
and the state changes from the congestion avoidance to the
fast recovery, described in Figure 7. If the sender
continues to receive the duplicate acknowledgements, the
transition FastRecover is executed; otherwise the state
changes to congestion avoidance after executing the
transition FastFin.
In either state of SlowStartState, CongestAvoidState,
or FastRecoverState, if the retransmission timer expires,

the state should change to SlowStartState after
retransmitting the lost segment.
Figure 5. The slow start sub-model
Figure 6. The congestion avoidance sub-model
Figure 7. The fast recovery sub-model
4 The Verification Algorithm
In the verification environment, the intermediator
observes the events from the two TCP ends and decides its
actions, e.g., forward or drops. The errors in the
implementation can be found if it does not perform the
behavior with respect to the formal model. We need to
generate the sequence of the events and actions, called
verification sequence. The occurrence graph can be
obtained from the CPN model, which is supported by
Design/CPN tool suite. In the occurrence graph, a path
from the initial node is a verification sequence.
We can generate the verification sequences for the
intermediator in advance, then execute the verification
sequences in the verification environment. Due to the non-
deterministic property of the TCP congestion control
feature, the number of allowed behaviors is very huge
even for the transmission of a small number of segments.
In fact, as there could be infinite segments to be sent, the
occurrence graph may be infinite. Even the TCP end just
sends some finite number of segments, the method is
difficult to be implemented because the occurrence graph
is huge and intermediator needs to store the huge number
of verification sequences.
We try to solve the problem in a different way, i.e.,
to generate the verification sequence in the runtime. In this
method, the intermediator executes the CPN model in
parallel with the two TCP ends. Its next verification action
is based on the present observed events. The algorithm is
described in Figure 8.
Since the state number may be infinite, the
verification cannot be exhaustive. We can execute only a
finite number of the possible behaviors and gain the
confidence that there are not errors in the TCP
implementation. The measurement for the confidence is
often defined differently for different models and practical
needs. Our measurement is to execute each transition in
the CPN model at least twice. Of course more strict
measurement can be introduced. In the algorithm, the
function satisfied(T) encodes the measurement and is used
to decide if we have got the satisfied confidence of the
TCP implementation and then stop the verification.
From viewpoint of the intermediator, the transitions
in the CPN model can be observable, controllable or
hidden. For example, the transition A2C is observable, the
transition C2B is controllable and the transition Congest is
hidden from outside. The events obtained from the
verification environment are not always the same as those
in the CPN model. There is a one-to-many mapping
between the event from the verification environment and
the transitions in the CPN model. For instance, both the
transition A2C and AretranC match the event that the
intermediator gets a segment from TCP End A. The
function match(e) reflects such mapping.
In the algorithm, a randomized method is adopted to
avoid repeatedly executing the same part of the CPN
model. The searching of the occurrence graph is guided
with the goal to execute all transitions twice in the model.
The algorithm uses this technique in two situations. Firstly
when the intermediator faces the choice of observing or
controlling, it performs the function random() which
produces a random value falling into the range [0,1]. In
the algorithm, the parameter P is used to determine if the
intermediator should be more active to perform actions or
be more passive to wait for the outside events. Secondly

when there is more than one controllable transition to be
selected, the intermediator randomly select one according
to the probability with the ratio based on the execution
number of the transitions.
Figure 8. The randomized verification algorithm
5 Conclusions
The paper describes the verification environment for
the TCP congestion control implementations. A formal
CPN model is established based on the verification
environment. A randomized algorithm is adopted to verify
TCP congestion control implementations. The future work
will enrich the CPN model to reflect more TCP features.
The verification algorithm is also worth further studying.
References
[1] M. Allman, V. Paxson and W. Stevens. TCP
Congestion Control. RFC 2581, April 1999.
[2] J.C.A. de Figueiredo, L.M. Kristensen: Using
Coloured Petri Nets to Investigate Behavioural and
Performance Issues of TCP Protocols. In K.Jensen (ed.):
Proceedings of the 2nd Workshop on Practical Use of
Coloured Petri Nets and Design/CPN, Aarhus 1999,
Department of Computer Science, University of Aarhus,
PB-541, 21-40.
[3] B. Han and J. Billington. An Analysis of TCP
Connection Management Using Coloured Petri Nets. In
Proc. 5th World Multi-Conference on Systemics,
Cybernetics and Informatics (SCI'2001), Orlando, Florida,
USA, 22-25 July 2001, pp.590-595.
[4] K. Jensen. Coloured Petri Nets: Basic Concepts,
Analysis Methods and Practical Use, Volume 1-3.
Springer-Verlag, Berlin, 1997.
[5] D Lee, et al. Passive testing and applications to
network management. ICNP’97 International Conference
on Network Protocols, Atlanta, Georgia, October 28-31,
1997.
[6] S. Parker, C. Schmechel. Some Testing Tools for
TCP Implementors. RFC 2398, August 1998.
[7] V. Paxson. Automated packet trace analysis of TCP
implementations. ACM SIGCOMM’97, Cannes, France,
September 1997.
[8] V. Paxson, M. Allman, S. Dawson, W. Fenner, J.
Griner, I. Heavens, K. Lahey, J. Semke, B. Volz. Known
TCP Implementation Problems. RFC 2525, March 1999.
[9] J. Postel (ed). Transmission Control Protocol
(Standard). RFC 793, September 1981.
[10] W. Stevens. TCP Slow Start, Congestion Avoidance,
Fast Retransmit, and Fast Recovery Algorithms. RFC
2001, Jan 1997.
[11] Meta Software. Design/CPN Reference Manual,
Version 2.0, 1993.
[12] University of Aarhus. Design/CPN Occurrence
Graph Manual, Version 3.0, 1996.
generate the initial occurrence graph node s0;
let the possible present states S = { s0 } ;
let t1,…,tm represent the execution number of the
transitions in the CPN model, clear t1,…, tm to zero ;
while not satisfied(T ) do
let the possible next observable and controllable
transitions from the present states A = ∅ ;
while S ≠ ∅ do
let s ∈ S, generate the next states s1,...,sn of the
state s from the occurrence graph of the CPN
model, the according arcs are a1,…,an ;
for i ∈ {1,…,n } do
if ai is observable or controllable then
A = A ∪ {ai} ;
else
S = S ∪ {si} ;
done
S = S - {s} ;
done
if A = ∅ then
report terminate; exit;
end
if there are events from the envrionment and
random() > P then /* try to observe */
read the event e fom the environment;
A′ = match(e) ∩ A ;
if A′ = ∅ then
report error; exit;
end
for ai ∈ A′ do
let sj denote the ending node of arc ai,
S = S ∪ {sj} ;
ti = ti + 1/ |A′ | ;
done
else /* try to control */
let A ={a1,…,ak}, select and execute ai with the
same probability ratio as 1/(t1,+1),…,1/(tk +1) ;
let sj denote the ending node of arc ai,
S = {sj} ;
ti = ti + 1 ;
end
done

tcpcongest

More Related Content

What's hot (15)

Viewers also liked (20)

Similar to tcpcongest (20)

tcpcongest