MODULE-4 CN (21CS52) - The Transport Layer

21CS52 -
COMPUTER NETWORKS
Textbooks:
1. Computer-Networks- Andrew S. Tanenbaum and David J. Wetherall, Pearson Education,
5th-Edition. (www.pearsonhighered.com/tanenbaum)
2. Computer Networking A Top-Down Approach -James F. Kurose and Keith W.
RossPearson Education 7th Edition.
Reference Books:
1. Behrouz A Forouzan, Data and Communications and Networking, Fifth Edition, McGraw
Hill,Indian Edition
2. Larry L Peterson and Brusce S Davie, Computer Networks, fifth edition, ELSEVIER
(As per VTU Syllabus)
3/3/2024 ELAIYARAJA P
21CS52 - COMPUTER NETWORKS
CREDITS – 4 (3 T + 2 L)
CIE (Continuous Internal Evaluation) MARKS – 50
SEE (Semester End Examination) MARKS – 50
Course Learning Objectives:

CLO1. Fundamentals of data communication networks.
CLO2. Software and hardware interfaces
CLO3. Application of various physical components and protocols
CLO4. Communication challenges and remedies in the networks.
Course Outcomes:
CO1. Learn the basic needs of communication system.
CO2. Interpret the communication challenges and its solution.
CO3. Identify and organize the communication system
network components
CO4. Design communication networks for user requirements.
Assessment Details (both CIE and SEE)
Continuous Internal Evaluation:
Three Unit Tests each of 20 Marks (duration 01 hour)
1. First test at the end of 5th week of the semester

2. Second test at the end of the 15th week of the semester
Two assignments each of 10 Marks
1. First assignment at the end of 4th week of the semester

2. Second assignment at the end of 9th week of the semester
Practical Sessions need to be assessed by appropriate rubrics and viva-voce

method.
This will contribute to 20 marks.
Program Outcomes:
PROGRAM OUTCOMES
PO's PO Description
Engineering knowledge: Apply the knowledge of mathematics, science, engineering
PO1 fundamentals, and an engineering specialization to the solution of complex
engineering problems.
Problem analysis: Identify, formulate, review research literature, and analyze
PO2 complex engineering problems reaching substantiated conclusions using first
principles of mathematics, natural sciences, and engineering sciences.
Design/development of solutions: Design solutions for complex engineering
problems and design system components or processes that meet the specified needs
PO3
with appropriate consideration for the public health and safety, and the cultural,
societal, and environmental considerations.
Conduct investigations of complex problems: Use research-based knowledge and
PO4 research methods including design of experiments, analysis and interpretation of
data, and synthesis of the information to provide valid conclusions.
Modern tool usage: Create, select, and apply appropriate techniques, resources, and
PO5 modern engineering and IT tools including prediction and modeling to complex
engineering activities with an understanding of the limitations.
The engineer and society: Apply reasoning informed by the contextual knowledge
PO6 to assess societal, health, safety, legal and cultural issues and the consequent
responsibilities relevant to the professional engineering practice.
Environment and sustainability: Understand the impact of the professional
PO7 engineering solutions in societal and environmental contexts, and demonstrate the
knowledge of, and need for sustainable development.
Ethics: Apply ethical principles and commit to professional ethics and
PO8
responsibilities and norms of the engineering practice.
Program Outcomes:
Individual and team work: Function effectively as an individual, and as a member
PO9
or leader in diverse teams, and in multidisciplinary settings.
Communication: Communicate effectively on complex engineering activities with
the engineering community and with society at large, such as, being able to
PO10
comprehend and write effective reports and design documentation, make effective
presentations, and give and receive clear instructions.
Project management and finance: Demonstrate knowledge and understanding of
the engineering and management principles and apply these to one’s own work, as a
PO11
member and leader in a team, to manage projects and in multidisciplinary
environments.
Life-long learning: Recognize the need for, and have the preparation and ability to
PO12 engage in independent and life-long learning in the broadest context of technological
change.
Program Specific Outcomes:
PROGRAM SPECIFIC OUTCOMES
PSO's PSO Description

An ability to design and analyze algorithms by applying theoretical concepts to build
PSO1 complex and computer- based systems in the domain of System Software, Computer
Networks & Security, Web technologies, Data Science and Analytics.
Be able to develop various software solutions by applying the techniques of Data
PSO2 Base Management, Complex Mathematical Models, Software Engineering practices
and Machine Learning with Artificial Intelligence.
21CS52 –
COMPUTER NETWORKS
Module 4 –
The Transport Layer
➢ Module 4 - The Transport Layer

Laboratory Component:
Laboratory Component:
1. Implement an Ethernet LAN using n nodes and set multiple traffic nodes and
plot congestion window for different source / destination.
2. Write a program for congestion control using leaky bucket algorithm.
The Transport Layer:

The Transport Service, Elements of
transport protocols, Congestion control, The
internet transport protocols.
Module 4 - The Transport Layer
❖ transport-layer ❖ connection-oriented
services transport: TCP
❖ multiplexing and ▪ segment structure
demultiplexing ▪ reliable data transfer
❖ connectionless ▪ flow control
transport: UDP ▪ connection management
❖ principles of reliable ❖ principles of congestion

data transfer control
❖ TCP congestion control
Protocol Suite Module 4 - The Transport Layer
HTTP SMTP DNS RTP
Distributed
applications User
Reliable
TCP UDP datagram
stream
service service
Diverse network
technologies
Best-effort
IP (ICMP, ARP)
connectionless
packet transfer
Network Network Network

Interface 1 Interface 2 Interface 3
Transport services and protocols application
transport
❖ provide logical network
data link
communication between app physical
processes running on
different hosts
❖ transport protocols run in
end systems
▪ send side: breaks app
messages into segments,
passes to network layer
application
▪ rcv side: reassembles transport
network
segments into messages, data link
physical
passes to app layer
❖ more than one transport
protocol available to apps
▪ Internet: TCP and UDP
Transport vs. network layer
❖ network layer: ❖transport layer: logical

logical communication between
communication processes
between hosts ▪relies on, enhances,
network layer services
Transport Service Primitives
Socket programming
goal: learn how to build client/server applications that
communicate using sockets
socket: door between application process and end-end-transport
protocol
application application
socket controlled by
process process app developer
transport transport
network network controlled
link by OS
link Internet
physical physical
Socket programming
Two socket types for two transport services:
▪ UDP: unreliable datagram
▪ TCP: reliable, byte stream-oriented
Application Example:
1. Client reads a line of characters (data) from its keyboard
and sends the data to the server.
2. The server receives the data and converts characters to
uppercase.
3. The server sends the modified data to the client.
4. The client receives the modified data and displays the line
on its screen.
We will use the term segment for messages sent from transport entity to
transport entity.
TCP, UDP and other Internet protocols use this term. Thus, segments
(exchanged by the transport layer) are contained in packets (exchanged by the
network layer). In turn, these packets are contained in frames (exchanged by
the data link layer). When a frame arrives, the data link layer processes the
frame header and, if the destination address matches for local delivery, passes
the contents of the frame payload field up to the network entity. The network
entity similarly processes the packet header and then passes the contents of the
packet payload up to the transport entity.
Nesting of Transport Protocol Data Unit (TPDU),

packets, and frames.
Berkeley Sockets
The socket primitives as they are used for TCP. Sockets were first released as part of
the Berkeley UNIX 4.2BSD software distribution in 1983. They quickly became
popular.
The primitives are now widely used for Internet programming on many operating
systems, especially UNIX-based systems, and there is a socket-style API for
Windows called ‘‘winsock.’’
Types of Sockets :
There are two types of Sockets: the datagram socket and
the stream socket.
FUNCTION CALL DESCRIPTION
Create() To create a socket
Bind() It’s a socket identification like a
telephone number to contact
Listen() Ready to receive a connection
Connect() Ready to act as a sender
Accept() Confirmation, it is like accepting
to receive a call from a sender
Write() To send data
Read() To receive data
Close() To close a connection
Connection-oriented demux: example

threaded server
application
P4
P3 P2 P3
transport
transport transport
network
network link network
link physical link
physical server: IP physical
address B
host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80
Multiplexing/demultiplexing
multiplexing at sender:
handle data from multiple demultiplexing at receiver:
sockets, add transport header use header info to deliver
(later used for demultiplexing) received segments to correct
socket
application
application P1 P2 application socket

P3 transport P4
process
transport network transport
link physical link
physical physical
How demultiplexing works
❖ host receives IP datagrams 32 bits

▪ each datagram has source IP source port # dest port #
address, destination IP
address
other header fields
▪ each datagram carries one
transport-layer segment
▪ each segment has source, application
destination port number data
❖ host uses IP addresses & (payload)
port numbers to direct
segment to appropriate
TCP/UDP segment format
socket
Connectionless demultiplexing
❖ recall: created socket has ❖ recall: when creating
host-local port #: datagram to send into UDP
DatagramSocket mySocket1 = new socket, must specify
DatagramSocket(12534);
▪ destination IP address
▪ destination port #
❖ when host receives UDP IP datagrams with same

segment: dest. port #, but different
▪ checks destination port # source IP addresses and/or
in segment source port numbers will
be directed to same socket
▪ directs UDP segment to at dest
socket with that port #
Connectionless demux: example
DatagramSocket
DatagramSocket serverSocket = new
DatagramSocket DatagramSocket
mySocket2 = new mySocket1 = new
DatagramSocket (6428); DatagramSocket
(9157); application
(5775);
P1
P3 P4
transport
transport transport
network
link physical link
physical physical
source port: 6428 source port: ?

dest port: 9157 dest port: ?
source port: 9157 source port: ?

dest port: 6428 dest port: ?
Connection-oriented demux
❖ TCP socket identified ❖ server host may support

by 4-tuple: many simultaneous TCP
▪ source IP address sockets:
▪ source port number ▪ each socket identified by
▪ dest IP address its own 4-tuple
▪ dest port number ❖ web servers have
❖ demux: receiver uses different sockets for
all four values to direct each connecting client
segment to appropriate ▪ non-persistent HTTP will
socket have different socket for
each request
UDP: User Datagram Protocol
Why is there a UDP?
▪ “no frills,” “bare bones” ▪ no connection
Internet transport protocol establishment (which can
▪ “best effort” service, UDP add RTT delay)
segments may be: ▪ simple: no connection
• lost state at sender, receiver
• delivered out-of-order to app ▪ small header size
▪ no congestion control
▪ connectionless: ▪ UDP can blast away as
• no handshaking between UDP fast as desired!
sender, receiver ▪ can function in the face
• each UDP segment handled of congestion
independently of others
UDP: User Datagram Protocol
▪ UDP use:
▪ streaming multimedia apps (loss tolerant, rate sensitive)
▪ DNS
▪ SNMP
▪ HTTP/3
▪ if reliable transfer needed over UDP (e.g., HTTP/3):
▪ add needed reliability at application layer
▪ add congestion control at application layer
UDP: Transport Layer Actions
SNMP client SNMP server
transport transport
(UDP) (UDP)
network (IP) network (IP)
link link
physical physical
SNMP server
SNMP client
UDP sender actions:
application
SNMP msg
application ▪ is passed an application-
layer message transport
transport UDP
UDPhh SNMP msg
▪ determines UDP (UDP)
(UDP) segment header fields
values network (IP)
network (IP) ▪ creates UDP segment
▪ passes segment to IP link
link
physical
physical
SNMP server
SNMP client
UDP receiver actions:
▪ receives segment from IP application
application
▪ checks UDP checksum transport
transport header value
SNMP msg (UDP)
(UDP) ▪ extracts application-layer
message network (IP)
network
UDP (IP)
h SNMP msg ▪ demultiplexes message link
link up to application via
socket physical
physical
UDP segment header
32 bits
source port # dest port #
length checksum
application length, in bytes of

data UDP segment,
(payload) including header
data to/from
UDP segment format application layer
UDP pseudo-header
0 8 16 31
Source IP Address
Destination IP Address
00000000 Protocol = 17 UDP Length
⚫ UDP checksum detects for end-to-end errors

⚫ Covers pseudoheader followed by UDP datagram
⚫ IP addresses included to detect against misdelivery
⚫ IP & UDP checksums set to zero during calculation
⚫ Pad with 1 byte of zeros if UDP length is odd
TCP seq. numbers, ACKs
The diagram
shows the
establishment of a
new connection to
a web server - the
Gateway Server.
The first three
packets are part of
the 3-way
handshake
performed by TCP
before any data is
transferred
between the two
hosts.
TCP seq. numbers, ACKs : STEP 1
Host A wishes to download a webpage from the Gateway Server. This requires a new
connection between the two to be established so 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".
Now, you might be expecting the next packet to be sent from
the Gateway Server, but this is not the case. You might recall
that Host A initiated the connection because it wanted to download a
web page from the Gateway Server. 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.
Note that the sequence number of the segment in line 4 is the same as in line 3
because the ACK does not occupy sequence number space.
So keep in mind that any packets generated, which are simply acknowledgments (in
other words, have only the ACK flag set and contain no data) to previously received
packets, never increment the sequence number.

Host A Host B
User
types
‘C’ Seq=42, ACK=79, data = ‘C’
host ACKs
receipt of
‘C’, echoes
Seq=79, ACK=43, data = ‘C’ back ‘C’
host ACKs
receipt
of echoed
‘C’ Seq=43, ACK=80
simple telnet scenario
18CS52 - Computer Networks and Security
Module -2 Transport Layer
Connection Management
before exchanging data, sender/receiver “handshake”:
❖ agree to establish connection (each knowing the other willing
to establish connection)
❖ agree on connection parameters (e.g., starting seq #s)
connection state: ESTAB connection state: ESTAB

connection variables: connection Variables:
seq # client-to-server seq # client-to-server
server-to-client server-to-client
rcvBuffer size rcvBuffer size
at server,client at server,client
network network
Socket clientSocket = Socket connectionSocket =

newSocket("hostname","port welcomeSocket.accept();
number");
TCP flow control
TCP flow control

❖ receiver “advertises” free
buffer space by including
rwnd value in TCP header to application process
of receiver-to-sender
segments RcvBuffer buffered data
▪ RcvBuffer size set via
socket options (typical default rwnd free buffer space
is 4096 bytes)
▪ many operating systems
autoadjust RcvBuffer TCP segment payloads
❖ sender limits amount of TCP receiver-side buffering

unacked (“in-flight”) data to
receiver’s rwnd value
❖ guarantees receive buffer
will not overflow
Congestion Control
Causes/costs of congestion: scenario 1

original data: lin throughput:
Simplest scenario: lout
Host A
▪ one router, infinite buffers
▪ input, output link capacity: R infinite shared
output link
▪ two flows buffers
R R
▪ no retransmissions needed
Host
B
R/2
Q: What happens as
lout
arrival rate lin
delay
throughput:
approaches R/2?
lin R/2 lin R/2
maximum per-connection large delays as arrival
throughput: R/2 rate lin approaches
capacity

▪ one router, finite buffers
▪ sender retransmits lost, timed-out packet
• application-layer input = application-layer output: lin = lout
• transport-layer input includes retransmissions : l’in lin
Host A lin : original data

lout
l'in: original data, plus
retransmitted data
R R
Host B finite shared output

link buffers

Idealization: perfect knowledge R/2
lout
▪ sender sends only when router buffers available
throughput:
Host A lin : original data lin
lout R/2
copy l'in: original data, plus
retransmitted data
free buffer space!
R R

link buffers

Idealization: some perfect knowledge
▪ packets can be lost (dropped at router) due
to full buffers
▪ sender knows when packet has been
dropped: only resends if packet known to be
lost
Host A lin : original data

copy l'in: original data, plus
retransmitted data
no buffer space!
R R

link buffers

Idealization: some perfect knowledge R/2
▪ packets can be lost (dropped at router) due
lout
to full buffers
throughput:
when sending at
▪ sender knows when packet has been R/2, some
dropped: only resends if packet known to be packets are
lost needed
retransmissions
Host A lin : original data lin R/2
l'in: original data, plus
retransmitted data
free buffer space!
R R

link buffers

Realistic scenario: un-needed
duplicates R/2
lout
▪ packets can be lost, dropped at router due to “wasted” capacity
due to un-needed
full buffers – requiring retransmissions retransmissions
throughput:
▪ but sender times can time out prematurely,
when sending at
sending two copies, both of which are R/2, some packets
delivered are
retransmissions,
Host A lin : original data lin
including needed
and un-needed
timeou R/2
copy
t l'in: original data, plus duplicates, that are
retransmitted data delivered!
free buffer space!
R R

link buffers

Realistic scenario: un-needed R/2
duplicates
lout
“wasted” capacity
due to un-needed
▪ packets can be lost, dropped at router due to retransmissions
throughput:
full buffers – requiring retransmissions
when sending at
▪ but sender times can time out prematurely, R/2, some packets
sending two copies, both of which are are
retransmissions,
delivered including needed
lin R/2 and un-needed
duplicates, that are
“costs” of congestion: delivered!
▪ more work (retransmission) for given receiver throughput

▪ unneeded retransmissions: link carries multiple copies of a packet
• decreasing maximum achievable throughput

▪ four senders Q: what happens as lin and lin’ increase ?
▪ multi-hop paths A: as red lin’ increases, all arriving blue pkts at upper
▪ timeout/retransmit queue are dropped, blue throughput g 0
Host lin : original data
A Host
l'in: original data, plus B
retransmitted data
finite shared
output link
buffers
Host
D
lout
Host
C

R/2
lout
lin’ R/2
another “cost” of congestion:

▪ when packet dropped, any upstream transmission capacity
and buffering used for that packet was wasted!
Causes/costs of congestion: insights

R/2
▪ throughput can never exceed capacity
throughput: lout
lin R/2
▪ delay increases as capacity approached
delay
R/2
lin R/2
lout
▪ loss/retransmission decreases effective
throughput:
throughput
lin R/2 R/2
▪ un-needed duplicates further decreases
throughput: lout
effective throughput
R/2
lin R/2
▪ upstream transmission capacity /
lout
buffering wasted for packets lost
downstream lin’ R/2
TCP congestion control: AIMD
▪ approach: senders can increase sending rate until packet loss
(congestion) occurs, then decrease sending rate on loss event
Additive Increase
Multiplicative Decrease
increase sending rate by 1 cut sending rate in half at
maximum segment size every each loss event
RTT until loss detected
TCP sender Sending rate
AIMD sawtooth
behavior: probing
for bandwidth
time
TCP AIMD:
Multiplicative decrease detail: sending rate is

▪ Cut in half on loss detected by triple duplicate ACK (TCP
Reno)
▪ Cut to 1 MSS (maximum segment size) when loss
detected by timeout (TCP Tahoe)
Why AIMD?
▪ AIMD – a distributed, asynchronous algorithm – has
been shown to:
• optimize congested flow rates network wide!
• have desirable stability properties
TCP slow start

Host A Host B
▪ when connection begins,
increase rate exponentially
until first loss event:
• initially cwnd = 1 MSS
RTT
• double cwnd every RTT
• done by incrementing cwnd
for every ACK received
▪ summary: initial rate is

slow, but ramps up
exponentially fast
time
TCP fairness
Fairness goal: if K TCP sessions share same bottleneck link

of bandwidth R, each should have average rate of R/K
TCP connection 1
bottleneck
TCP connection 2 router
capacity R
Real-Time Protocol (RTP)
▪ RTP specifies packet ▪ RTP runs in end systems

structure for packets ▪ RTP packets encapsulated
carrying audio, video data in UDP segments
▪ RFC 3550 ▪ interoperability: if two VoIP
▪ RTP packet provides applications run RTP, they
• payload type may be able to work
identification together
• packet sequence
numbering
• time stamping
RTP runs on top of UDP
RTP libraries provide transport-layer interface

that extends UDP:
• port numbers, IP addresses
• payload type identification
• packet sequence numbering
• time-stamping
RTP header
payload sequence Synchronization Miscellaneo
time stamp
type number type Source ID us fields
payload type (7 bits): indicates type of encoding currently being

used. If sender changes encoding during call, sender
informs receiver via payload type field
Payload type 0: PCM mu-law, 64 kbps
Payload type 3: GSM, 13 kbps
Payload type 7: LPC, 2.4 kbps
Payload type 26: Motion JPEG
Payload type 31: H.261
Payload type 33: MPEG2 video
sequence # (16 bits): increment by one for each RTP packet sent
❖ detect packet loss, restore packet sequence
RTP header
payload sequence Synchronization Miscellaneous
time stamp
type number type Source ID fields
▪ timestamp field (32 bits long): sampling instant of first byte in this
RTP data packet
• for audio, timestamp clock increments by one for each
sampling period (e.g., each 125 usecs for 8 KHz sampling
clock)
• if application generates chunks of 160 encoded samples,
timestamp increases by 160 for each RTP packet when source
is active. Timestamp clock continues to increase at constant
rate when source is inactive.
▪ SSRC field (32 bits long): identifies source of RTP stream. Each
stream in RTP session has distinct SSRC
Real-Time Control Protocol (RTCP)
▪ works in conjunction with RTP ▪ each RTCP packet contains sender
▪ each participant in RTP session and/or receiver reports
periodically sends RTCP • report statistics useful to

control packets to all other application: # packets sent, #
participants packets lost, interarrival jitter
▪ feedback used to control

performance
• sender may modify its

transmissions based on feedback
RTCP: multiple multicast senders
sender RTP
RTCP
RTCP
RTCP
receivers
▪ each RTP session: typically a single multicast address; all RTP

/RTCP packets belonging to session use multicast address
▪ RTP, RTCP packets distinguished from each other via distinct port
numbers
▪ to limit traffic, each participant reduces RTCP traffic as number of
conference participants increases
Real-Time Control Protocol (RTCP)
RTCP: packet types
receiver report packets: source description packets:
▪ fraction of packets lost, last ▪ e-mail address of sender,
sequence number, average sender's name, SSRC of
interarrival jitter associated RTP stream
sender report packets: ▪ provide mapping between
▪ SSRC of RTP stream, the SSRC and the
current time, number of user/host name
packets sent, number of
bytes sent
TCP: Overview RFCs: 793,1122,1323, 2018, 2581

❖ point-to-point: ❖ full duplex data:
▪ one sender, one receiver ▪ bi-directional data flow
❖ reliable, in-order byte in same connection
steam: ▪ MSS: maximum
segment size
▪ no “message
boundaries” ❖ connection-oriented:
❖ pipelined: ▪ handshaking (exchange
of control msgs) inits
▪ TCP congestion and flow sender, receiver state
control set window size before data exchange
❖ flow controlled:
▪ sender will not
overwhelm receiver
TCP Segment Format
0 4 10 16 24 31
Source port Destination port
Sequence number
Acknowledgment number
Header U A P R S F
Reserved R C S S Y I Window size
length G K H T N N
Checksum Urgent pointer
Options Padding
Data
• Each TCP segment has header of 20 or more bytes + 0 or more bytes of data
TCP seq. numbers, ACKs outgoing segment from sender
sequence numbers: source port # dest port #
sequence number
▪byte stream “number” of acknowledgement number
first byte in segment’s rwnd
data
checksum urg pointer
window size
acknowledgements: N
▪seq # of next byte

expected from other side sender sequence number space
▪cumulative ACK
sent sent, not- usable not
Q: how receiver handles ACKed yet ACKed but not usable
out-of-order segments (“in-
flight”)
yet sent
▪A: TCP spec doesn’t say, incoming segment to sender

- up to implementer source port # dest port #
sequence number
acknowledgement number
A rwnd
checksum urg pointer
TCP Header
Port Numbers Sequence Number
A socket identifies a Byte count
connection endpoint First byte in segment
IP address + port 32 bits long
A connection specified by a 0  SN  232-1
socket pair Initial sequence number
Well-known ports selected during connection
FTP 20 setup
Telnet 23
DNS 53
HTTP 80
3/3/2024 P ELAIYARAJA
TCP Header
Acknowledgement Number Header length
SN of next byte expected by 4 bits
receiver Length of header in multiples
Acknowledges that all prior of 32-bit words
bytes in stream have been Minimum header length is 20
received correctly bytes
Valid if ACK flag is set Maximum header length is 60
bytes
TCP Header
Reserved Control
6 bits 6 bits
URG: urgent pointer flag
Urgent message end = SN + urgent pointer
ACK: ACK packet flag
PSH: override TCP buffering
RST: reset connection
Upon receipt of RST, connection is terminated
and application layer notified
SYN: establish connection
FIN: close connection
TCP Header
Window Size TCP Checksum
16 bits to advertise window Internet checksum method
size TCP pseudoheader + TCP
Used for flow control segment
Sender will accept bytes with
SN from ACK to ACK +
window
Maximum window size is
65535 bytes
0 8 16 31
Source IP address
Destination IP address
00000000 Protocol = 6 TCP segment length
TCP pseudo-header
Internet apps: application, transport protocols

application underlying
application layer protocol transport protocol
e-mail SMTP [RFC 2821] TCP

remote terminal access Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
file transfer FTP [RFC 959] TCP
streaming multimedia HTTP (e.g., YouTube), TCP or UDP
RTP [RFC 1889]
Internet telephony SIP, RTP, proprietary
(e.g., Skype) TCP or UDP
THE END

MODULE-4 CN (21CS52) - The Transport Layer

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MODULE-4 CN (21CS52) - The Transport Layer

Uploaded by

Copyright:

Available Formats

21CS52 -

Course Learning Objectives:

CLO2. Software and hardware interfaces

CLO3. Application of various physical components and protocols

CLO4. Communication challenges and remedies in the networks.

Continuous Internal Evaluation:

Three Unit Tests each of 20 Marks (duration 01 hour)

1. First test at the end of 5th week of the semester

Two assignments each of 10 Marks

1. First assignment at the end of 4th week of the semester

Practical Sessions need to be assessed by appropriate rubrics and viva-voce

PROGRAM SPECIFIC OUTCOMES

PSO's PSO Description

➢ Module 4 - The Transport Layer

The Transport Layer:

❖ principles of reliable ❖ principles of congestion

Network Network Network

Transport vs. network layer

❖ network layer: ❖transport layer: logical

Nesting of Transport Protocol Data Unit (TPDU),

Connection-oriented demux: example

host: IP source IP,port: B,80 host: IP

application P1 P2 application socket

How demultiplexing works

❖ host receives IP datagrams 32 bits

❖ when host receives UDP IP datagrams with same

source port: 6428 source port: ?

source port: 9157 source port: ?

❖ TCP socket identified ❖ server host may support

SNMP client SNMP server

network (IP) network (IP)

application length, in bytes of

00000000 Protocol = 17 UDP Length

⚫ UDP checksum detects for end-to-end errors

TCP seq. numbers, ACKs

simple telnet scenario

connection state: ESTAB connection state: ESTAB

Socket clientSocket = Socket connectionSocket =

TCP flow control

TCP flow control

❖ sender limits amount of TCP receiver-side buffering

Causes/costs of congestion: scenario 1

▪ two flows buffers

arrival rate lin

Causes/costs of congestion: scenario 2

Host A lin : original data

Host B finite shared output

Causes/costs of congestion: scenario 2

free buffer space!

Host B finite shared output

Causes/costs of congestion: scenario 2

Host A lin : original data

Host B finite shared output

Causes/costs of congestion: scenario 2

free buffer space!

Host B finite shared output

Causes/costs of congestion: scenario 2

free buffer space!

Host B finite shared output

Causes/costs of congestion: scenario 2

▪ more work (retransmission) for given receiver throughput

Causes/costs of congestion: scenario 3

Causes/costs of congestion: scenario 3