Connection Oriented

STEP 1: Host A sends the initial packet to Host B. This packet has
the "SYN" bit enabled. Host B receives the packet and sees the
"SYN" bit which has a value of "1" (in binary, this means ON) so it
knows that Host A is trying to establish a connection with it.
STEP 2: Assuming Host B has enough resources, it sends a packet
back to Host A and with the "SYN and ACK" bits enabled (1). The
SYN that Host B sends, at this step, means 'I want to synchronise
with you' and the ACK means 'I acknowledge your previous SYN
request'.
STEP 3: So... after all that, Host A sends another packet to Host B
and with the "ACK" bit set (1), it effectively tells Host B 'Yes, I
acknowledge your previous request'.
Once the 3-way handshake is complete, the connection is
established (virtual circuit) and the data transfer begins.
Connection Creation
Connection Creation
Connection Creation
Connection Creation
Connection Teardown
Connection Teardown
Connection Teardown
Connection Teardown
 Flow Control

when a machine receives a flood of data too quickly for it to process, it

stores it in a memory section called a buffer.

However, if the data burst continues it will eventually exhaust the memory
of the receiving end and that will result in the arriving data being
discarded.

So in this situation the receiving end will simply issue a "Not ready" or
"Stop" indicator to the sender, or source of the flood.

After the receiver processes the data it has in its memory, it sends out a
"Ready" or "Go" transport indicator and the sending machine receives the
 Windowing

Data throughput, or transfer efficiency, would be low if the

transmitting machine had to wait for an acknowledgment after
sending each packet of data (segment).

Because there is time available after the sender transmits the data
segment and before it finishes processing acknowledgments from
the receiving machine, the sender uses the break to transmit
more data.

Windowing we could do so by stating that it is the number of data

segments the transmitting machine is allowed to send without
receiving an acknowledgment for them.
Suppose window size equal to 3, which means that Host B can send
3 data segments to Host A before expecting an "ACK" back.

Host B sends the first 3 segments (Send 1, Send 2 and Send 3), Host
A receives them all in good condition and then sends the "ACK 4" to
Host B.

This means that Host A acknowledged the 3 data segments Host B

sent and awaits the next data segments which, in this case, would
be 4, 5 and 6.
The window size of this transfer which is equal to 3.
At first, Host B sends 3 data segments to Host A and they are received in
perfect condition so, based on what we learned, Host A sends an "ACK 4"
acknowledging the 3 data segments and requesting the next 3 data
segments which will be 4, 5, 6.

As a result, Host B sends data segments 4, 5, 6 but 5 gets lost somewhere along the
way and Host A doesn't receive it so, after a bit of waiting, it realizes that 5 got lost and
sends an "ACK 5" to Host B, indicating that it would like data segment 5 retransmitted.
This method is called "positive acknowledgment with retransmission".

At this point Host B sends data segment 5 and waits for Host A to send an "ACK" so it
can continue sending the rest of the data. Host A receives the 5th data segment and
sends "ACK 7" which means 'I received the previous data segment, now please send
TCP Header and TCP Segment
When you send a http request to download a webpage, it must be sent to the correct web
server in order for it to receive it, process it and allow you to view the page you want.

This is achieved by obtaining the correct IP address via DNS resolution and sending the
request to the correct port number at the remote machine (web server). The port value, in
the case of an http request, is usually 80.

Once your request arrives at the web server, it will check that the packet is indeed for itself.
This is done by observing the destination IP Address of the newly received packet. Keep in
mind that this particular step is a function of the Network layer.

Once it verifies that the packet is in fact for the local machine, it will process the packet and
see that the destination port number is equal to 80. It then realises it should send the
data (or request) to the http deamon that's waiting in the background to serve clients
To use the FTP service, workstation generates a packet that is directed to the
server's IP address, that is 200.0.0.1, but this time with a destination port of 21.
The first host that wishes to initiate the connection, to generate what is called an
Initial Sequence Number (ISN), which is basically the first sequence number that's
contained in the Sequence field.
Host A wishes to download a webpage from the Gateway Server.
Host A sends a packet to the Gateway Server.

This packet has the SYN flag set and also contains the ISN generated by Host
A's operating system, that is 1293906975.

Since Host A is initiating the connection and hasn't received a reply from the
Gateway Server, the Acknowledgment number is set to zero (0).

In short, Host A is telling the Gateway Server the following: "I'd like to initiate a
new connection with you. My Sequence number is 1293906975".
The Gateway Server receives Host A's request and generates a reply
containing its own generated ISN, that is 3455719727, and the next Sequence
number it is expecting from Host A which is 1293906976.

The Server also has the SYN & ACK flags set, acknowledging the previous
packet it received and informing Host A of its own Sequence number

In short, the Gateway Server is telling Host A the following: "I acknowledge
your sequence number and expecting your next packet with sequence number
1293906976. My sequence number is 3455719727".
Host A receives the reply and now knows Gateway's sequence number. It
generates another packet to complete the connection. This packet has the ACK
flag set and also contains the sequence number that it expects the Gateway
Server to use next, that is 3455719728.

In short, Host A is telling the Gateway Server the following: "I acknowledge
your last packet. This packet's sequence number is 1293906976, which is what
you're expecting. I'll also be expecting the next packet you send me to have a
sequence number of 3455719728".

Since the 3-way TCP handshake has been completed, a virtual connection
between the two now exists and the Gateway Server is ready to listen to Host
A's request.
In this step, Host A generates a packet with some data and sends it to the
Gateway Server. The data tells the Gateway Server which webpage it would like
sent.
we can see our packet sniffer indicating that the field has a value of 7(hex) and
this is interpreted as 28 bytes. To calculate this, you take the value of 7, multiply
it by 32 and divide the result by 8: 7x32=224/8=28 bytes.
This flag is used to identify incoming data as 'urgent'. Such incoming segments
do not have to wait until the previous segments are consumed by the receiving
end but are sent directly and processed immediately.
URG:This flag is used to identify incoming data as 'urgent'. Such incoming segments do
not have to wait until the previous segments are consumed by the receiving end but are
sent directly and processed immediately.

The URG pointer tell how many bytes of the data is urgent in the segment that has arrived.
(Example if the data size is 100 bytes and only firs 50 bytes is urgent, the urgent pointer
will have a value of 50).
Acknowledgement: The Acknowledgement flag is used to acknowledge the successful
receipt of packets.

PUSH :The Push flag, like the Urgent flag, exists to ensure that the data is given the
priority (that it deserves) and is processed at the sending or receiving end.

The purpose of the PSH bit is to tell TCP that do not wait for the buffer to become full and
send the data immediately. Similarly when the receiver receives the segment with PSH
flag set, should send the data immediately to the upper layer without waiting for the
receive buffer to become full.
Reset (RST) Flag

The reset flag is used when a segment arrives that is not intended for the
current connection. The host would automatically reject your request and
then send you a reply with the RST flag set. This indicates that the remote
host has reset the connection.

There the sender has already closed the port on whcih the connection was
open some time back and hence the RST.

The host has simply run out of resources.

 SYNchronisation Flag

SYN- Synchronize is used during session setup to agree on initial sequence

numbers. Sequence numbers are random.

After the three way handshake a dedicated virtual path is established

between the source machine to the target machine for the actual data to
transfer.
 FIN Flag
FIN flag is used to negotiate between the peer systems that the communication
is over and they can drop the connection. Basically, it tears down the TCP
virtual connection. FIN is a 4 way handshake which appears in the last packet
of a session.

The above diagram represents an existing connection betwen Host A and B, where the
two hosts are exchanging data. Once the data transfer is complete, Host A sends a packet
with the FIN, ACK flags set (STEP 1).
With this packet, Host A is ACKnowledging the previous stream while at the same time
initiating the TCP close procedure to kill this connection. At this point, Host A's application
will stop receiving any data and will close the connection from this side.
In response to Host A's request to close the connection, Host B will send an
ACKnowledgement (STEP 2) back, and also notify its application that the connection is no
longer available. Once this is complete, the host (B) will send its own FIN, ACK flags
(STEP 3) to close their part of the connection.
The purpose of the TCP window size is to allow the receiving TCP host to tell the sending
TCP host the amount of data it is currently willing to receive.

In this example, Host A is connected to a Web server via a 10 Mbit link. According to
formula, to calculate the best Window value we need the following information: Bandwidth
and Delay. We are aware of the link's bandwidth: 10,000,000 bits (10 Mbits), and we can
easily find out the delay by issuing a 'ping' from Host A to the Web server which gives us an
average Round Trip Time response (RTT) of 10 milliseconds or 0.01 seconds.
We are then able to use this information to calculate the most efficient Window size
(WS):WS = 10,000,000 x 0.01 => WS = 100,000 bits or (100,000/8)/1024 = 12,5 kbytes
For 10 Mbps bandwidth and a round-trip delay of 0.01 sec, this gives a window size of
about 12 kb or nine 1460-byte segments:

This should yield maximum throughput on a 10 Mbps LAN, even if the delay is as high
as 10 ms because most LANs have round-trip delay of less than a few milliseconds.
When bandwidth is lower, more delay can be tolerated for the same fixed window size,
so a window size of 12 kb works well at lower speeds, too.
 The original TCP standard limits the receive window size to 64KB or 65,536 bytes. This is
because the field in the TCP header is only 16-bits wide. TCP's receive window size is particularly
important in satellite communications, because the maximum throughput of a single TCP
connection is bounded by the following equation:
windowsize
throughput max
roundtript ime

Without large windows, the maximum effective throughput for a single TCP connection over geosynchronous satellite is:

65536 KB
throughput max 126kBps 1008kbps
0.520

Throughput is often referred to as bandwidth and the round trip time (RTT) as the delay. We can rewrite this equation
and solve for the minimum window size required given the bandwidth of the link and round trip delay as follows:

windowsize min bandwidth delay

Based on this new equation, we can calculate the minimum required receive window size for any link if we know the delay.
For instances, if we assume a round trip end-to-end satellite delay of 530ms and a link bandwidth of 1.544Mbps or T1,
the minimum window size is:

windowsize min 1,544,000bps 0.530 s 818,320bits 102 KB

This new option is used to multiply the window size value found in the TCP
header window field to obtain the true window size. The new maximum window
size can now be as high as 230 or slightly over 1Gbyte
Checksum Flag

Pseudo Header
Maximum Segment Size (MSS)
Window Scaling
Selective Acknowledgements (SACK)
Timestamps
Nop
TCP usually computes the Maximum Segment Size (MSS) that results in IP
Datagrams that match the network MTU. In practice, this means the MSS will have
such a value that if we add the IP Header as well, the IP Datagram (IP Header+TCP
Header+DATA) would be equal to the network MTU.
 Window Scaling is, in essence, an extention to the Window size flag. Because the
largest possible value in the Window size flag is only 65,535 bytes (64 kb), it was
clear that a larger field was required in order to increase the value to a whopping 1
Gig! Thus, Window Scaling was born

The Window Scaling option can be a maximum of 30 bits in size, which includes the
original 16 bit Window size field covered in the previous section. So that's 16
(original window field) + 14 (TCP Options 'Window Scaling') = 30 bits in total.
with the use of Window Scaling, the window size has increased to256 kb! Since
the value is quite large, which translates to more data during transit, Host B has
already received the first few packets, while Host A is still sending the first 256 kb
window.
On Time = 2, Host B sends an Acknowledgement to Host A, which is still busy
sending data. Host A will receive the Acknowledgement before it finishes the 256
kb window and will therefore continue sending data without pause since it will
soon receive another Acknowledgement from Host B.
 Selective Acknowledgments (SACK)

For example, if we have a Windows98 client that is waiting for byte 4,268, but
the SACK option shows that the Windows98 client has also received bytes
7,080 through 8,486, it is obvious that it is missing bytes 4,268 through 7,079,
so the server should only resend the missing 2,810 bytes, rather than restarting
the entire transfer at byte number 4,268.
Lastly, we should note that the SACK field in the TCP Options uses two 16 bit
fields, a total of 32 bits together.

Timestamps
The Timestamp field consists of a Timestamp Echo and Timestamp Reply field,
both of which the reply field is always set to zero by the sender and completed
by the receiver after which it is sent back to the original sender. Both timestamp
fields are 4 bytes long!

Nop
"No Option" and is used to separate the different options used within the TCP
Option field.
For example, if options MSS and SACK are used, Windows XP will usually
place two nop's between them
When the above packet arrives at the receiver, a decapsulation process is
required in order to remove each OSI layer's overhead and pass the Data portion
to the application that's waiting for it. As such, when the packet is received in full
by the network card, it is given to the 2nd OSI layer (Datalink) which, after
performing a quick check on the packet for errors, it will strip the overhead
associated with that layer, meaning the yellow blocks will be removed.
The remaining portion, that is, the IP header, TCP header and Data, now called an
IP Datagram, will be passed to the 3rd OSI layer (Network) where another check
will be performed and if found to be error free, the IP header will be stripped and
the rest (now called a Segment) is passed to the 4th OSI layer.
The TCP protocol (4th OSI layer) will accept the segment and perform its own
error check on the segment. Assuming it is found error free, the TCP header is
stripped off and remaining data is given to the upper layers eventually arriving at
the application waiting for it.
 Sliding Window Flow
Control
Advertised window

1 2 3 4 5 6 7 8 9 10 11

sent and sent but not

acknowledged acknowledged can be sent
USABLE
WINDOW can't sent

Here: Sender can transmit sequence numbers

6,7,8.
 Sliding Window Flow Control
Sliding Window Protocol is performed at the byte level:

Advertised window

1 2 3 4 5 6 7 8 9 10 11

sent and sent but not

acknowledged acknowledged can be sent
USABLE
WINDOW can't sent

Here: Sender can transmit sequence numbers 6,7,8.

47
 Sliding Window: Window Closes
Transmission of a single byte (with SeqNo = 6) and acknowledgement is
received (AckNo = 5, Win=4):

1 2 3 4 5 6 7 8 9 10 11

Transmit Byte 6

1 2 3 4 5 6 7 8 9 10 11

AckNo = 5, Win = 4
is received

1 2 3 4 5 6 7 8 9 10 11

48
 Sliding Window: Window Opens
Acknowledgement is received that enlarges the window to the right (AckNo
= 5, Win=6):

1 2 3 4 5 6 7 8 9 10 11

AckNo = 5, Win = 6
is received

1 2 3 4 5 6 7 8 9 10 11

A receiver opens a window when TCP buffer empties (meaning that data is
delivered to the application).

49
 Sliding Window: Window Shrinks
Acknowledgement is received that reduces the window from the right
(AckNo = 5, Win=3):

1 2 3 4 5 6 7 8 9 10 11

AckNo = 5, Win = 3
is received

1 2 3 4 5 6 7 8 9 10 11

Shrinking a window should not be used

50
 TCP Timers
TCP maintains four (4) timers for each
connection:
Retransmission Timer:
The timer is started during a transmission. A timeout
causes a retransmission
Persist Timer
Ensures that window size information is transmitted even if
no data is transmitted
Keepalive Timer
Detects crashes on the other end of the connection
2MSL Timer
Measures the time that a connection has been in the
TIME_WAIT state
51
 Retransmission timer

TCP starts a retransmission timer when each outbound segment is handed

down to IP.

If no acknowledgment has been received for the data in a given segment

before the timer expires, the segment is retransmitted.

For new connection requests, the retransmission timer is initialized

Persist timer:

If an acknowledgment is lost, we could end up with both sides waiting for the
other: the receiver waiting to receive data (since it provided the sender with
a nonzero window) and the sender waiting to receive the window update
allowing it to send.

To prevent this form of deadlock from occurring the sender uses a

persist timer that causes it to query the receiver periodically, to find
out if the window has been increased.

These segments from the sender are called window probes. In this chapter
we'll examine window probes and the persist timer. We'll also examine the
silly window syndrome, which is tied to the persist timer.
 TCP Keep alive Timer
When a TCP connection has been idle for a long time (1 min 2 hours),
a Keepalive timer reminds a station to check if the other side is still
there.
A segment wihtout data is sent if the connection has been idle for 2
hours
Assume a probe has been sent from A to B:
(1) B is up and running: B responds with an ACK
(2) B has crashed and is down: A will send 10 more probes,
each 75
seconds apart. If A does not get
a response, it will close the

connection

(3) B has rebooted: B will send a RST segment

(4) B is up, but unreachable: Looks to A the same as (2)

54
 Time-Wait (2 MSL) Timer

starts a timer that runs for twice the maximum packet lifetime
the connection is closed after the timer expires, allowing port number
to be reused
 Figure 15.13 State transition diagram

TCP/IP Protocol Suite 58

 Figure 15.15 Time-line diagram for Figure 15.14

1. Enough time for an ACK to be lost

and a new FIN to arrive. If during
the TIME-WAIT state, a new FIN
arrives, the client sends a new ACK
and restarts the 2MSL timer
2. To prevent a duplicate segment
from one connection appearing in
the next one, TCP requires that
incarnation cannot take place
unless 2MSL amount of time has
elapsed.
Another solution: the ISN of the
incarnation is greater than the last
seq. # used in the previous
connection.

TCP/IP Protocol Suite 61

 Figure 15.16 Transition diagram for a common scenario

TCP/IP Protocol Suite 62

 Figure 15.17 Time line for a common scenario

TCP/IP Protocol Suite 63

 Figure 15.18 Simultaneous open

TCP/IP Protocol Suite 64

 Figure 15.19 Simultaneous close

ex

TCP/IP Protocol Suite 65

 Figure 15.20 Denying a connection

TCP/IP Protocol Suite 66

 Figure 15.21 Aborting a connection

TCP/IP Protocol Suite 67

 Figure 15.22 Send window in TCP

TCP/IP Protocol Suite 68

 Figure 15.23 Receive window in TCP

TCP/IP Protocol Suite 69

 Figure 15.24 TCP/IP protocol suite

Messages Flow control

are pushed
1 5 3 Messages
feedback are pulled

2
Segements are pushed
4
Flow control feedback

TCP/IP Protocol Suite 70

 Figure 15.25 An example of flow control

TCP/IP Protocol Suite 71

 Figure 15.26 Example 15.2

TCP/IP Protocol Suite 72

 Figure 15.27 Simplified FSM for sender site

TCP/IP Protocol Suite 73

 Figure 15.28 Simplified FSM for the receiver site

TCP/IP Protocol Suite 74

Rules for Generating ACK
(1)
1. When one end sends a data segment to
the other end, it must include an ACK. That
gives the next sequence number it expects
to receive. (Piggyback)
2. The receiver needs to delay sending
(until another segment arrives or 500ms) an
ACK segment if there is only one
outstanding in-order segment. It prevents
ACK segments from creating extra traffic.
3. There should not be more than 2 in-order
unacknowledged segments at any time. It
prevent the unnecessary retransmission

TCP/IP Protocol Suite 75

Rules for Generating ACK
(2)
4. When a segment arrives with an out-of-
order sequence number that is higher than
expected, the receiver immediately sends
an ACK segment announcing the sequence
number of the next expected segment. (for
fast retransmission)
5. When a missing segment arrives, the
receiver sends an ACK segment to announce
the next sequence number expected.
6. If a duplicate segment arrives, the
receiver immediately sends an ACK.

TCP/IP Protocol Suite 76

 Figure 15.29 Normal operation

TCP/IP Protocol Suite 77

 Figure 15.30 Lost segment

TCP/IP Protocol Suite 78

 Figure 15.31 Fast retransmission

TCP/IP Protocol Suite 79

 Figure 15.32 Lost acknowledgment

TCP/IP Protocol Suite 80

 Figure 15.33 Lost acknowledgment corrected by resending a segment

TCP/IP Protocol Suite 81

TopicsDiscussedintheSection
Retransmission Timer
Persistence Timer
Keepalive Timer
TIME-WAIT Timer

TCP/IP Protocol Suite 82

The primary purpose of TCP is to provide reliable logical circuit or
connection service between pairs of processes.

TCP can be characterized by the following facilities it provides

for the
applications using it
Stream Data Transfer: From the application's viewpoint, TCP
transfers a
contiguous stream of bytes through the network.
TCP does this by grouping the bytes in TCP segments, which
are passed to IP to the destination.
for transmission

Reliability: TCP assigns a sequence number to each byte

transmitted and
expects a positive acknowledgment (ACK) from the receiving TCP.
If the ACK is not received within a timeout interval, the data is
retransmitted.
Flow Control: The receiving TCP, when sending an ACK back to the
sender, also indicates to the sender the number of bytes it can
receive beyond the last received TCP segment, without causing
overrun and overflow in its internal buffers.

This is sent in the ACK in the form of the highest sequence number it
can receive without problems. This mechanism is also referred to as a
Multiplexing: Achieved through the use of ports, just as with UDP.
window-mechanism,

Logical Connections: The reliability and flow control mechanisms

described above require that TCP initializes and maintains certain
status information for each data stream. The combination of this
status, including sockets, sequence numbers and window sizes, is
called a logical connection.

Each connection is uniquely identified by the pair of sockets used by

the sending and receiving processes.

Full Duplex: TCP provides for concurrent data streams in both

directions.
The window principle:
send a packet and then wait for an acknowledgment from the
receiver before sending the next packet. If the ACK is not
received within a certain amount of time, retransmit the packet.
 Now, consider a protocol where the sender groups its packets to be
transmitted, as
in Figure and uses the following rules:
The sender can send all packets within the window without
receiving an ACK, but
must start a timeout timer for each of them.
The receiver must acknowledge each packet received, indicating
the sequence
number of the last well-received packet.
The sender slides the window on each ACK received.
The sender can transmit packets 1 to 5 without waiting for any
acknowledgment:
At the moment the sender receives ACK 1 (acknowledgment for
packet 1), it
can slide its window one packet to the right:
Imagine some special cases:
Packet 2 gets lost: The sender will not receive ACK 2, so its
window will
remain in position 1 .

In fact, since the receiver did not receive packet 2, it will

acknowledge packets 3, 4, and 5 with an ACK 1, since packet 1 was
the last one received in sequence.

At the sender's side, eventually a timeout will occur for packet 2 and
it will be retransmitted.

Note that reception of this packet by the receiver will generate ACK
5, since it has now successfully received all packets 1 to 5, and the
sender's window will slide four positions upon receiving this ACK 5.
Packet 2 did arrive, but the acknowledgment gets lost:
The sender does
not receive ACK 2, but will receive ACK 3. ACK 3 is an
acknowledgment
for all packets up to 3 (including packet 2) and the sender can now
slide its
window to packet 4.
window mechanism ensures:
Reliable transmission.
Better use of the network bandwidth (better throughput).
Flow-control, since the receiver may delay replying to a
packet with an
acknowledgment, knowing its free buffers are available and
the
window-size of the communication.
 The window principle applied to TCP
The above window principle is used in TCP, but with a few
differences:
Since TCP provides a byte-stream connection, sequence numbers
are assigned to
each byte in the stream.

TCP divides this contiguous byte stream into TCP segments to

transmit them.
The window principle is used at the byte level, that is, the
The window
segments sentsize
andisACKs
determined by the receiver when the
connection
received williscarry byte-sequence numbers and the window size is
established
expressed as aand is variable during the data transfer.
number of bytes, rather than a number of packets.
Each ACK message will include the window size that the receiver
is ready to deal with at that particular time.
The sender's data stream can now be seen as follows:

TCP will block bytes into segments, and a TCP segment only
carries the sequence number of the first byte in the
segment.
TCP segment format
 Acknowledgments and retransmissions

TCP sends data in variable length segments. Sequence numbers

are based on a byte count.

Acknowledgments specify the sequence number of the next byte

that the receiver expects to receive.

Consider that a segment gets lost or corrupted. In this case, the

receiver will
acknowledge all further well-received segments with an
acknowledgment referring to the first byte of the missing packet.
The sender will stop transmitting when it has sent all the bytes
in the window. Eventually, a timeout will occur and the missing
segment will be retransmitted.
The sender does know that segment 2 is lost or corrupted, but
does not know anything about segments 3 and 4.

The sender should at least retransmit segment 2, but it could

also retransmit segments 3 and 4 (since they are within the
current window).

It is possible that:
1. Segment 3 has been received, and we do not know about
segment 4. It
could be received, but ACK did not reach us yet, or it could be
lost.

2. Segment 3 was lost, and we received the ACK 1500 upon the
reception of
segment 4.
When discussing TCP Windows, we are most often referring to the TCP
Receive Window.

Simply put, a TCP Receive Window is a buffer on each side of the TCP
connection that temporarily holds incoming data.

The data in this buffer is sent to the application, clearing more room for
incoming data.

If this buffer fills up, the receiver of the data will alert the sender that no more
data can be received until the buffer is cleared.

A device advertises the current size of its TCP Window in the TCP Header
information.
The sender of this packet is telling the other side of the connection that it
has a TCP receive buffer of 65,535 bytes. This is the maximum standard
TCP Window Size. There are options within TCP to make it bigger

Each side of the TCP connection has its own TCP Receive Window. So at
any point, these two windows may be different. For example, a web server
often sends data to users, instead of receiving data from users. For this
reason, a web server doesnt need as large a TCP Window as a user may
need. So the web server may advertise a receive window of 8192 bytes,
while the client has a window of 65,535.
During a file transfer, data is flowing from one machine to another. The receiver
of the data needs to keep its TCP Window from dropping down to zero,
indicating that the windows has filled. If a TCP Window ever goes to zero, or
gets close to zero, this alerts the sender of the data that no more room is left in
the receiver for more data. File transfer will be halted until an update is sent
showing the buffer has been cleared.
Usually there are multiple application processes running on
one host.

For example, a computer may be sending several files

generated by filling in web forms, while at the same time
sending emails.

The network layer only cares about sending a stream of data

out of the computer.

Therefore, the transport layer needs to aggregate data from

different applications into a single stream before passing it to
the network layer.
This is called multiplexing.

Similarly, when the computer receives data from the outside,

the transport layer is again responsible of distributing that
data to different applications such as a web browser or
email client in a process called demultiplexing.
 Transport layer duties

03/12/17 Unit-4 : Transport Layer 118

 Chapters

Chapter 22 Process-to-Process Delivery

Chapter 23 Congestion Control and QoS

03/12/17 Unit-4 : Transport Layer 119

Chapter 22

Process-to-Process
Delivery:
UDP and TCP
03/12/17 Unit-4 : Transport Layer 120
22.1 Process-to-Process Delivery

Client-Server Paradigm

Addressing

Multiplexing and Demultiplexing

Connectionless/Connection-Oriented

Reliable/Unreliable
03/12/17 Unit-4 : Transport Layer 121
 Note:

The transport layer is responsible for

process-to-process delivery.

03/12/17 Unit-4 : Transport Layer 122

 Figure 22.1 Types of data deliveries

03/12/17 Unit-4 : Transport Layer 123

 Figure 22.2 Port numbers

03/12/17 Unit-4 : Transport Layer 124

 Figure 22.3 IP addresses versus port numbers

03/12/17 Unit-4 : Transport Layer 125

 Figure 22.4 IANA ranges

03/12/17 Unit-4 : Transport Layer 126

 Figure 22.5 Socket address

03/12/17 Unit-4 : Transport Layer 127

 Figure 22.6 Multiplexing and demultiplexing

03/12/17 Unit-4 : Transport Layer 128

 Figure 22.7 Connection establishment

03/12/17 Unit-4 : Transport Layer 129

 Figure 22.8 Connection termination

03/12/17 Unit-4 : Transport Layer 130

 Figure 22.9 Error control

03/12/17 Unit-4 : Transport Layer 131

22.2 UDP

Port Numbers

User Datagram

Applications

03/12/17 Unit-4 : Transport Layer 132

 Note:

UDP is a connectionless, unreliable

protocol that has no flow and error
control. It uses port numbers to
multiplex data from the application
layer.

03/12/17 Unit-4 : Transport Layer 133

Table 22.1 Well-known ports used by UDP
Port Protocol Description
7 Echo Echoesareceiveddatagrambacktothesender
9 Discard Discardsanydatagramthatisreceived
11 Users Activeusers
13 Daytime Returnsthedateandthetime
17 Quote Returnsaquoteoftheday
19 Chargen Returnsastringofcharacters
53 Nameserver DomainNameService
67 Bootps Serverporttodownloadbootstrapinformation
68 Bootpc Clientporttodownloadbootstrapinformation
69 TFTP TrivialFileTransferProtocol
111 RPC RemoteProcedureCall
123 NTP NetworkTimeProtocol
161 SNMP SimpleNetworkManagementProtocol
162 SNMP SimpleNetworkManagementProtocol(trap)
03/12/17 Unit-4 : Transport Layer 134
 Figure 22.10 User datagram format

03/12/17 Unit-4 : Transport Layer 135

 Note:

The calculation of checksum and its

inclusion in the user datagram are
optional.

03/12/17 Unit-4 : Transport Layer 136

 Note:

UDP is a convenient transport-layer

protocol for applications that provide
flow and error control. It is also used
by multimedia applications.

03/12/17 Unit-4 : Transport Layer 137

22.3 TCP

Port Numbers
Services
Sequence Numbers
Segments
Connection
Transition Diagram
Flow and Error Control
Silly Window Syndrome
03/12/17 Unit-4 : Transport Layer 138
Table 22.2 Well-known ports used by TCP
Port Protocol Description
7 Echo Echoesareceiveddatagrambacktothesender
9 Discard Discardsanydatagramthatisreceived
11 Users Activeusers
13 Daytime Returnsthedateandthetime
17 Quote Returnsaquoteoftheday
19 Chargen Returnsastringofcharacters
20 FTP,Data FileTransferProtocol(dataconnection)
21 FTP,Control FileTransferProtocol(controlconnection)
23 TELNET TerminalNetwork
25 SMTP SimpleMailTransferProtocol
53 DNS DomainNameServer
67 BOOTP BootstrapProtocol
79 Finger Finger
80 HTTP HypertextTransferProtocol
111 RPC RemoteProcedureCall
03/12/17 Unit-4 : Transport Layer 139
 Figure 22.11 Stream delivery

03/12/17 Unit-4 : Transport Layer 140

 Figure 22.12 Sending and receiving buffers

03/12/17 Unit-4 : Transport Layer 141

 Figure 22.13 TCP segments

03/12/17 Unit-4 : Transport Layer 142

Example 1
Imagine a TCP connection is transferring a file of 6000 bytes. The
first byte is numbered 10010. What are the sequence numbers for
each segment if data are sent in five segments with the first four
segments carrying 1000 bytes and the last segment carrying 2000
bytes?

Solution
The following shows the sequence number for each segment:
Segment 1 ==> sequence number: 10,010 (range: 10,010 to
11,009)
Segment 2 ==> sequence number: 11,010 (range: 11,010 to
12,009)
Segment 3==> sequence number: 12,010 (range: 12,010 to
13,009)
Segment 4==> sequence number: 13,010 (range: 13,010 to
14,009)
03/12/17 Unit-4 : Transport Layer 143
Segment 5==> sequence number: 14,010 (range: 14,010 to
 Note:

The bytes of data being transferred in

each connection are numbered by
TCP. The numbering starts with a
randomly generated number.

03/12/17 Unit-4 : Transport Layer 144

 Note:

The value of the sequence number

field in a segment defines the number
of the first data byte contained in that
segment.

03/12/17 Unit-4 : Transport Layer 145

 Note:

The value of the acknowledgment field

in a segment defines the number of the
next byte a party expects to receive.
The acknowledgment number is
cumulative.

03/12/17 Unit-4 : Transport Layer 146

 Figure 22.14 TCP segment format

03/12/17 Unit-4 : Transport Layer 147

 Figure 22.15 Control field

03/12/17 Unit-4 : Transport Layer 148

Table 22.3 Description of flags in the control field

Flag Description

URG Thevalueoftheurgentpointerfieldisvalid.

ACK Thevalueoftheacknowledgmentfieldisvalid.

PSH Pushthedata.

RST Theconnectionmustbereset.

SYN Synchronizesequencenumbersduringconnection.

FIN Terminatetheconnection.

03/12/17 Unit-4 : Transport Layer 149

 Figure 22.16 Three-step connection establishment

03/12/17 Unit-4 : Transport Layer 150

 Figure 22.17 Four-step connection termination

03/12/17 Unit-4 : Transport Layer 151

Table 22.4 States for TCP

State Description

CLOSED Thereisnoconnection.
LISTEN Theserveriswaitingforcallsfromtheclient.

SYNSENT Aconnectionrequestissent;waitingforacknowledgment.

SYNRCVD Aconnectionrequestisreceived.
ESTABLISHED Connectionisestablished.

FINWAIT1 Theapplicationhasrequestedtheclosingoftheconnection.

FINWAIT2 Theothersidehasacceptedtheclosingoftheconnection.

TIMEWAIT Waitingforretransmittedsegmentstodie.
CLOSEWAIT Theserveriswaitingfortheapplicationtoclose.
LASTACK Theserveriswaitingforthelastacknowledgment.
03/12/17 Unit-4 : Transport Layer 152
 Figure 22.18 State transition diagram

03/12/17 Unit-4 : Transport Layer 153

 Note:

A sliding window is used to make

transmission more efficient as well as
to control the flow of data so that the
destination does not become
overwhelmed with data. TCPs sliding
windows are byte-oriented.

03/12/17 Unit-4 : Transport Layer 154

 Figure 22.19 Sender buffer

03/12/17 Unit-4 : Transport Layer 155

 Figure 22.20 Receiver window

03/12/17 Unit-4 : Transport Layer 156

 Figure 22.21 Senderbufferandsenderwindow

03/12/17 Unit-4 : Transport Layer 157

 Figure 22.22 Sliding the sender window

03/12/17 Unit-4 : Transport Layer 158

 Figure 22.23 Expanding the sender window

03/12/17 Unit-4 : Transport Layer 159

 Figure 22.24 Shrinking the sender window

03/12/17 Unit-4 : Transport Layer 160

 Note:

In TCP, the sender window size is

totally controlled by the receiver
window value (the number of empty
locations in the receiver buffer).
However, the actual window size can
be smaller if there is congestion in the
network.
03/12/17 Unit-4 : Transport Layer 161
 Note:

Some points about TCPs sliding windows:

The source does not have to send a full
windows worth of data.

The size of the window can be increased or

decreased by the destination.

The destination can send an acknowledgment

at any time.

03/12/17 Unit-4 : Transport Layer 162

 Figure 22.25 Lost segment

03/12/17 Unit-4 : Transport Layer 163

 Figure 22.26 Lost acknowledgment

03/12/17 Unit-4 : Transport Layer 164

 Figure 22.27 TCP timers

03/12/17 Unit-4 : Transport Layer 165

 Client-Server
Model:
Socket Interface
03/12/17 Unit-4 : Transport Layer 166
24.1 Client-Server Model

Relationship

Concurrency

Processes

03/12/17 Unit-4 : Transport Layer 167

 Figure 24.1 Client-server model

03/12/17 Unit-4 : Transport Layer 168

 Figure 24.2 Client-server relationship

03/12/17 Unit-4 : Transport Layer 169

 Figure 24.3 Connectionless iterative server

03/12/17 Unit-4 : Transport Layer 170

 Figure 24.4 Connection-oriented concurrent server

03/12/17 Unit-4 : Transport Layer 171

24.2 Socket Interface

Sockets

Connectionless Iterative Server

Connection-Oriented Server

03/12/17 Unit-4 : Transport Layer 172

 Figure 24.5 Socket structure

03/12/17 Unit-4 : Transport Layer 173

 Figure 24.6 Socket types

03/12/17 Unit-4 : Transport Layer 174

 Figure 24.7 Socket interface for connectionless iterative server

03/12/17 Unit-4 : Transport Layer 175

 Figure 24.8 Socket interface for connection-oriented concurrent server

03/12/17 Unit-4 : Transport Layer 176

 Congestion Control
and
Quality of Service

03/12/17 Unit-4 : Transport Layer 177

23.2 Congestion

Network Performance

03/12/17 Unit-4 : Transport Layer 178

 Figure 23.5 Incoming packet

03/12/17 Unit-4 : Transport Layer 179

 Figure 23.6 Packet delay and network load

03/12/17 Unit-4 : Transport Layer 180

 Figure 23.7 Throughput versus network load

03/12/17 Unit-4 : Transport Layer 181

23.3 Congestion Control

Open Loop

Closed Loop

03/12/17 Unit-4 : Transport Layer 182

23.4 Two Examples

Congestion Control in TCP

Congestion Control in Frame Relay

03/12/17 Unit-4 : Transport Layer 183

 Note:

TCP assumes that the cause of a lost

segment is due to congestion
in the network.

03/12/17 Unit-4 : Transport Layer 184

 Note:

If the cause of the lost segment is

congestion, retransmission of the
segment does not remove
the causeit aggravates it.

03/12/17 Unit-4 : Transport Layer 185

 Figure 23.8 Multiplicative decrease

03/12/17 Unit-4 : Transport Layer 186

 Figure 23.9 BECN

03/12/17 Unit-4 : Transport Layer 187

 Figure 23.10 FECN

03/12/17 Unit-4 : Transport Layer 188

 Figure 23.11 Four cases of congestion

03/12/17 Unit-4 : Transport Layer 189

23.5 Quality of Service

Flow Characteristics

Flow Classes

03/12/17 Unit-4 : Transport Layer 190

23.6 Techniques to Improve QoS

Scheduling

Traffic Shaping

Resource Reservation

Admission Control

03/12/17 Unit-4 : Transport Layer 191

 Figure 23.12 Flow characteristics

03/12/17 Unit-4 : Transport Layer 192

 Figure 23.13 FIFO queue

03/12/17 Unit-4 : Transport Layer 193

 Figure 23.14 Priority queuing

03/12/17 Unit-4 : Transport Layer 194

 Figure 23.15 Weighted fair queuing

03/12/17 Unit-4 : Transport Layer 195

 Figure 23.16 Leaky bucket

03/12/17 Unit-4 : Transport Layer 196

 Figure 23.17 Leaky bucket implementation

03/12/17 Unit-4 : Transport Layer 197

 Note:

A leaky bucket algorithm shapes

bursty traffic into fixed-rate traffic by
averaging the data rate. It may drop
the packets if the bucket is full.

03/12/17 Unit-4 : Transport Layer 198

 Figure 23.18 Token bucket

03/12/17 Unit-4 : Transport Layer 199

 Note:

The token bucket allows bursty traffic

at a regulated maximum rate.

03/12/17 Unit-4 : Transport Layer 200