TCP, Part 2
TCP Flow Control
Copyright By PowCoder代写 加微信 powcoder
So far, this is what we know about TCP:
1. PIPE-LINED PROTOCOL
2. SEQUENCE NUMBER – Uses byte-stream order of
3. CUMULATIVE ACK
4. 1 TIMER CONTROL – associated with the oldest
unACKed segment
5. Dynamically estimates the Timeout interval using an
Exponential Weighted Moving Average technique
6. Buffers out-of-order segments
7. Employs a flow control mechanism
8. Employs a congestion control mechanism
9. Tries to allocate bandwidth fairly among users of TCP.
TCP with MODIFICATIONS: DOUBLING THE TIMEOUT INTERVAL SENDER Provides a limited form of congestion control
Timer expiration is more likely caused by congestion in the network
Congestion may get worse if sources continue to retransmit packets persistently.
Let the timeout interval grow exponentially after each retransmission.
After a timeout event,
TimeoutInterval = 2 * TimeoutIntervalPrevious
TCP acts more politely by increasing the TimeoutInterval, causing the sender to retransmit after longer and longer intervals.
After an ACK is received, or a new data is received from the application layer above, the TimeoutInterval is derived
Others: check RFC 2018 – selective ACK
from most recent EstimatedRTT and DevRTT
TCP Receiver: ACK Generation [RFC 1122, RFC 2581] Note: Receiver does not discard out-of-order segments
in-order segment arrival,
everything else already ACKed
Delay sending the ACK. Wait up to 500ms for next segment. If next segment does not arrive in this interval, send ACK
TCP Receiver action
in-order segment arrival, no gaps, one delayed ACK
immediately send a single cumulative ACK
(due to action 1)
out-of-order segment arrival 3 with higher than expect seq. #
send duplicate ACK, indicating seq. # of next expected byte
– a gap is detected
arrival of segment that
4 partially or completely fills gap
Immediately send an ACK if segment starts at lower end of gap
TCP with MODIFICATIONS: FAST RETRANSMIT SENDER
01 Why wait for the 02
timeout to expire, when consecutive ACKs can be used to indicate a lost segment
03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
loop (forever) {
switch(event)
event: data received from application above
With Fast Retransmit
start timer }
This is slightly different from Go-Back N, as the ACK here has a different meaning. ACK = last byte received + 1
/* perform TCP fast retransmission */ resend segment with sequence number y
sendbase = initial_sequence number nextseqnum = initial_sequence number
create TCP segment with sequence number nextseqnum If (timer currently not running)
start timer for segment nextseqnum pass segment to IP
nextseqnum = nextseqnum + length(data)
event: timer timeout
retransmit not yet ACKed segment with smallest sequence number restart timer
event: ACK received, with ACK field value of y
if (y > sendbase) { /* cumulative ACK of all data up to y-1 */
sendBase = y
if (there are currently not-yet-acknowledged segments)
else { /* a duplicate ACK for already ACKed segment */
increment number of duplicate ACKs received for y if (number of duplicate ACKS received for y is 3) {
} /* end of loop forever */
TCP with MODIFICATIONS: FAST RETRANSMIT Example:
ACK 100 is > sendBase and there are yet to be ACKed segments (restart timer)
The missing segment (with Seq=100) is retransmitted before the timer expires
duplicate ACK duplicate ACK
duplicate ACK
Prevent the sender from overwhelming the receiver.
Let the receiver communicate to the sender how much data it can still receive, as part of the ACK segment.
TCP Flow Control
flow control
receiver: explicitly informs sender of (dynamically changing) amount of free buffer space
sender won’t overrun receiver’s buffer by transmitting too much,
RcvWindow field in TCP segment
RcvBuffer = size of TCP Receive Buffer RcvWindow = amount of spare room in Buffer
of transmitted, unACKed
receiver buffering
LastByteRead
sender: keeps the amount
data less than most
recently received
It is assumed here that the Receiver discards out-of-order segments.
FLOW CONTROL: Receiver EXAMPLE: HOST A sends a large file to HOST B
RECEIVER: HOST B – uses RcvWindow, LastByteRcvd, LastByteRead
• RcvBuffer: typical default is 4096 bytes
• many operating systems autoadjust
LastByteRead
Data from IP (network layer)
Application Process
60 50 40 0
LastByteRcvd
It is assumed here that the Receiver discards out-of-order segments.
IHnOitiSaTllyB, R(RcevcWeiivnedro)wtel=lsRHcOvBSuTffAer(Sender) how much spare room it has in the Application reads from the buffer
connection buffer by placing its current value of RcvWindow in the receive RcvBuffer
window field of every segment it sends to HOST A (Sender). RcvWindow=RcvBuffer-[LastByteRcvd-LastByteRead]
FLOW CONTROL: Sender EXAMPLE: HOST A sends a large file to HOST B
SENDER: HOST A – uses RcvWindow of HostB, LastByteSent, LastByteACKed LastByteACKed
SENDER: HOST A
Data from Application Layer
ACK from Host B,
80 70 60 0
LastByteSent
sender limits amount of unACKed (“in-flight”) data to received RcvWindow
It is assumed here that the Receiver discards out-of-order segments.
To ensure that HOST B does not overflow, HOST A maintains throughout the connection’s life that [LastByteSent-LastByteACKed] <= RcvWindow
including RcvWindow
Some issue to consider:
when the receive
TCP requires that HOST A continue to send segments with one data byte when HOST B’s receive window is 0. Such segments will be ACKed by HOST B.
buffer of HOST B is
full ? (that is, when RcvWindow=0)
TCP sends a segment only when there is data or ACK to send. Therefore, the sender must maintain the connection ‘alive’.
Eventually, the buffer will have some space and the ACKs will contain RcvWindow > 0 11
FLOW CONTROL
RcvWindow – used by the connection to provide the flow control service
What happens
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com