TCP connection management

1
TCP connection management
1
2
Establishing ConnectionThree-Way handshake

• Each side notifies other of starting sequence
  number it will use for sending
• Why not simply chose 0?
• Must avoid overlap with earlier incarnation
• Security issues
• Each side acknowledges others sequence number
• SYN-ACK Acknowledge sequence number 1
• Can combine second SYN with first ACK

SYN SeqC
ACK SeqC1 SYN SeqS
ACK SeqS1
Client
Server
3
TCP State Diagram Connection Setup
CLOSED
active OPEN
create TCB Snd SYN
passive OPEN
CLOSE
create TCB
delete TCB
CLOSE
LISTEN
delete TCB
SEND
rcv SYN
SYN SENT
SYN RCVD
snd SYN
snd SYN ACK
rcv SYN
snd ACK
Rcv SYN, ACK
rcv ACK of SYN
Snd ACK
CLOSE
ESTAB
Send FIN
4
Tearing Down Connection

• Either side can initiate tear down
• Send FIN signal
• Im not going to send any more data
• Other side can continue sending data
• Half open connection
• Must continue to acknowledge
• Acknowledging FIN
• Acknowledge last sequence number 1

A
B
FIN, SeqA
ACK, SeqA1
Data
ACK
FIN, SeqB
ACK, SeqB1
5
State Diagram Connection Tear-down
CLOSE
ESTAB
send FIN
CLOSE
rcv FIN
send FIN
send ACK
CLOSE WAIT
FIN WAIT-1
rcv FIN
CLOSE
snd ACK
ACK
snd FIN
rcv FINACK
FIN WAIT-2
CLOSING
LAST-ACK
snd ACK
rcv ACK of FIN
rcv ACK of FIN
TIME WAIT
CLOSED
rcv FIN
Timeout2msl
snd ACK
delete TCB
6
TCP SACK
6
7
SACK

• Basic problem is that cumulative acks provide
  little information
• Selective acknowledgement (SACK) essentially adds
  a bitmask of packets received
• Implemented as a TCP option
• Encoded as a set of received byte ranges
• (max of 4 ranges/often max of 3)?

8
Selective ACKnowledgements (SACK)?

• TCP SACK options specify the blocks of data
  received in terms of blocks
• Block contiguous range of data received
• Left edge specified first sequence number
• Right edge specifies last sequence number 1
• Header has 40 bytes for TCP option
• 2 bytes for TCP options Kind and Length
• 38 bytes remaining specify 4 block ranges at
  most

9
TCP (Reno variant)?
X
X
X
Now what? - timeout
X
Sequence No
Time
10
SACK
X
X
X
Now what? send retransmissions as soon as
detected
X
Sequence No
Time
11
TCP ECN
11
12
Explicit Congestion Notification (ECN)?

• Active Queue Management
• monitor queue, do not just drop upon overflow ?
  more intelligent decisions
• maintain low average queue length, alleviate
  phase effects, enforce fairness
• Explicit Congestion Notification (ECN)?
• Instead of dropping, set a bit reduced loss ?
  major benefit!
• Receiver informs sender about bit sender behaves
  as if a packet was dropped
• ? actual communication between end nodes and the
  network
• Typical incentives
• sender server efficiently use connection,
  fairly distribute bandwidth
• use ECN as it was designed
• receiver client goal high throughput, does
  not care about others
• ignore ECN flag, do not inform sender about it
• Need to make it impossible for receiver to lie
  about ECN flag when it was set
• Solution nonce random number from sender,
  deleted by router when setting ECN
• Sender believes no congestion iff correct nonce
  is sent back

13
ECN in action

• Nonce provided by bit combination
• ECT(0) ECT1, CE0
• ECT(1) ECT0, CE1
• Nonce usage specification still experimental

14
TCP Window Scale Option for Gigabit Networks
15
TCP Maximum Throughput

• A TCP connections maximum achievable throughput
  is limited by the minimum of the TCP senders
  socket send buffer and the TCP receivers socket
  receive buffer.
• Min(socket send buffer on the sender, socket
  receive buffer on the receiver) / RTT.
• Although we can use setsockopt() to enlarge the
  socket send and receive buffer to a big value,
  the advertised window field in the TCP header is
  only 16 bits, which means a maximum window size
  of 64 KB only.
• On gigabit networks, clearly this is not enough.

16
TCP Window Scale Option

• In this scheme, the definition of the TCP window
  is enlarged from 16 to 32 bits.
• The window field in the header still uses 16
  bits, but a option is defined that applies a
  scaling operation to the 16-bit values.
• During the 3-way handshaking phase, this option
  is carried in the SYN and SYNACK packets to
  indicate whether the option is supported.
• In TCP implementation, the real window size is
  internally maintained as a 32-bit value.
• The shift field in the option is 1-byte long.
• 0 means no scaling is performed.
• 14 is the maximum, allowing 64KB 214.

17
TCP Window Scale Option

• This option can only appear in a SYN packet.
  Therefore, the scale factor is fixed in each
  direction when the connection is established.
• The shift count is automatically calculated by
  TCP, based on the size of the socket receive
  buffer.
• Keep dividing the buffer size by 2 until the
  resulting number is less than 64 KB.
• Each host thus maintains two shift counts S for
  sending and R for receiving.
• Every 16-bit advertised window that is received
  from the other end is left-shifted by R bits to
  obtain the real advertised window.
• When we need to send a window advertisement to
  the other end, the real window size is
  right-shifted by S bits, and the resulting 16-bit
  value is placed in the TCP header.

18

• Questions?