Transcript Network Overview

TCP
7/21/2015
1
TCP Adaptive Retransmission
Algorithm - Original

Theory



Practice



Estimate RTT
Multiply by 2 to allow for variations
Use exponential moving average (A = 0.1 to 0.2)
Estimate = (A) * measurement + (1- A) * estimate
Problem


Did not handle variations well
Ambiguity for retransmitted packets

7/21/2015
Was ACK in response to first, second, etc transmission?
2
TCP Adaptive Retransmission
Algorithm – Karn-Partridge

Algorithm


Exclude retransmitted packets from RTT
estimate
For each retransmission



Double RTT estimate
Exponential backoff from congestion
Problem


7/21/2015
Still did not handle variations well
Did not solve network congestion problems as
well as desired
3
TCP Adaptive Retransmission
Algorithm – Jacobson

Algorithm

Estimate variance of RTT





Use variance estimate as component of RTT estimate



Calculate mean interpacket RTT deviation to approximate variance
Use second exponential moving average
Deviation = (B) * |RTT_Estimate – Measurement| + (1–B) * deviation
B = 0.25, A = 0.125 for RTT_estimate
Next_RTT = RTT_Estimate + 4 * Deviation
Protects against high jitter
Notes


7/21/2015
Algorithm is only as good as the granularity of the clock
Accurate timeout mechanism is important for congestion control
4
TCP Connection
Establishment

3-Way Handshake

Sequence Numbers



listen
Synchronize (SYN)
Acknowledge (ACK)
Server listens for
connection from client
Active Open

7/21/2015
J,K
Passive Open


Server
Message Types


Client
Client initiates connection
to server
Time flows down
5
TCP Connection Termination

Message Types



Client
Server
Active Close


Finished (FIN)
Acknowledge (ACK)
Sends no more data
Passive close

Accepts no more data
Time flows down
7/21/2015
6
TCP Connection Management (cont)
TCP server
lifecycle
TCP client
lifecycle
7/21/2015
7
TCP State Descriptions
CLOSED
Disconnected
LISTEN
Waiting for incoming connection
SYN_RCVD
Connection request received
SYN_SENT
Connection request sent
ESTABLISHED
Connection ready for data transport
CLOSE_WAIT
Connection closed by peer
LAST_ACK
Connection closed by peer, closed locally, await ACK
FIN_WAIT_1
Connection closed locally
FIN_WAIT_2
Connection closed locally and ACK’d
CLOSING
Connection closed by both sides simultaneously
TIME_WAIT
Wait for network to discard related packets
7/21/2015
8
TCP State Transition Diagram
Active
open/SYN
CLOSED
Passive open
Close
SYN/SYN + ACK
SYN_RCVD
ACK
SYN/SYN + ACK
ESTABLISHED
ACK
FIN +
ACK/ACK
FIN/ACK
SYN + ACK/ACK
CLOSE_WAIT
CLOSING
FIN_WAIT_2
SYN_SENT
FIN/ACK
FIN/ACK
FIN_WAIT_1
7/21/2015
LISTEN
Send/SYN
Close/ACK
Close/FIN
Close
Close/FIN
ACK
LAST_ACK
TIME_WAIT
ACK
Timeout
CLOSED
9
TCP State Transition Diagram

Questions

State transitions




TIME_WAIT state



7/21/2015
Describe the path taken by a server under normal
conditions
Describe the path taken by a client under normal
conditions
Describe the path taken assuming the client closes the
connection first
What purpose does this state serve
Prove that at least one side of a connection enters this
state
Explain how both sides might enter this state
10
TCP State Transition Diagram
Active
open/SYN
CLOSED
Passive open
SYN/SYN + ACK
SYN_RCVD
Close
Close
LISTEN
Send/SYN
ACK
SYN/SYN + ACK
SYN_SENT
SYN + ACK/ACK
ESTABLISHED
1.
2.
3.
4.
5.
TCP A
CLOSED
SYN-SENT
ESTABLISHED
ESTABLISHED
ESTABLISHED
7/21/2015
TCP B
LISTEN
--> <SEQ=100><CTL=SYN>
-->
SYN-RECEIVED
<-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
--> <SEQ=101><ACK=301><CTL=ACK>
-->
ESTABLISHED
--> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED
11
TCP State Transition Diagram
Active
open/SYN
CLOSED
Passive open
Close
SYN/SYN + ACK
SYN_RCVD
ACK
SYN/SYN + ACK
ACK
ESTABLISHED
FIN/ACK
CLOSE_WAIT
CLOSING
FIN_WAIT_2
FIN +
ACK/ACK
FIN/ACK
SYN_SENT
SYN + ACK/ACK
FIN/ACK
FIN_WAIT_1
7/21/2015
LISTEN
Send/SYN
Close/FIN
Close/FIN
Close
Close/FIN
ACK
LAST_ACK
TIME_WAIT
ACK
Timeout
CLOSED
12
TCP Sliding Window Protocol

Sequence numbers


ACK sequence number


Enables dynamic receive window size
Receive buffers



Actually next byte expected as opposed to last byte received
Advertised window


Indices into byte stream
Data ready for delivery to application until requested
Out-of-order data out to maximum buffer capacity
Sender buffers


7/21/2015
Unacknowledged data
Unsent data out to maximum buffer capacity
13
TCP Sliding Window Protocol
– Sender Side



LastByteAcked <= LastByteSent
LastByteSent <= LastByteWritten
Buffer bytes between LastByteAcked and LastByteWritten
Maximum buffer size
Advertised window
Data available, but
outside window
First unacknowledged byte
7/21/2015
Last byte sent
14
TCP Sliding Window Protocol
– Receiver Side



LastByteRead < NextByteExpected
NextByteExpected <= LastByteRcvd + 1
Buffer bytes between NextByteRead and LastByteRcvd
Maximum buffer size
Advertised window
Buffered, out-of-order data
Next byte expected (ACK value)
Next byte to be read by application
7/21/2015
15
TCP ACK generation - 1
Maximum buffer size
Available buffer size
Next byte expected (ACK value)
Next byte to be read by application

Arrival of in-order segment with expected seq #. All
data up to expected seq # already ACKed

7/21/2015
Delayed ACK. Wait up to 500ms for next segment.
16
TCP ACK generation - 2
Maximum buffer size
Available buffer size
Next byte expected (ACK value)
Next byte to be read by application

Arrival of in-order segment with expected seq #. One
other segment has ACK pending

7/21/2015
Immediately send single cumulative ACK, ACKing both inorder segments
17
TCP ACK generation - 3
Maximum buffer size
Available buffer size
Next byte expected (ACK value)
Next byte to be read by application

Arrival of out-of-order segment higher-than-expect
seq. # Gap detected

7/21/2015
Immediately send duplicate ACK, indicating seq. # of next
expected byte
18
TCP ACK generation - 4
Maximum buffer size
Available buffer size
Next byte expected (ACK value)
Next byte to be read by application

Arrival of segment that partially or completely fills gap

Immediate send ACK, provided that segment starts at lower end of
gap
7/21/2015
19
TCP ACK generation
[RFC 1122, RFC
2581]
Event at Receiver
TCP Receiver action
Arrival of in-order segment with
expected seq #. All data up to
expected seq # already ACKed
Delayed ACK. Wait up to 500ms
for next segment. If no next segment,
send ACK
Arrival of in-order segment with
expected seq #. One other
segment has ACK pending
Immediately send single cumulative
ACK, ACKing both in-order segments
Arrival of out-of-order segment
higher-than-expect seq. # .
Gap detected
Immediately send duplicate ACK,
indicating seq. # of next expected byte
Arrival of segment that
partially or completely fills gap
Immediate send ACK, provided that
segment starts at lower end of gap
7/21/2015
20
Fast Retransmit

What’s the problem
with time-out?



time-out period often
relatively long
Detect lost segments
via duplicate ACKs.


7/21/2015
Sender often sends
many segments backto-back
If segment is lost, there
will likely be many
duplicate ACKs.

If sender receives 3
ACKs for the same
data, it supposes
that segment after
ACKed data was
lost:

fast retransmit:
resend segment
before timer expires
Why 3?
21
Fast retransmit algorithm:
event: ACK received, with ACK field value of y
if (y > SendBase) {
SendBase = y
if (there are currently not-yet-acknowledged segments)
start timer
}
else {
increment count of dup ACKs received for y
if (count of dup ACKs received for y = 3) {
resend segment with sequence number y
}
a duplicate ACK for
already ACKed segment
7/21/2015
fast retransmit
22
A 4th situation?

Receiver side
Maximum buffer size
Available buffer size
What if?
Buffered, out-of-order data
Next byte expected (ACK value)
Next byte to be read by application
7/21/2015
23
TCP Flow Control
Sender
Maximum buffer size
Sliding window
First unacknowledged byte
Receiver
Data available, but
Last byte sent outside window
Maximum buffer size
Available buffer size
7/21/2015
Next byte to be read
by application
Buffered, out-of-order data
Next byte expected (ACK value)
Avoid?
24
Flow Control vs. Congestion
Control

Flow control


Congestion control


Preventing senders from overrunning the
capacity of the receivers
Preventing too much data from being injected
into the network, causing switches or links to
become overloaded
TCP provides both


7/21/2015
flow control based on advertised window
congestion control discussed later in class
25
TCP Flow Control

Receiving side



Receive buffer size = MaxRcvBuffer
LastByteRcvd - LastByteRead < = MaxRcvBuffer
AdvertisedWindow = MaxRcvBuffer - (NextByteExpected NextByteRead)



Shrinks as data arrives and
Grows as the application consumes data
Sending side



Send buffer size = MaxSendBuffer
LastByteSent - LastByteAcked < = AdvertisedWindow
EffectiveWindow = AdvertisedWindow - (LastByteSent LastByteAcked)



7/21/2015
EffectiveWindow > 0 to send data
LastByteWritten - LastByteAcked < = MaxSendBuffer
block sender if (LastByteWritten - LastByteAcked) + y
> MaxSenderBuffer
26
TCP Flow Control

Problem: Slow receiver application





Advertised window goes to 0
Sender cannot send more data
Non-data packets used to update window
Receiver may not spontaneously generate update or
update may be lost
Solution



7/21/2015
Sender periodically sends 1-byte segment, ignoring
advertised window of 0
Eventually window opens
Sender learns of opening from next ACK of 1-byte
segment
27
TCP Flow Control

Problem: Application delivers tiny pieces of data to
TCP




Example: telnet in character mode
Each piece sent as a segment, returned as ACK
Very inefficient
Solution


Delay transmission to accumulate more data
Nagle’s algorithm




7/21/2015
Send first piece of data
Accumulate data until first piece ACK’d
Send accumulated data and restart accumulation
Not ideal for some traffic (e.g. mouse motion)
28
TCP Flow Control

Problem: Slow application reads data in tiny
pieces




Receiver advertises tiny window
Sender fills tiny window
Known as silly window syndrome
Solution


7/21/2015
Advertise window opening only when MSS or
1/2 of buffer is available
Sender delays sending until window is MSS or
1/2 of receiver’s buffer (estimated)
29
TCP Bit Allocation Limitations

Sequence numbers vs. packet lifetime




Assumed that IP packets live less than 60
seconds
Can we send 232 bytes in 60 seconds?
Less than an STS-12 line
Advertised window vs. delay-bandwidth



7/21/2015
Only 16 bits for advertised window
Cross-country RTT = 100 ms
Adequate for only 5.24 Mbps!
30
TCP Sequence Numbers –
32-bit
Bandwidth
Speed
Time until wrap around
T1
1.5 Mbps
6.4 hours
Ethernet
10 Mbps
57 minutes
T3
45 Mbps
13 minutes
FDDI
100 Mbps
6 minutes
STS-3
155 Mbps
4 minutes
STS-12
622 Mbps
55 seconds
STS-24
1.2 Gbps
28 seconds
7/21/2015
31
TCP Advertised Window –
16-bit
Bandwidth
Speed
Max RTT
T1
1.5 Mbps
350 ms
Ethernet
10 Mbps
52.4 ms
T3
45 Mbps
11.6 ms
FDDI
100 Mbps
5.2 ms
STS-3
155 Mbps
3.4 ms
STS-12
622 Mbps
843 µs
STS-24
1.2 Gbps
437 µs
7/21/2015
32