Connection Oriented Versus

Connectionless service
Sr. Parameters Connection oriented Connectionless
No.

1. Reservation of Necessary Not necessary

resources

2. Utilization of resources Less Good

3. State information Lot of information Not much information is
required required to be stored

4. Guarantee of service Guaranteed No guarantee

5. Connection Connection needs to be Connection need not be
established established

6. Delays More Less

7. Overheads Less More
8. Packet travel Sequentially Randomly
9. Congestion due to Not possible Very much possible
overloading
How demultiplexing work?
 Reliable Vs. Unreliable
• If the application layer program needs reliable
transport layer protocol is used by implementing
the flow and error control at the transport layer.
• But this service will be slow and more complex.
• But if the application layer program does not
need reliability because it uses its own flow and
error control mechanism, then an unreliable
service is used.
• UDP is connectionless protocol and unreliable,
but TCP is connection oriented and reliable
protocol.
UDP: User Datagram Protocol [RFC 768]
• What is a connectionless protocol?

– The device sending a message simply sends it

addressed to the intended recipient.
– If there are problems with the transmission, it may
be necessary to resend the data several times.
– The Internet Protocol (IP) and User
Datagram Protocol (UDP) are connectionless
protocols.
UDP: User Datagram Protocol [RFC 768]
• The User Datagram Protocol offers only a
minimal transport service -- non-guaranteed
datagram delivery -- and gives applications
direct access to the datagram service of the IP
layer.
• UDP is almost a null protocol; the only services
it provides over IP are check summing of data
and multiplexing by port number.
• UDP is a standard protocol with STD number 6.
• An application program running over UDP must deal
directly with end-to-end communication problems
that a connection-oriented protocol would have
handled -- e.g., retransmission for reliable delivery,
packetization and reassembly, flow control,
congestion avoidance, etc., when these are required.
• The service provided by UDP is an unreliable service
that provides no guarantees for delivery and no
protection from duplication.
• Compared to other transport protocols, UDP and
its UDP-Lite variant are unique in that they do not
establish end-to-end connections between
communicating end systems.
The UDP header contains four fields :
a 16 bits source port
a 16 bits destination port
a 16 bits length field
a 16 bits checksum
• UDP is basically an application interface to IP. It adds no
reliability, flow-control, or error recovery to IP. It simply
serves as a multiplexer/demultiplexer for sending and
receiving datagrams, using ports to direct the
datagrams.
• UDP provides a mechanism for one application to send a
datagram to another.
• Be aware that UDP and IP do not provide guaranteed
delivery, flow-control, or error recovery, so these must
be provided by the application.
• Standard applications using UDP include:

– Trivial File Transfer Protocol (TFTP)

– Domain Name System (DNS) name server
– Remote Procedure Call (RPC), used by the Network
File System (NFS)
– Simple Network Management Protocol (SNMP)
– Lightweight Directory Access Protocol (LDAP)
Message Header Format for UDP
 Field Description
Source Port UDP packets from a client use this as a service access
point (SAP) to indicate the session on the local client
that originated the packet. UDP packets from a server
carry the server SAP in this field
Destination UDP packets from a client use this as a service access
Port point (SAP) to indicate the service required from the
remote server. UDP packets from a server carry the
client SAP in this field
UDP length The number of bytes comprising the combined UDP
header information and payload data
UDP A checksum to verify that the end to end data has not
Checksum been corrupted by routers or bridges in the network or
by the processing in an end system.
 UDP checksum
• Goal: detect “errors” (e.g., flipped bits) in
transmitted segment
Sender: Receiver:
• treat segment contents as • compute checksum of
sequence of 16-bit received segment
integers
• check if computed checksum
• checksum: addition (1’s
complement sum) of equals checksum field value:
segment contents – NO - error detected
• sender puts checksum – YES - no error detected.
value into UDP checksum But maybe errors
field nonetheless? More later
….
 Internet Checksum Example
• Note
– When adding numbers, a carryout from the
most significant bit needs to be added to the
result
• Example: add two 16-bit integers

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
 Fields Description
4 bits of the version of IP currently used, the ip version is 4
iph_ver
(other version is IPv6).
4 bits, the ip header (datagram) length in 32 bits octets (bytes)
that point to the beginning of the data. The minimum value
iph_ihl
for a correct header is 5. This means a value of 5 for
the iph_ihl means 20 bytes (5 * 4).
iph_tos 8 bits, type of service controls the priority of the packet.
The total is 16 bits; total length must contain the total length
iph_len of the ip datagram (ip and data) in bytes. This includes ip
header, icmp or tcp or udp header and payload size in bytes.
The iph_ident sequence number is mainly used for
iph_ident
reassembly of fragmented IP datagrams.
Consists of a 3-bit field of which the two low-order (least-
significant) bits control fragmentation. The low-order bit
specifies whether the packet can be fragmented. The middle
iph_flag
bit specifies whether the packet is the last fragment in a series
of fragmented packets. The third or high-order bit is not
 Fields Description
The fragment offset is used for reassembly of fragmented
datagrams. The first 3 bits are the fragment flags, the first one
ihp_offset always 0, the second the do-not-fragment bit (set by ihp_offset =
0x4000) and the third the more-flag or more-fragments-following
bit (ihp_offset = 0x2000).
8 bits, time to live is the number of hops (routers to pass) before
iph_ttl the packet is discarded, and an icmp error message is
returned. The maximum is 255.
8 bits, the transport layer protocol. It can be tcp (6), udp (17),
iph_protocol
icmp (1), or whatever protocol follows the ip header.
iph_chksu
16 bits, a checksum on the header only, the ip datagram.
m
iph_source 32 bits, source IP address. It is converted to long format.
32 bits, destination IP address, converted to long format, e.g.
iph_dest
by inet_addr().
Options Variable.
Variable. The internet header padding is used to ensure that the
Padding
internet header ends on a 32 bit boundary.
 Ports and sockets
• This section introduces the concepts of port and socket, which are
needed to determine which local process at a given host actually
communicates with which process, at which remote host, using
which protocol. If this sounds confusing, consider the following:

– An application process is assigned a process identifier number

(process ID), which is likely to be different each time that process is
started.
– Process IDs differ between operating system platforms, hence they
are not uniform.
– A server process can have multiple connections to multiple clients at
a time, hence simple connection identifiers would not be unique.

• The concept of ports and sockets provides a way to uniformly and

uniquely identify connections and the programs and hosts that are
engaged in them, irrespective of specific process IDs.
• Ports:
• Each process that wants to communicate with another process
identifies itself to the TCP/IP protocol suite by one or more
ports.
• A port is a 16-bit number, used by the host-to-host protocol to
identify to which higher level protocol or application program
(process) it must deliver incoming messages. There are two
types of port:
– Well-known:
• Well-known ports belong to standard servers, for example,
Telnet uses port 23. Well-known port numbers range
between 1 and 1023.
• Well-known port numbers are typically odd, because early
systems using the port concept required an odd/even pair of
ports for duplex operations.
– Ephemeral:
• Clients do not need well-known port numbers because they
initiate communication with servers and the port number
they are using is contained in the UDP datagram sent to the
server.
• Ephemeral port numbers have values greater than 1023,
normally in the range 1024 to 65535. A client can use any
number allocated to it, as long as the combination of
<transport protocol, IP address, port number> is unique.
• Sockets:
– The socket interface is one of several application
programming interfaces (APIs) to the communication
protocols. Designed to be a generic communication
programming interface, APIs were first introduced by 4.2
BSD.
– 4.2 BSD allowed two different communication domains:
Internet and UNIX.
– 4.3 BSD has added the Xerox Network System (XNS)
protocols,
– 4.4 BSD will add an extended interface to support the ISO
OSI protocols.
– A socket address is the triple:
<protocol, local-address, local-process>
– For example, in the TCP/IP suite:
<tcp, 193.44.234.3, 12345>
 Principles of Reliable data transfer
• Making sure that the packets sent by the sender are
correctly and reliably received by the receiver amid
network errors, i.e., corrupted/lost packets.
– Can be implemented at LL, NL or TL of the protocol stack.

• When and why should this be used?

– Link Layer
• Rarely done over twisted-pair or fiber optic links
• Usually done over lossy links (wireless) for performance improvement
(versus correctness) in P2P links
– Network/Transport Layers
• Necessary if the application requires the data to be reliably delivered
to the receiver, e.g., file transfer
 Reliable Delivery: Service Model
… 4 3 2 1
… 4 3 2 1

RDT_Send Deliver_Data

Reliable Data Transfer Reliable Data Transfer

Protocol (Sender Side) Protocol (Receiver Side)
UDT_Send RDT_Receive
unreliable channel
Reliable, In-order Delivery

– Reliable, In-order delivery

• Typically done when reliability is implemented at the
transport layer, e.g., TCP
• Example application: File transfer
 Reliable Delivery: Assumptions
We’ll:
• Consider only unidirectional data transfer
– A sender sending packets to a receiver
– Bidirectional communication is a simple extension,
where there are 2 sender/receiver pairs

• Start with simple a protocol and make it

complex as we continue
 RDT over Unreliable Channel
… 4 3 2 1
… 4 3 2 1

RDT_Send Deliver_Data

Reliable Data Transfer Reliable Data Transfer

Protocol (Sender Side) Protocol (Receiver Side)
UDT_Send RDT_Receive
Unreliable channel

• Channel may flip bits in packets/lose packets

– The received packet may have been corrupted during
transmission, or dropped at an intermediate router due to
buffer overflow

• The question: how to recover from errors?

• ACKs, NACKs, Timeouts… Next
 RDT over Unreliable Channel
• Two fundamental mechanisms to accomplish
reliable delivery over Unreliable Channels
– Acknowledgements (ACK), Negative ACK (NACK)
• Small control packets (header without any data) that a
protocol sends back to its peer saying that it has received an
earlier packet (positive ACK) or that it has not received a
packet (NACK) Sent by the receiver to the sender.
– Timeouts
• Set by the sender for each transmitted packet
• If an ACK is received before the timer expires, then the
packet has made it to the receiver
• If the timeout occurs, the sender assumes that the packet is
lost (corrupted) and retransmits the packet
 ARQ
• Automatic repeat request (ARQ) is a protocol for
error control in data transmission. When the
receiver detects an error in a packet, it automatically
requests the transmitter to resend the packet.
• The general strategy of using ACKs (NACKs) and
timeouts to implement reliable delivery is called
Automatic Repeat reQuest (ARQ)

• 3 ARQ Mechanisms for Reliable Delivery

– Stop and Wait
– Concurrent Logical Channels
– Sliding Window
 Stop and Wait
• Simplest ARQ protocol
• Sender:
Sender Receiver
– Send a packet
– Stop and wait until an ACK

Timeout
arrives Time
– If received ACK, send the
next packet
– If timeout, Retransmit the
same packet
• Receiver:
– When you receive a packet
correctly, send an ACK
• Stop and wait with ARQ: Automatic Repeat reQuest
(ARQ), an error control method, is incorporated with stop
and wait flow control protocol.
– If error is detected by receiver, it discards the frame and send
a negative ACK (NAK), causing sender to re-send the frame
– In case a frame never got to receiver, sender has a timer:
each time a frame is sent, timer is set
→ If no ACK or NAK is received during timeout period, it
re-sends the frame
– Timer introduces a problem: Suppose timeout and sender
retransmits a frame but receiver actually received the
previous transmission → receiver has duplicated copies
– To avoid receiving and accepting two copies of same frame,
frames and ACKs are alternatively labeled 0 or 1: ACK0 for
frame 1, ACK1 for frame 0
An important link parameter is defined by

where ,
 R is data rate (bps), d is link distance (m), V is propagation
velocity (m/s) and L frame length (bits)
 In error-free case, efficiency or maximum link utilization of stop
and Wait with ARQ is:
 Recovering from Error
Timeout

Timeout

Timeout
Time
Timeout

Timeout

Timeout
Packet lost ACK lost Early timeout

• Does this protocol work?

• When an ACK is lost or a early timeout occurs, how does the receiver
know whether the packet is a retransmission or a new packet?
– Use sequence numbers: Both Packets and ACKs
 Stop & Wait with Seq #s
Timeout

Timeout

Timeout
Time
Timeout

Timeout

Timeout
Packet lost ACK lost Early timeout
 Performance of Stop and Wait
• Can only send one packet per round trip
• network protocol limits use of physical resources!
sender receive
first packet bit transmitted, t = 0 r
last packet bit transmitted, t = L / R

first packet bit arrives

RTT last packet bit arrives, send
ACK

ACK arrives, send next

packet, t = RTT + L / R

U L/R .008
= 0.027%
= = = 0.00027
sender 30.008
RTT + L / R microsec microsec
onds onds
 Pipelining: Increasing Utilization
• Pipelining: sender allows multiple, “in-flight”, yet-to-be-
acknowledged pkts without waiting for first to be ACKed to keep
the pipe full
– Capacity of the Pipe = RTT * BW
sender receiver
first packet bit transmitted, t = 0
last bit transmitted, t = L / R

first packet bit arrives

RTT last packet bit arrives, send ACK
last bit of 2nd packet arrives, send ACK
last bit of 3rd packet arrives, send ACK
ACK arrives, send next
packet, t = RTT + L / R

Increase utilization
by a factor of 3!

U 3*L/R .024
sender
= = = 0.0008
RTT + L / R 30.008 microsecon
 Sliding Window Protocols
• Reliable, in-order delivery of packets
• Sender can send “window” of up to N,
consecutive unack’ed packets
• Receiver makes sure that the packets are
delivered in-order to the upper layer

• 2 Generic Versions
– Go-Back-N
– Selective Repeat
• For large link parameter a, stop and wait protocol is inefficient.
• A universally accepted flow control procedure is the sliding
window protocol.
– Frames and acknowledgements are numbered using sequence
numbers
– Sender maintains a list of sequence numbers (frames) it is allowed
to transmit, called sending window
– Receiver maintains a list of sequence numbers it is prepared to
receive, called receiving window
– A sending window of size N means that sender can send up to N
frames without the need for an ACK
– A window size of N implies buffer space for N frames
– For n-bit sequence number, we have 2n numbers: 0, 1, · · · , 2n − 1,
but the maximum window size N = 2n− 1 (not 2n)
– ACK3 means that receiver has received frame 0 to frame 2
correctly, ready to receive frame 3 (and rest of N frames within
window)
• In error-free case, efficiency or maximum link
utilization of sliding window protocol is:

• Thus it is able to maintain efficiency for large link

parameter a: just use large widow size N.
• Note that U = 1 means that link has no idle time: there
are always something in it, either data frames or ACKs.
 Continue…
• What should be the size of pipeline?
• How do we handle errors:
– Sender and receiver maintain buffer space
– Receiver window = 1,
– Sender window = n
• Consider the case of 3-bit sequence number
with maximum window size N = 7.
• This illustration shows that Sending and
receiving windows can shrink or grow during
operation.
• The receiver do not need to acknowledge every
frames.
• If both sending and receiving window sizes are N
= 1, the sliding window protocol reduces to the
stop-and-wait.
• In practice, error control must be incorporated
with flow control, and we next discuss two
common error control mechanisms.
 Sliding Window:
Generic Sender/Receiver States
Sender Receiver

Last ACK Received Last Packet Sent Next Packet Expected Last Packet Acceptable
(LAR) (LPS) (NPE) (LPA)

… … … …

Sender Window Size Receiver Window Size

Sent & Acked Sent Not Acked Received & Acked Acceptable Packet

OK to Send Not Usable Not Usable

 Sliding Window- Sender Side
• The sender maintains 3 variables
– Sender Window Size (SWS)
• Upper bound on the number of in-flight packets
– Last Acknowledgement Received (LAR)
– Last Packet Sent (LPS)
– We want LPS – LAR <= SWS
<= SWS

LAR LPS
 Sliding Window- Receiver Side
• The receiver maintains 3 variables
– Receiver Window Size (RWS)
• Upper bound on the number of buffered packets
– Last Packet Acceptable (LPA)
– Next Packet Expected (NPE)
– We want LPS – NPE + 1 <= RWS
<= RWS

NPE LPA
 Go-back-n ARQ
• The basic idea of go-back-n error control is: If
frame i is damaged, receiver requests
retransmission of all frames starting from frame i
• An example:
• Notice that all possible cases of damaged frame
and ACK / NAK must be taken into account
• For n-bit sequence number, maximum window
size is N = 2n − 1 not N = 2n → with N = 2n
• Consider n = 3, if N = 8 what may happen:
• Suppose that sender transmits frame 0 and gets an ACK1
• It then transmits frames 1,2,3,4,5,6,7,0 (this is allowed, as
they are within the sending window of size 8) and gets
another ACK1
• This could means that all eight frames were received
correctly
• It could also mean that all eight frames were lost, and
receiver is repeating its previous ACK1
• With N = 7, this confusing situation is avoided
 Sender Receiver
Last ACK Received Last Packet Sent Next Packet Expected Last Packet Acceptable
(LAR) (LPS) (NPE) (LPA)

… … … …

SWS = N
RWS = 1 packet

Sent & Acked Sent Not Acked Received & Acked Acceptable Packet

OK to Send Not Usable Not Usable

• SWS = N: Sender can send up to N consecutive unack’ed pkts

• RWS = 1: Receiver has buffer for just 1 packet
• Always sends ACK for correctly-rcvd pkt with highest in-order seq #
– Cumulative ACK
– discard & re-ACK pkt with highest in-order seq #
• Out-of-order pkt:
Timeout:
Retransmit ALL packets that have been previously sent, but not yet ACKed
Therefore the name Go-Back-N
GBN in action (SWS = 4)
• Why use GBN?
– Very simple receiver

• Why NOT use GBN?

– Throwing away out-of-order packets at the receiver
results in extra transmissions, thus lowering the
channel utilization:
• The channel may become full of retransmissions of old
packets rather than useful new packets
– Can we do better?
• Yes: Buffer out-of-order packets at the receiver and do
Selective Repeat (Retransmissions) at the sender
 Selective-Reject ARQ
• In selective-reject ARQ error control, the only
frames retransmitted are those receive a NAK or
which time out.
• An illustrative example:
• Selective-reject would appear to be more
efficient than go-back-n, but it is harder to
implement and less used
• The window size is also more restrictive: for n-bit
sequence number, the maximum window size is
N = 2n/2 to avoid possible confusion
• Go-back-n and selective-reject can be seen as
trade-offs between link bandwidth (data rate)
and data link layer buffer space.
– If link bandwidth is large but buffer space is scarce,
go-back-n is preferred
– If link bandwidth is small but buffer space is pretty,
selective-reject is preferred
 Sender Receiver
Last ACK Received Last Packet Sent Next Packet Expected Last Packet Acceptable
(LAR) (LPS) (NPE) (LPA)

… … … …

SWS = N RWS = N

Sent & Acked Sent Not Acked Received & Acked Acceptable Packet

OK to Send Not Usable Not Usable

• SWS = RWS = N consecutive packets: Sender can send up to N

consecutive unack’ed pkts, Receiver can buffer up to N consecutive packets
• Receiver individually acknowledges all correctly received pkts
– buffers pkts, as needed, for eventual in-order delivery to upper layer
• Sender only resends pkts for which ACK not received
– sender timer for each unACKed pkt
Selective repeat in action
 Transmission Control Protocol (TCP)
• The Transmission Control Protocol (TCP) is a connection-
oriented reliable protocol.

• It provides a reliable transport service between pairs of

processes executing on End Systems (ES) using the network
layer service provided by the IP protocol.

• The Transmission Control Protocol (TCP) was initially

defined in RFC 793.

• TCP is a standard protocol with STD number 7.

• TCP is used by a large number of applications,
including :
– Email (SMTP, POP, IMAP)
– World wide web ( HTTP, ...)
– Most file transfer protocols ( ftp, peer-to-peer file
sharing applications , ...)
– remote computer access : telnet, ssh, X11, VNC, ...
– non-interactive multimedia applications : flash
 Connection-Oriented Service
• In a connection oriented service, a connection
is established between source and
destination.
• Then the data is transferred and at the end
the connection is released.
 Connection Establishment

Three protocol scenarios for establishing a connection using a three-way handshake.

CR denotes CONNECTION REQUEST.
(a) Normal operation,
(b) Old CONNECTION REQUEST appearing out of nowhere.
(c) Duplicate CONNECTION REQUEST and duplicate ACK.
 Handshaking Protocol
• handshaking is an automated process of negotiation that
dynamically sets parameters of a communications channel
established between two entities before normal
communication over the channel begins.
• It follows the physical establishment of the channel and
precedes normal information transfer.
• The handshaking process usually takes place in order to
establish rules for communication when a computer sets about
communicating with a foreign device.
• When a computer communicates with another device like a
modem, printer, or network server, it needs to handshake with
it to establish a connection.
• A simple handshaking protocol might only involve
the receiver sending a message meaning "I received
your last message and I am ready for you to send me
another one."
• A more complex handshaking protocol might allow
the sender to ask the receiver if it is ready to receive
or for the receiver to reply with a negative
acknowledgement meaning "I did not receive your
last message correctly, please resend it"
Two Way Handshaking Protocol
Two Army Problem
• Protocol 1: two way handshake:
• Chief of blue army 1 sends a message to the chief of
blue army 2 stating “I propose we attack in the morning
of January 1. Is it OK with you?”.
• Suppose that the messenger reaches to blue army 2 and
the chief of blue army 2 agrees with the idea.
• He sends the message “yes” back army 1 and assume
that this message also gets through.
• This process is called two way handshake and it is shown
in fig.(a).
• The question is will the attack take place? The answer is
probably not because the chief of blue army 2 does not
know whether his reply got through.
Blue army 1 Blue army 2 Blue army 1 Blue army 2

Message 1 Message 1

Message 2

Message 3
Acknowledgement
message 1

Time Time

(a) Two way handshake (b) Three way handshake

 Three Way Handshaking Protocol
• Now let us improve the two way handshake protocol
by making it a three way handshake.
• Assuming no messages lost, blue army – 2 will gets
the acknowledgement.
• But now the chief of blue army – 1 will hesitate,
because he does not know if the last message he has
sent has got through or not.
• So we can make a four way handshake. But it also
does not help, because in every protocol, the
uncertainty after last handshake message always
remains.
• A three-way-handshake is a method used in a TCP/IP
network to create a connection between a local host/client
and server.

EVENT DIAGRAM

Host A sends a TCP SYNchronize packet to Host B

Host B receives A's SYN
Host B sends a SYNchronize ACKnowledgement
Host A receives B's SYN-ACK
Host A sends ACKnowledge
Host B receives ACK.
TCP socket connection is ESTABLISHED.
• 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.
– The application does not have to bother with
chopping the data into basic blocks or datagrams.
– TCP does this by grouping the bytes in TCP segments,
which are passed to IP for transmission to the
destination.
– Reliability:
– CP 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.
– Since the data is transmitted in blocks (TCP
segments), only the sequence number of the first
data byte in the segment is sent to the destination
host.
– The receiving TCP uses the sequence numbers to
rearrange the segments when they arrive out of
order, and to eliminate duplicate segments.
– 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.

– Multiplexing:
– Achieved through the use of ports, just as with UDP.
– 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.
TCP segment format
• Source Port: The 16-bit source port number, used by the receiver to
reply.
• Destination Port: The 16-bit destination port number.
• Sequence Number: The sequence number of the first data byte in
this segment. If the SYN control bit is set, the sequence number is the
initial sequence number (n) and the first data byte is n+1.
• Acknowledgment Number: If the ACK control bit is set, this field
contains the value of the next sequence number that the receiver is
expecting to receive.
• Data Offset: The number of 32-bit words in the TCP header. It
indicates where the data begins.
• Reserved: Six bits reserved for future use; must be zero.
• URG: Indicates that the urgent pointer field is significant in this
segment.
• ACK: Indicates that the acknowledgment field is significant in this
segment.
• PSH: Push function.
• RST: Resets the connection.
• SYN: Synchronizes the sequence numbers.
• FIN: No more data from sender.
• Window: Used in ACK segments. It specifies the number of
data bytes
• Checksum: The 16-bit one's complement of the one's
complement sum of all 16-bit words in a pseudo-header, the
TCP header, and the TCP data.
• Urgent Pointer: Points to the first data octet following the
urgent data. Only significant when the URG control bit is set.
• Options: Just as in the case of IP datagram options, options
can be either:
– A single byte containing the option number
– A variable length option
• Padding: All zero bytes are used to fill up the TCP header to a
total length that is a multiple of 32 bits.
 The window principle
• A trivial transport protocol is:
– send a packet and then wait for an ACK from the
receiver before sending the next packet;
– if the ACK is not received within a certain amount of
time, retransmit the packet.

• While this mechanism ensures reliability, it only

uses a part of the available network bandwidth.
• Now, consider a protocol where the sender
groups its packets to be transmitted:

– 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 window principle
• If packet 2 is lost, the
receiver does not
acknowledge the
reception of
subsequent data
messages.
• The sender re-
transmits
unacknowledged
messages after a
timeout expires.
• The window principle is used in TCP, but:

– the window principle is used at the byte level,

that is, the segments sent and ACKs received
carry byte-sequence numbers and the window
size is expressed as a number of bytes;

– the window size is determined by the receiver

when the connection is established and is
variable during the data transfer.
The window principle
 Congestion control
• The TCP congestion control scheme was initially
proposed by Van Jacobson in [Jacobson1988].
• Essential strategy :: The TCP host sends packets into the
network without a reservation and then the host reacts
to observable events.
• Originally TCP assumed FIFO queuing.
• Basic idea :: each source determines how much capacity
is available to a given flow in the network.
• ACKs are used to ‘pace’ the transmission of packets such
that TCP is “self-clocking”.
• TCP relies on Additive Increase and Multiplicative
Decrease (AIMD).
• To implement AIMD, a TCP host must be able to control
its transmission rate.
 Standard TCP Congestion Control
Algorithms
• One of the most common implementations of
TCP is called Reno, and combines four
different mechanisms :

– Slow start
– Congestion avoidance
– Fast retransmit
– Fast recovery
 Slow start
• Slow Start, a requirement for TCP software
implementations is a mechanism used by the sender
to control the transmission rate, otherwise known as
sender-based flow control.
• The rate of acknowledgements returned by the
receiver determine the rate at which the sender can
transmit data.
• When a TCP connection first begins, the Slow Start
algorithm initializes a congestion window to one
segment, which is the maximum segment size (MSS)
initialized by the receiver during the connection
establishment phase.
• When acknowledgements are returned by the receiver, the
congestion window increases by one segment for each
acknowledgement returned.
• Thus, the sender can transmit the minimum of the congestion
window and the advertised window of the receiver, which is
simply called the transmission window.
• For example, the first successful transmission and
acknowledgement of a TCP segment increases the window to
two segments.
• After successful transmission of these two segments and
acknowledgements completes, the window is increased to four
segments.
• Then eight segments, then sixteen segments and so on,
doubling from there on out up to the maximum window size
advertised by the receiver or until congestion finally does occur.
• At some point the congestion window may
become too large for the network or network
conditions may change such that packets may be
dropped.
• Packets lost will trigger a timeout at the sender.

• When this happens, the sender goes into

congestion avoidance mode as described in the
next section.
 Congestion Avoidance
• During the initial data transfer phase of a TCP
connection the Slow Start algorithm is used.
• However, there may be a point during Slow Start
that the network is forced to drop one or more
packets due to overload or congestion.
• If this happens, Congestion Avoidance is used to
slow the transmission rate.
• However, Slow Start is used in conjunction with
Congestion Avoidance as the means to get the data
transfer going again so it doesn’t slow down and stay
slow.
• In the Congestion Avoidance algorithm a retransmission
timer expiring or the reception of duplicate ACKs can
implicitly signal the sender that a network congestion
situation is occurring.
• The sender immediately sets its transmission window to
one half of the current window size (the minimum of the
congestion window and the receiver’s advertised
window size), but to at least two segments.
• If congestion was indicated by a timeout, the congestion
window is reset to one segment, which automatically
puts the sender into Slow Start mode.
• If congestion was indicated by duplicate ACKs, the Fast
Retransmit and Fast Recovery algorithms are invoked
• As data is received during Congestion Avoidance, the
congestion window is increased.
• However, Slow Start is only used up to the halfway
point where congestion originally occurred.
• This halfway point was recorded earlier as the new
transmission window.
• After this halfway point, the congestion window is
increased by one segment for all segments in the
transmission window that are acknowledged.
• This mechanism will force the sender to more slowly
grow its transmission rate, as it will approach the
point where congestion had previously been
detected.
 Fast Retransmit
• When a duplicate ACK is received, the sender does
not know if it is because a TCP segment was lost or
simply that a segment was delayed and received out
of order at the receiver.
• If the receiver can re-order segments, it should not
be long before the receiver sends the latest
expected acknowledgement.
• Typically no more than one or two duplicate ACKs
should be received when simple out of order
conditions exist.
• If however more than two duplicate ACKs are received
by the sender, it is a strong indication that at least one
segment has been lost.
• The TCP sender will assume enough time has lapsed for
all segments to be properly re-ordered by the fact that
the receiver had enough time to send three duplicate
ACKs.
• When three or more duplicate ACKs are received, the
sender does not even wait for a retransmission timer to
expire before retransmitting the segment.
• This process is called the Fast Retransmit algorithm.
• Immediately following Fast Retransmit is the Fast
Recovery algorithm.
 Fast Recovery
• Since the Fast Retransmit algorithm is used when
duplicate ACKs are being received, the TCP sender
has implicit knowledge that there is data still flowing
to the receiver.
• Why? The reason is because duplicate ACKs can only
be generated when a segment is received.
• This is a strong indication that serious network
congestion may not exist and that the lost segment
was a rare event.
• So instead of reducing the flow of data abruptly by going
all the way into Slow Start, the sender only enters
Congestion Avoidance mode.
• Rather than start at a window of one segment as
in Slow Start mode, the sender resumes
transmission with a larger window, incrementing
as if in Congestion Avoidance mode.
• Congestion Control is concerned with efficiently
using a network at high load.
• Several techniques can be employed. These include:
– Warning bit
– Choke packets
– Load shedding
– Random early discard
– Traffic shaping
• The first 3 deal with congestion detection and
recovery. The last 2 deal with congestion avoidance.
 Warning Bit
• A special bit in the packet header is set by the
router to warn the source when congestion is
detected.
• The bit is copied and piggy-backed on the ACK
and sent to the sender.
• The sender monitors the number of ACK
packets it receives with the warning bit set
and adjusts its transmission rate accordingly.

129
 Choke Packets
• A more direct way of telling the source to
slow down.
• A choke packet is a control packet
generated at a congested node and
transmitted to restrict traffic flow.
• The source, on receiving the choke packet
must reduce its transmission rate by a
certain percentage.
• An example of a choke packet is the ICMP
Source Quench Packet.

130
 Hop-by-Hop Choke Packets
• Over long distances or at high speeds choke
packets are not very effective.
• A more efficient method is to send to choke
packets hop-by-hop.
• This requires each hop to reduce its
transmission even before the choke packet
arrive at the source.

131
 Load Shedding
• When buffers become full, routers simply discard
packets.
• Which packet is chosen to be the victim depends on
the application and on the error strategy used in the
data link layer.
• For a file transfer, for, e.g. cannot discard older
packets since this will cause a gap in the received
data.
• For real-time voice or video it is probably better to
throw away old data and keep new packets.
• Get the application to mark packets with discard
priority.

132
 Random Early Discard (RED)
• This is a proactive approach in which the
router discards one or more packets before
the buffer becomes completely full.
• Each time a packet arrives, the RED
algorithm computes the average queue
length, avg.
• If avg is lower than some lower threshold,
congestion is assumed to be minimal or
non-existent and the packet is queued.

133
 RED, cont.
• If avg is greater than some upper
threshold, congestion is assumed to be
serious and the packet is discarded.
• If avg is between the two thresholds, this
might indicate the onset of congestion. The
probability of congestion is then calculated.

134
Traffic Shaping
• Another method of congestion control is to
“shape” the traffic before it enters the
network.
• Traffic shaping controls the rate at which
packets are sent (not just how many).
• Used in ATM and Integrated Services
networks.
• At connection set-up time, the sender and
carrier negotiate a traffic pattern (shape).
• Two traffic shaping algorithms are:
– Leaky Bucket
– Token Bucket

135
 Piggybacking
• Piggybacking is a bi-directional data
transmission technique in the network layer (OSI
model).
• In all practical situations, the transmission of data
needs to be bi-directional. This is called as full-
duplex transmission.
• We can achieve this full duplex
transmission i.e. by having two separate
channels-one for forward data transfer and the
other for separate transfer i.e. for
acknowledgements.
• A better solution would be to use each
channel (forward & reverse) to transmit
frames both ways, with both channels having
the same capacity.
• If A and B are two users.
• Then the data frames from A to B are
intermixed with the acknowledgements from
A to B.
• One more improvement that can be made is
piggybacking.
• The concept is explained as follows:
• In two way communication, Whenever a data
frame is received, the received waits and does
not send the control frame (acknowledgement)
back to the sender immediately.
• The receiver waits until its network layer passes
in the next data packet. The delayed
acknowledgement is then attached to this
outgoing data frame.
• This technique of temporarily delaying the
acknowledgement so that it can be hooked with
next outgoing data frame is known as
piggybacking.
• The major advantage of piggybacking is better
use of available channel bandwidth.

• The disadvantages of piggybacking are:

1. Additional complexity.
2. If the data link layer waits too long before
transmitting the acknowledgement, then
retransmission of frame would take place.