0% found this document useful (0 votes)
24 views

08 Transport TCP

The document discusses Transport Layer Protocol (TCP) which provides reliable, connection-oriented communication. It describes TCP's service model, segment structure, connection management, reliable data transfer mechanisms including retransmissions and flow/congestion control. TCP establishes connections using a 3-way handshake to initialize sequencing information and exchange parameters like maximum segment size to provide reliable byte streams between endpoints.

Uploaded by

Z Goo
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
24 views

08 Transport TCP

The document discusses Transport Layer Protocol (TCP) which provides reliable, connection-oriented communication. It describes TCP's service model, segment structure, connection management, reliable data transfer mechanisms including retransmissions and flow/congestion control. TCP establishes connections using a 3-way handshake to initialize sequencing information and exchange parameters like maximum segment size to provide reliable byte streams between endpoints.

Uploaded by

Z Goo
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 49

Transport Layer: TCP

2022/23 COMP3234B & ELEC3443B


Contents
• TCP provides a reliable, connection-oriented service

• TCP service model

• TCP segment structure

• TCP connection management

• TCP reliable data transfer

• TCP retransmission timeout mechanism

• TCP flow control

• TCP congestion control

Computer and Communication Networks 2


Learning Outcome

• [ILO2 - Technologies and Protocols] be able to describe the working


principles behind key network protocols – TCP
• ILO 2a - Transport Layer: comprehend the challenges and explain the
principles in providing reliable communication in an unreliable medium.

Computer and Communication Networks 3


Readings

• Required Readings
• Chapter 3 of Computer Networking – A Top-Down Approach Featuring the
Internet 7th edition, by J. Kurose et. al
• Sections 3.5, 3.6, 3.7

Computer and Communication Networks 4


Transmission Control Protocol - TCP
• Service Model
• endpoint-to-endpoint – supports a logical channel between two endpoints
(processes)
• full duplex – supports bidirectional communication at the same time
• The system must maintain independent sequencing info for data flow in each direction
• Connection-oriented
• A logical connection only exists in the end systems
• Intermediate devices do not see/manage this connection
• Require connection setup and release
• handshaking to establish connection before data exchange
• establish some shared state info – e.g., sequencing info, window size, etc.
• Keeping connection state before connection close

Computer and Communication Networks 5


Transmission Control Protocol - TCP
• Reliable in-order byte stream
• Reliability – Using Checksum, Sequence number, Acknowledgment, Retransmission, and timeout
• Stream Data Transfer
• TCP is a stream-oriented protocol that connects the two ends like with an imaginary “water pipe”
• TCP treats the application data as a stream of bytes
• Use of send & receive buffers
• TCP packs application data into TCP segments and passes the segments (one-by-one) to network layer for
delivering to remote host
• Maximum Segment Size (MSS) – The maximum amount of application data to be placed in one segment
• TCP may group application data passed by application from one or more send() calls into one segment for
transmission

Computer and Communication Networks 6


Transmission Control Protocol
- TCP
• TCP Multiplexing/Demultiplexing
• TCP allows multiplexing of multiple connections between end systems
• Each connection only connects two endpoints
• A TCP connection is specified by a 4-tuple
• ((my IP address, my port), (peer’s IP address, peer’s port))
• Arriving segment directed according to connection 4-tuple

Computer and Communication Networks 7


TCP Segment Structure
• TCP segment header
• fixed 20-byte header + optional part (at most 40
bytes)

20 bytes
• TCP segment size
• MSS (max segment size)
• maximum amount of application data to be placed in a

40 bytes
segment
• Each side determines its MSS and informs the other
end during connection setup

MSS
• It is limited by lower link-layer MTU (max
transmission unit) IP datagram encapsulates TCP segment, which in
turn, link-layer frame encapsulates IP datagram

Computer and Communication Networks 8


TCP Header
• 32-bit sequence number field
• every byte on TCP connection has its own sequence number !!
• the value in the header indicates the seq # of the first data byte carried in this
segment
• Each end initializes its Initial sequence number (ISN)
• Is “generated” during connection establishment
• Inform the other end through the 3-way handshaking protocol

• 32-bit Acknowledgment Number field


• Carries the Seq# of the next expected byte expecting by this end
• Acknowledges to the other end that all prior bytes have been received correctly
• TCP uses Cumulative ACK (like GBN)
• This field is valid only when ACK bit (in flag field) is set

Computer and Communication Networks 9


TCP Header (cont)
• Header length field – 4 bits
• Specifies the length of TCP header in unit of 4-byte
• Flag field – 6 bits
• URG bit – indicates that there is an “urgent” data carried in this segment
• Urgent data is contained at the front of the segment payload and end at the point of Seq# + urgent
data pointer field (not being used at all)
• ACK bit – indicates this segment carries acknowledgment
• That means the value in acknowledgment field is valid
• PSH bit – to urge the receiver to pass data to upper application immediately (it is not
available for our use)
• RST bit – to reset the connection
• SYN bit – use in connection establishment
• FIN bit – use in connection teardown

Computer and Communication Networks 10


TCP Header (cont)

• Receive Window - 16 bits


• Maximum 65535 bytes
• Mainly use for flow control
• Inform the other end what is the size of remaining receive buffer at this end at this
moment
• This becomes the size of the sender’s window on the other end

• TCP Checksum
• Same way as UDP, using Internet Checksum

Computer and Communication Networks 11


TCP Header (cont)
• Options
• Variable length at most 40 bytes
• Timestamp option, Window Scale option, MSS option, SACK option, . . .
• Maximum Segment Size (MSS) option specifies largest segment a node wants to receive
• Each end can announce its MSS during connection establishment
• The default size is 536 bytes
• This makes up an IP datagram of 576 bytes including 20 bytes for IP header and 20 bytes for TCP header
• The norm of MSS is 1460 bytes, which is limited by Ethernet technology
• Timestamp option
• The sender can place a 32-bit timestamp value in a segment
• It is used
• For measuring the Round-Trip Time
• For protection against wrapped sequence number

Computer and Communication Networks 12


TCP Connection Management

• TCP sender, receiver establish “connection” before exchanging


data segments
I want to talk to you.
Client Here are my state info: Server
ISN: 3004792292
RecvWin: 5840
MSS: 1460

Sure.
Here are my state info:
ISN: 214748366
RecvWin: 49232
MSS: 1460

Computer and Communication Networks 13


TCP Connection Establishment
• Connection Setup with Three-Way Handshake
• initialize TCP state info (variables):
• initial Seq. Numbers (ISN) for connections in each direction
• buffers, flow control info (e.g., Receive Window), MSS, . .

• Not an easy task


• Involve two remote processes
• has no idea of what is happening at the remote partner's end
• connecting via an unreliable network
• setup packets could be lost; could be arrived out-of-order
• could be delayed by congestion
• induced retransmission  duplicated setup packets
• communication processes need to keep state info
• problem with machine crash which loses all state info

Computer and Communication Networks 14


Three-way handshake
client server
socket( )
socket( ), bind( ), listen( )
Step 1: client sends a TCP connect( )
accept( )
SYN segment to server
• specifies initial seq # (C_ISN#), which
“appears” to be randomly generated
• does not carry any data Step 2: server recv SYN, sends a
SYN+ACK segment
• server specifies its own initial seq # (S_ISN#)
Step 3: client then replies return from • ack with ACK bit set and ACK# stored as C_ISN#+1
with an ACK segment connect( ) • does not carry any data

*
seq # carries C_ISN#+1 , ack
return from
carries S_ISN#+1 accept( )
write( )
* This seq # is not used up by the
ACK segment at all. read( )

• may contain data but usually not


return from
read( )

Computer and Communication Networks 15


Three-way handshake (cont.)
• If no server process is listening to destination port at the
destination address, a reset segment (by setting the RST bit) is sent
to reject connection
• Server and client have their own initial seq #
• each SYN segment “consumes” one sequence number even it
carries no data
• thus, receiver of SYN segment must send an ACK
• if the ACK is missing, the timeout timer will trigger the retransmission of SYN

Computer and Communication Networks 16


Connection Termination

• A "four-way" handshake protocol


• symmetric release
• either end can terminate first
• treat a bidirectional channel as two unidirectional channels
• each direction releases the connection independently

Computer and Communication Networks 17


Connection Termination
hostA hostB

Step 1: client end system close( )


sends TCP FIN control
segment to server
Step 2: server receives FIN, replies
with ACK.
close( )
Closes connection, sends FIN

Step 3: client receives FIN,


replies with ACK.
Timed wait

Enters “timed wait” state closed Step 4: server, receives ACK.

Connection closed

closed

Computer and Communication Networks 18


Connection Termination
• “timed wait” state - (waits 30s, 1min, or 2mins)
• System needs to keep the connection state info for this duration
• It will respond only to retransmission FINs (from hostB)
• Maybe the returned ACK was lost, B retransmitted FIN
• if such FIN segment arrives, resent ACK & restart TIME_WAIT timer
• Similarity, a FIN segment also consumes one Seq#
• If a response to FIN is lost, server will resend FIN segment and will
releases the connection after retries sending FIN some number of times
• 2nd ACK & 3rd FIN can be sent by one segment; this reduces to a "3-
way" handshaking

Computer and Communication Networks 19


TCP Reliable Data Transfer
• TCP operates on top of IP, which is only a best effort service
• Packets may arrive out-of-order, may have errors, may be lost, may arrive after a long
delays
• TCP uses many of the principles we learned in stop-and-wait, go-back-n, &
selective-repeat
• Checksum, Sequence number, Acknowledgment, Retransmission, timeout
• TCP uses the same Internet Checksum as UDP and IP
• 32-bit Sequence Numbers
• Every byte carried in a segment has its sequence number; the seq# in the header shows
the seq# of the first byte in that segment
• Initial seq# is “randomly” generated at each end during connection setup; they inform
each other by exchanging through the SYN segments
Computer and Communication Networks 20
TCP Reliable Data Transfer
• TCP Window – Receive Window – Flow control
• TCP does not use the traditional sliding window
• TCP has one window at each end which is controlled by the remote peer at the other end of TCP
connection
• This window is used by the remote peer to limit how many unACKed bytes the sender can send before
stop-and-wait for the acknowledgements
• How TCP receiver handles out-of-order segments ??
• TCP specification doesn’t say, up to implementer
• Most implementations use buffers to store valid but out-of-order segments (like selective repeat)
• Acknowledgment
• TCP uses cumulative acknowledgment (like GBN)
• Support piggybacked acknowledgment
• A data segment also carries acknowledgment to the other side
• This reduces the traffic, save valuable bandwidth

Computer and Communication Networks 21


TCP Acknowledgment [RFC 1122, RFC
2581]
Event at Receiver TCP Receiver action
Arrival of in-order segment with Delayed ACK. Wait up to 500ms for next
expected seq #. All data up to expected segment. If no next segment, send ACK
seq # already ACKed
Arrival of in-order segment with Immediately send single cumulative
expected seq #. One other segment has ACK, ACKing both in-order segments
ACK pending
Arrival of out-of-order segment higher- Immediately send duplicate ACK,
than-expect seq. # . Gap detected indicating seq. # of next expected byte

Arrival of segment that partially or Immediate send ACK, provided that


completely fills gap segment starts at lower end of gap

Computer and Communication Networks 22


TCP Transmission Policy
• When received data from application, TCP places the application data in
send buffer; TCP may or may not immediately transmit data
• TCP has three mechanisms to trigger a transmission
• When the amount of data in send buffer exceed threshold (which is the Max
segment size); or
• URGENT data; or
• TCP thinks is time to send
• if there is unack’ed data in transit, buffer data and send it until ACK arrives

• Start retransmission timer if not already running


• TCP uses single retransmission timer (like GBN)
• think of timer as for oldest unACKed segment

Computer and Communication Networks 23


TCP Timeout Interval
• The Crux: How long should the retransmission timer be?
• Need to be longer than RTT, but RTT is fluctuating
• For Local Area Network (LAN)
• RTT delay is highly predictable; thus, RTT values are pretty stable
• For the Internet
• Larger variation of RTTs as Internet is shared and the amount of traffic going through Internet is unpredictable
• If timeout duration is set to be too short
• Suffers unnecessary retransmissions
• If set to too long timeout
• Delays recovery from errors; performance suffers

• Because there may have a large variation of the RTT time; simply measure the
RTT to determine the timeout interval is not good enough; need an adaptive
timeout mechanism

Computer and Communication Networks 24


TCP Timeout Interval
• Make use of the RTT observations (past measurements)
• Measure the RTT from segment transmission until ACK receipt
• Denoted this as SampleRTT
• Usually TCP takes one measurement per one RTT

• SampleRTT is fluctuating from time to time


• TCP maintains a weighted average (EstimatedRTT)
• EstimatedRTTi+1 = (1-)EstimatedRTTi + SampleRTTi+1
• typical value of the smoothing factor:  = 0.125
• which is an influence factor of current measured sample

• Can we simply use EstimatedRTT to set TimeoutInterval?


• If the variation among samples is small, the EstimatedRTT value should be good enough
• If the variation is large, the timeout value should adjust appropriately

Computer and Communication Networks 25


TCP Timeout Interval
• Setting the timeout
• EstimatedRTT plus "safety margin"
• larger variation in RTT  larger safety margin

• first estimate of how much SampleRTT deviates from EstimatedRTT


• Difference = SampleRTTi+1 - EstimatedRTTi
• DevRTTi+1 = (1 - )DevRTTi +  |Difference|
• where  is a factor between 0 and 1; recommended value is 0.25
• Set timeout interval to
• TimeoutInterval = EstimatedRTT + 4 x DevRTT

Computer and Communication Networks 26


TCP Timeout Interval
• There is one issue
• A segment has timeout and been retransmitted, an ACK comes back
• which ACK this is referred to? The first one or retransmitted one??

• To avoid retransmission ambiguity problem,


• TCP does not derive the timeout interval on retransmitted segment by EstimatedRTT
and DevRTT
• Instead, the timeout interval is actually doubled on each timeout, until the segment
gets through the first time
• We call this exponential backoff
• Congestion is the most likely cause of segment losses; it is likely that the RTT value will be increased
by the congestion
• For the next transmission, we reuse this timeout value until the ACK for this segment is
received that was not retransmitted

Computer and Communication Networks 27


TCP Flow Control
• TCP’s “sliding window” is different from the mechanism used by GBN & SR
• TCP sender window does not slide forward upon receiving ACKs
• TCP sender window is not determined by sender itself and size of window is not fixed
• The size of the TCP sender window is limited by the receive window advertised by the
remote peer
• Receiver has limited buffers to store arriving packets
• Receiver’s buffer overflow
• When Sender’s transmission rate is faster than the application’s data consumption rate
• "reason of flow control"
• sender won't overflow receiver's buffer by sending too much, too fast
• by regulating rate at which source is allowed to send information

Computer and Communication Networks 28


Recv Win
TCP Flow Control TCP
spare
Application process data From network
room
in buffer

• Receive Window Recv Buffer

• the remote peer tells the other end how much receive buffer space available at its end
for this connection at the moment
• this is for speed-matching send rate to receiving application’s draining rate
• Space remain in Receive buffer (suppose no out-of-order segment)
• RecvWin = RecvBuffer – [LastByteRcvd–LastByteRead]

• Advertises unused buffer space by including RecvWin in segment header


and sends to the other end
• Peer at the other end is obliged to keep number of outstanding unACKed
bytes below RecvWin
• This guarantees receiver’s buffer doesn’t overflow
Computer and Communication Networks 29
TCP Flow Control
(Receiver has advertised that RecvWin=4KiBytes)
• A deadlock scenario may occur if the ACK
segment (ACK=4096, WIN=2048) were lost
(Recv host stored that • However, ACK does not timeout and
2Ki msg in recv buff) retransmit
• Sender is blocked, so....
(Upper application does
not immediately read it)
• TCP allows sender to send even RecvWin=0
• periodically, send a 1-byte segment to “test”
• send urgent data when needed

Computer and Communication Networks 30


Congestion
• Congestion Control
• Cause of congestion
• To avoid a set of senders overrunning the
• When the number of packets approaches network resources
the packet handling capacity of the network
• Examples
• all going to the same outgoing line
• Don’t want the control to be too restrictive
• mismatch of line speeds • Ideal case - Elastic utilization of network
bandwidth
• Transmitters dynamically adjust transmission
rate according to network congestion level as
indicated by feedbacks from the network

Computer and Communication Networks 31


Congestion

• Effects of congestion
• Longer delay as experiencing longer queues in routers
• Packet loss due to buffer overflow at routers
• Rely on retransmission to recover from the loss; however, performance suffers
• resources used by the packet before the loss become waste

Computer and Communication Networks 32


TCP Congestion Control
• TCP sender should transmit as fast as possible, but without
congesting the network
• The Cruxes
• how to find a suitable transmission rate just below congestion level
• how to perceive that there is congestion
• how to adjust rate in response to changes in the congestion condition
• Basic principle
• no explicit feedback from network
• the sources detect congestion from observed losses

Computer and Communication Networks 33


Congestion Window
• Flow control imposed by receiver
• Receive Window announced by receiver
• Congestion control
• TCP uses another window – “Congestion Window”
• reflects the estimated capacity of the network by the sender
• Max. number of bytes of unacknowledged data that may be sent at any
time: MIN(RecvWin, CongWin)
• LastByteSent – LastByteAcked  min{RecvWin, CongWin}
• TCP is allowed to send no faster than the slowest component can
accommodate
• Either the network or destination host

Computer and Communication Networks 34


Bandwidth Probing
• Each TCP sender sets its own rate, based on implicit feedback
• received ACK segment (a good thing!), network is not congested, so increases sending rate
• detects segment loss: assume loss due to congested network, so decreases sending rate

• “probing for bandwidth”


• increase transmission rate on receipt of ACK, until eventually loss occurs, then decrease
transmission rate

ACKs being received,


X loss, so decrease rate
so increase rate
X
X
X
sending rate

TCP’s “sawtooth” behavior


time
Computer and Communication Networks 35
TCP Congestion-Control Algorithm

• Three major phases


• Slow start
• Congestion Avoidance
• Fast Recovery (plus Fast Retransmit)

Computer and Communication Networks 36


TCP Slow Start
• when TCP connection begins, Host A Host B
• set CongWin to 1 MSS
• example: MSS = 500 bytes & RTT = 200 msec (assume RecvWin is

RTT
large; not a limiting factor)
• initial transmission rate = 20 kbps

• available bandwidth may be much larger than


MSS/RTT
• desirable to quickly ramp up to respectable rate
• increase rate exponentially
• Theoretically – double CongWin every RTT
• In practice – by incrementing CongWin by 1 MSS for
every (non-duplicated) ACK received time

Computer and Communication Networks 37


TCP Slow Start (cont.)
• Slow Start actually increases CongWin aggressively - Exponential increase
• If allows it to increase without limit, the sending rate may become too fast that eventually
overflows the network and causes packet loss
• TCP keeps another state variable – ssthresh
• When detects segment losses – e.g., timeout
• TCP sets ssthresh = FlightSize/2 FlightSize <= Min(RecWin, CongWin)
• remember (half of) TCP rate when congestion last occurred
• resets CongWin = 1 MSS
• increases rate exponentially until ssthresh
• then increases CongWin linearly
• in essence, going to Congestion Avoidance phase

• Initially, ssthresh is set to 64KiB

Computer and Communication Networks 38


Congestion Avoidance -
Additive Increase Multiplicative
Decrease
• TCP uses Additive Increase to slowly increase its transmission rate and probe for
next congestion level
• Here is the concept under AIMD per full window Host A Host B
• In theory – CongWin increment by one MSS per RTT
• In practice: increment a little for each (non-duplicated) ACK

RTT
• CongWin += MSS*MSS/CongWin
• This is the additive increase – linear
• If detection of congestion feedback:
• Triple Duplicate ACKs
• Drop the transmission rate by half
• This is the multiplicative decrease
• Go to the Fast Recovery phase
• Timeout time
• Set ssthresh to FlightSize/2
• Set CongWin to 1 MSS
• Go to Slow Start phase
Computer and Communication Networks 39
Triple Duplicate ACKs
• Detection of congestion by timeout
Host A Host B
• Switch to Slow Start SN1

• This significantly reduces performance due to long delay SN2


SN3 ACK2
SN4 ACK3

• Detection of triple duplicate ACKs SN5


ACK3

SN6
• whenever receiver gets a valid but out-of-order segment, it ACK3
ACK3
immediately sends back an ACK telling which expected seq
# it is waiting for Retransmit SN3

ACK7
• TCP does not use NACK
• when there are more than 3 out-of-order segments
arrived, this is likely to be a packet loss signal
• Switch to Fast Recovery with Fast Retransmit

Computer and Communication Networks 40


Fast Recovery with Fast Retransmit
(TCP Reno)
• TCP performs a Fast Retransmit
• retransmitting what appears to be missing segment without waiting for timeout
• Fast Recovery
• TCP cuts down the transmission rate by half
• ssthresh = FlightSize/2
• CongWin = ssthresh + 3*MSS
• account for the three segments that triggered duplicate ACKs
• each time another duplicate ACK arrives
• increment CongWin by one segment size and transmit a new segment if allowed by the new value of
CongWin
• when a non-duplicate ACK arrived (that means, your retransmitted segment reached the other
end successfully)
• set CongWin = ssthresh
• Go to Congestion Avoidance phase

Computer and Communication Networks 41


TCP Congestion Behavior
70 • when CongWin < ssthresh, sender in slow-
start phase, window grows exponentially
60
CongWin size (units of MSS)

ssthresh
50 • when CongWin >= ssthresh, sender is in
congestion-avoidance phase, window grows
linearly
40

30
• when triple duplicate ACK occurs, ssthresh
set to CongWin/2, CongWin set to ~ ssthresh
20

10 • when timeout occurs, ssthresh set to


CongWin/2, CongWin set to 1 MSS, back to
0
slow-start
0 50 100 150 200 250
Time

Computer and Communication Networks 42


TCP SACK RFC 6675

• SACK feature is enabled by default in Linux,


Windows, and macOS Host A Host B

SN1

• An extension of TCP Reno to improve the


SN2
SN3 ACK2
SN4 ACK3

performance in handling multiple dropped SN5


SN6 ACK3 SACK4-5

segments in one RTT SN7


ACK3 SACK 4-5, 6-7
ACK3 SACK 4-5, 6-8

• TCP Reno can only retransmit one lost segment per RTT SN3

• Similar to Selective Repeat, TCP uses the SACK option to ACK5 SACK 6-8

indicate which non-contiguous blocks of data have been


received and queued

Computer and Communication Networks 43


TCP SACK
• Sender marks all SACK segments • Sender upon receiving an ACK that does
not cover RecoverPoint
• When sender receives the third duplicate • Marks new SACK segment covered by this
ACK, transits to Fast Retransmission and ACK
Recovery phase
• Recalculates the pipe variable
• Records the highest seq# transmitted so far
➔ RecoveryPoint • Updates the cwnd variable
• Sets the highest ACK# ➔ HighACK • if cwnd - pipe >= sender's MSS
• ssthresh = cwnd = (FlightSize/2) • Retransmits next missing segment (if there is
one) or sends a new segment
• Retransmits the 1st missing segment • Updates the pipe variables to add the just
• Calculates the number of outstanding (re)transmitted segment
packets (or bytes) in flight ➔ pipe
• Upon receiving a cumulative ACK for a
• i.e., all unSACKed packets
seq# greater than RecoveryPoint,
terminates the Recovery phase

Computer and Communication Networks 44


TCP CUBIC RFC 8312

• Now adopted by Linux, Mac, and Windows


• Primary goal is to support networks with large bandwidth × delay
products, which are sometimes called long-fat networks (LFN)
• With LFN, CongWin may be grew to quite large value
• Once drop to half, TCP Reno additive increase requiring too many round-trips to
reach the previously available capacity
• The name TCP CUBIC comes from the use of a cubic function to control
the congestion window increase function rather linearly
• For the slow start phase and the fast recovery phase, TCP CUBIC is
similar to TCP Reno

Computer and Communication Networks 45


TCP CUBIC

• The main difference is the Congestion Avoidance phase


• TCP uses a cubic function to set the CongWin (assume no further loss event)
𝑊 𝑡 = 𝐶(𝑡 − 𝐾)3 +𝑊𝑚𝑎𝑥
• t is the elapsed time since the last window reduction
• C is a constant (default 0.4)
• Wmax is the window size when loss was last detected
• K is the time period the function takes to increase W to Wmax and is derived as follows
3 (1 − 𝛽)𝑊𝑚𝑎𝑥
𝐾=
𝐶
•  is the multiplicative decrease factor, the recommended value is 0.7
• Thus, at the beginning of the CA phase, CongWin = 0.7  Wmax

Computer and Communication Networks 46


TCP CUBIC

• Cubic functions can have both convex and concave portions


• Concave portion
• Quickly ramp up the window to get close to Wmax and probe cautiously for bandwidth as
it approaches Wmax
• This is definitely faster than linearly
• Convex portion
• Slowly increase the growth rate as you move away from Wmax; but move quickly when
further away from Wmax
• This is essentially probing for a new achievable Wmax

Computer and Communication Networks 47


Summary
• TCP is a stream-oriented protocol that connects as an imaginary pipe between the two
ends; where as UDP treats each application message as an individual unit.
• Each byte in the TCP segment has a sequence number, but TCP header only carries the
sequence number of the first data byte contained in that segment.
• One important function of 3-way handshaking is to initialize the TCP state variables
(e.g. seq #, MSS, AdvertisedWindow, . . ) associated with the TCP connection on both
sides.
• Both ends in the TCP must call the close to teardown the connection. Thus, it is possible
that one end has teardown, while the other end still remains open
• Another special feature of connection termination is the TIME_WAIT state, which
allows the TCP stack to response to retransmit FIN because of the ACK is lost

Computer and Communication Networks 48


Summary
• The retransmission time (Timeout) can be made dynamically by basing
on the RTT. As RTT may be varied due to the network condition, most
formula take some running average as the estimated of RTT
• TCP decouples the flow control mechanism with its sliding window.
Receive an ACK does not slide the sender window forward. It is
controlled by the Receive Window which is managed by the receiver
• TCP makes use of timeout and duplicate ACKs as the signals of network
congestion. If the sender perceives that there is little congestion, then it
increases its send rate; if sender perceives that there is congestion, it
reduces its send rate.

Computer and Communication Networks 49

You might also like