RSS
Twitter
Facebook
Showing posts with label TCP. Show all posts
COMPUTER NETWORKS-I × TCP
• Indirect TCP to split the TCP
connection into two separate connections
• first one from sender to base
station the second from base station to receiver
• the advantage is both
connections are homogeneous
• The disadvantage is that it
breaks the semantics of TCP
• There is another solution for
keeping the semantics of TCP is the Transactional
TCP
Transactional TCP
The above figure (a) shows the
normal RPC call where nine messages are exchanged between the client and the
server
Figure (b) shows the one with
Transactional TCP T/TCP where request and SYN and also FIN are sent together
thus reducing the messages and providing faster service
COMPUTER NETWORKS-I × TCP
• Jacobson algorithm
• Another smoothed value D
deviation it is the difference between the expected
and observed value |RTT-M|
• D= α D+(1- α )|RTT-M|
• Timeout interval =RTT+4*D
• The problem with retransmission
answered by Karn’s algorithm
• RTT not updated for
retransmitted segment timeout is doubled on each failure till
the segment gets through first
time
• There is another timer called
the persistence timer- it is used when the sender is made to wait due to lack
of buffer space at the receiver. Once this timer goes off the sender sends the
probe to find about the receiver buffer space otherwise a deadlock occurs so
this timer is used to resolve the same
• The third timer is the
keepalive timer- it is used for the connections which are idle for a long time
suppose this timer goes off then the connection is closed
COMPUTER NETWORKS-I × TCP
how to set TCP timeout value?
• longer than RTT
– note: RTT will vary
• too short: premature timeout
– unnecessary retransmissions
• too long: slow reaction to
segment loss
• The algorithm is based on
continuous measurements of network performance
• Jacobson algorithm is one used
for calculating RTT
• For each connection a value RTT
is maintained
• RTT updated using the formula
• RTT=αRTT+(1- α)M
• Where M is time taken for ACK
• And α is the smoothing factor
• And α=7/8
COMPUTER NETWORKS-I × TCP
• How TCP prevents congestion
• when connection established,
window size chosen
• Receiver specifies seeing its
buffer size
• Still congestion occurs
• The two problems are Network
Capacity and Receiver Capacity
• Solution?
• Solution
• Sender maintains two windows:
one the receiver granted
• the other Congestion Window
• at the connection
establishment- the congestion window is set to the size of the
maximum segment in use on the
connection
• Each burst acknowledged doubles
the congestion window
• Congestion window grow
exponentially
• This is called the Slow Start
algorithm
• Another Solution?
• Solution
• Uses threshold
• initially some value in
addition to the receiver and congestion window
• When timeout threshold is set
to half of the current congestion window
• Congestion window is set to one
max segment
• Slow start is used to find what
the network can handle
• Exponential growth stops when
threshold hit
• From that point congestion window grow linearly
• Example
• Segment size=1K
• Congwin=64KB
• when timeout threshold=34KB
• Congwin=1KB
• the congstion window grows
exponentially until it hits threshold and then linearly
COMPUTER NETWORKS-I × TCP
• Sender & receiver negotiate
on window size
• In the figure below the sender
sends 2K data and the initial seq no
• The receiver sends the ack for
the next seq no it is expecting and also advertises
the widow size
• Suppose the window is zero then
sender waits and then sends a probe and then
sends the next set of data
• The diagram shows how the two
sides communicate
• Suppose there is only one byte
to be sent the 41 byte packet to be sent instead Nagle algorithm suggest that
when the first byte comes it is sent and the other buffered till the ack
received and then send the rest and wait for the ack and like this a sufficient
no of bytes go in one segment
Silly window
syndrome
At the receiver side even if a
byte available at its buffer it advertised and the sender sends
the buffer is full the sender
waits again and probes to get the window size so this will
continue and a loop formed to
avoid this the receiver is forced to wait till good amount of
buffer space availability and
then advertises and avoids the loop.
TCP Congestion
control
Congestion:
• informally: “too many sources
sending too much data too fast for network to
handle”
• different from flow control!
• manifestations:
– lost packets (buffer overflow
at routers)
– long delays (queueing in router
buffers)
Problems when
congestion happens
COMPUTER NETWORKS-I × TCP
• Server waits by executing
LISTEN and ACCEPT primtives
• Client executes a CONNECT
primitive specifying IP and PORT no, max TCP
TCP connection management
• segment size and user data
• CONNECT sends TCP segment with
SYN bit ON and ACK off
• Server can either accept or
reject connection
• In call collision only one
connection is established
• Connection released using FIN
bit
• One FIN and one ACK in each
direction
• possible to combine first ACK
and second FIN in the same segment
Finite state
machine
• Management on client side
• When client issue CONNECT, TCP
entity sends SYN segment
• Separate state for each
connection
• When ACK arrives the final ACK
sent and switches to new state
• Data transfer
• when no data issue CLOSE
primitive sends FIN segment
• One side goes to WAIT and waits
for the FIN from other side
• Packet life time taken care too
• Management on server side
• When server issue LISTEN and
waits for incoming request
• When SYN comes the server
responds with ACK
• When three way handshake
complete then server goes to new state
• FIN is sent when server want to close
