1 unit 5 transport layer. 2 topics introduction to tcp the tcp service elements of transport...
TRANSCRIPT
1
Unit 5
Transport layer
2
Topics
Introduction to TCP The TCP service Elements of transport protocol The TCP segment header Connection establishment Connection release Modeling TCP management UDP Performance issues
3
Transport layer functions
Provide end to end communication function Connect applications with the network layer Optional: Packet assembly, disassembly, sequencing end to end acknowledgment High level flow/ congestion control Error checking
4
The TCP service
5
The TCP Service
Services provided to the upper layers Transport service primitives Berkeley sockets
6
Services Provided to the Upper LayersThe network, transport, and application layers.
7
The task of transport layer is to provide reliable, cost effective transport of data from source machine to destination machine
To achieve this goal transport layer makes use of the services provided by the network layer.
The transport services are of two types: Connection oriented Connectionless
Addressing and flow control in transport layer is similar to that in the network layer
Even though network and transport layer provide similar services, the transport layer can improve the QoS which a network layer cannot do
Services Provided to the Upper Layers
8
If a transport entity is told that its network connection is abruptly terminated, then it can set a new network connection to the remote transport entity
Through this new connection it can ask about which data has already arrived and which is yet to arrive
The transport service primitives can be designed to be independent of the network service primitives
The transport layer isolates the upper layers from the technology, design and imperfections of the subnet
Hence layers of reference model are divided into 2 groups
Layers 1 to 4 form the 1st group transport service provider
Layers above 4 are called transport service users
Services Provided to the Upper Layers
9
Transport Service Primitives
• Transport service primitives allow the transport user such as application programs to access the transport service
The primitives for a simple transport service.
10
The server executes the LISTEN primitive This will make a system call to block the
server until a client turns up When the clients wants to talk to the server it
executes the CONNECT primitive In response the transport entity blocks the
caller and sends a packet to the server. The transport layer message is encapsulated in the payload of this packet for the server’s transport entity
Transport Service Primitives
11
Transport Service Primitives
The nesting of TPDUs, packets, and frames.
12
Transport Service Primitives
A state diagram for a simple connection management scheme. Transitions labeled in italics are caused by packet arrivals. The solid lines show the client's state sequence. The dashed lines show the server's state sequence.
13
Berkeley Sockets• The socket interface was originally based on UNIX. It defines a
set of system calls or procedures
• The communication structure that we need in socket programming is called as socket. A socket acts as an endpoint
Fig. The socket primitives used in Berkeley UNIX for TCP.
14
Steps followed for socket programming: Server side:
Server creates a socket and checks for errors using SOCKET
Assign address to newly created socket using BIND Use the LISTEN to allocate space to queue the incoming
calls Execute an ACCEPT for blocking the waiting incoming
connections Client side:
Create a socket using SOCKET Use CONNECT to initiate connection process Establish the connection
Berkeley Sockets
15
Elements of transport protocol
16
Transport Protocol
(a) Environment of the data link layer.(b) Environment of the transport layer.
17
Transport Protocol
No Data link layer Transport layer1 Communication is through a
physical channelCommunication is through a subnet
2 It is not necessary to specify the destination router
Explicit addressing of destination is essential
3 Establishing a connection is simple
Initial connection establishment is more complicated
4 No storage capacity There is some storage capacity in the subnet
5 No additional delay Delay is introduced due to the storing capacity of subnet
6 Different approaches are used for buffering and flow control by the two layers
18
Elements of Transport Protocols
• Addressing• Connection Establishment• Connection Release• Flow Control and Buffering• Multiplexing• Crash Recovery
19
Addressing
TSAPs, NSAPs and transport connections.
20
If a remote process wants to get connected to another remote process, then it has to specify the one to which connection is established
So a transport address is defined. This is the address to which processes can listen for connection requests
In transport layer its called as TSAP (Transport Service Access Point)
Transport connection over a connection oriented network layer is as follows:
The time-of-day server process on host 2 gets connected to TSAP 1522 so as to wait for an incoming call. For this it can use the LISTEN call
Addressing
21
An application process on host 1 wants to find out the time of day. So it issues a CONNECT request that specifies TSAP 1208 as the source and TSAP 1522 as the destination
The transport entity on host 1 then sets up a network connection between the two hosts. Such a network layer connection is not required with a connectionless subnet. Using this network connection, the host 1’s transport entity can communicate with transport entity on host 2
Transport entity on host 1 then request a connection between TSAP 1208 and TSAP 1522 to transport entity on host 2
The transport entity on host 2 then asks the time of day server at TSAP 1522 if it is willing to accept a new connection. If it says yes, then a new transport connection is established
Addressing
22
How a user process in host 1 establishes a connection with a
time-of-day server in host 2.
Addressing
23
Connection Establishment
Three protocol scenarios for establishing a connection using a three-way handshake. CR denotes CONNECTION REQUEST. (a) Normal operation, (b) Old CONNECTION REQUEST appearing out of nowhere. (c) Duplicate CONNECTION REQUEST and duplicate ACK.
24
Fig. a Normal operation:
Host 1 chooses a seq. no. x and sends a connection request (CR) TPDU containing it to host 2
Host 2 replies with a connection accepted TPDU to acknowledge x and so announce its own seq. no. y
Host 1 acknowledges host 2 and send first data TPDU
Connection Establishment
25
Fig. b Fig shows the first TPDU is a delayed duplicate
CONNECTION REQUEST from an old connection. The host 1 does not know about it
Host 2 receives this TPDU and sends to host 1, a connection accepted TPDU
But Host 1 is not trying to establish any connection so it sends a REJECT along with ACK=y
So Host 2 realizes that it was fooled by a delayed duplicate and abandons the connection
Connection Establishment
26
Fig. c Duplicate CR and duplicate ACK: This is the worst case in which delayed duplicates of
connection request CR and ACK are floating around in the subnet
Host 2 gets a CR and it replies to it by sending ACK. Note that host 2 has proposed a connection with a sequence no. y
When the 2nd delayed TPDU arrives at host 2 it understands that z has been acknowledged and not y. So it understands that this too is an OLD duplicate
Connection Establishment
27
Connection release
Any one of the two parties involved in data exchange can close the connection
But the problem is that, when connection is terminated from one end, the other party can continue to send data in the other direction
Two styles of releasing the connection are: Asymmetric release:
When one party hangs up the connection is broken. It is an abrupt release and may result in loss of data
Symmetric release: It treats the connection as two separate unidirectional
connections and requires each one to be released separately
It does not involve any loss of data
28
Asymmetric Connection Release
Abrupt disconnection with loss of data.
29
Connection Release
The two-army problem.
30
Protocol 1: Two way handshake Chief of blue army 1 sends a message to the chief
of blue army 2 stating “I propose we attack in the morning of January 1. Is it OK with you? ”
Suppose that the messenger reaches to the blue army 2 and the chief of blue army 2 agrees with the idea
He sends the message “yes” back to blue army 1 and assume that this message also gets through
This process is called two way handshake The question is whether the attack takes place? The
answer is probably not because the chief of blue army 2 does not know whether his reply got through
Connection Release
31
Protocol 2: Three way handshake Assuming no messages lost, blue army 2 will also
get the acknowledgment But now the chief of blue army 1 will hesitate,
because he does not know if the last message he has sent has got through or not
So we can make four way handshake But it also does not help because the uncertainty
after last handshake message always remains In fact we can prove that no protocol exists that
works
Connection Release
32
Connection ReleaseFour protocol scenarios for releasing a connection.
(a) Normal case of a three-way handshake (b) final ACK lost.
6-14, a, b
33
Connection Release
(c) Response lost. (d) Response lost and subsequent DRs lost.
6-14, c,d
34
Flow control and buffering For flow control, a sliding window is needed on each
connection to keep a fast transmitter from overrunning a slow receiver
Since a host may have numerous connections, its impractical to implement the same data link buffering strategy.
The sender should always buffer outgoing TPDUs until they are acknowledged
The receiver may not dedicate specific buffers to specific connections. Instead, a single buffer pool may be maintained for all connections
When a TPDU comes in, if there is a free buffer available, the TPDU is accepted otherwise discarded
35
For high bandwidth traffic, it is better if the receiver dedicate a full window of buffers, to allow the data flow at maximum speed
As the traffic pattern changes, the transport protocol should allow sending host to request buffer space at the other end. Alternatively the receiver could tell the sender “I have reserved buffers for you”
Dynamic buffer management in variable-sized window: Initially the sender requests a certain number of buffers
based on its perceived needs The receiver then grants as many buffers as it can afford Every time the sender transmits a TPDU, it must
decrement its allocation, stopping altogether when the allocation reaches zero
Flow control and buffering
36
The receiver then separately piggybacks both acknowledgements and buffer allocations onto reverse traffic
To prevent deadlock caused by loss of TPDUs, each host should periodically send control TPDUs giving the acknowledgement ad buffer status on each connection
The sender’s window size could be dynamically adjusted not only by the availability of the buffers at the receiver side, but also by the capacity and traffic of the subnet. The bigger the subnet’s carrying capacity and lighter the traffic, larger is the sender’s window size
Flow control and buffering
37
Multiplexing
(a) Upward multiplexing. (b) Downward multiplexing.
38
Crash recovery The host and routers are subject to crashes which
needs recovery coz it results in loss of data packets If transport entity is inside the hosts then recovery
from the network and router crashes is simple In case of a router crash, the two transport entities
must exchange information after the crash to determine which TPDUs were received and which were not. The crash can be recovered by retransmitting the lost ones
If the network layer provides connection-oriented service, then the loss of a virtual circuit can be handled by establishing a new virtual circuit
39
It is difficult to recover from the host crash Suppose that the sender is sending a long file to the receiver
using a simple stop-and-wait protocol. Part way through the transmission the receiver crashes
When the receiver comes back up, it might send a broadcast TPDU to all other hosts, requesting the other hosts to inform it of the status of all open connections before the crash
The sender can be in one of the two states: one TPDU outstanding, or no TPDUs outstanding
Think about the situation when the receiver first sends an ACK and then performs the write but crash occurs in the middle
If crash takes place at layer N, then crash recovery can take place at only N+1 layer only if the higher layer retain enough status information
Crash recovery
40
TCP
41
Properties of TCP
Process- to process communication Stream delivery service Full-duplex communication Connection oriented service Reliable service
42
Process- to process communication
TCP provides process-to-process communication like UDP using port numbers
UDP ports have no relation to TCP ports (different name spaces).
43
Stream delivery service TCP is stream-oriented protocol. In UDP, a process sends messages called user
datagram to receiver by adding header which eventually becomes an IP datagram. Neither IP nor UDP recognizes any relationship between the datagrams.
But TCP allows the sending process to deliver data as a stream of bytes and allows receiving process to obtain data as a stream of bytes.
TCP creates an environment in which the two processes seem to be connected by an imaginary tube that carries their data across the Internet.
44
Stream delivery The sending process produces the stream of bytes and
the receiving process consumes them.
45
Sending and receiving buffers Sending and receiving processes may not write or
read data at the same speed, so TCP uses buffers for storage.
Two buffers – sending and receiving One way to implement a buffer is to use a circular
array of 1-byte locations as shown in figure. For simplicity two buffers of 20bytes are shown,
normally they are of 100s or thousands of bytes. Buffers are shown of same size, which is not always
the case.
46
Sending and receiving buffers contd..
47
Sending and receiving buffers contd..
BUFFER AT SENDER SIDE: At the sending site, the buffer has three types of
chambers. White section contains empty chambers that can be filled
by the sending process. Gray area holds bytes that have been sent but not yet
acknowledged. TCP keeps these bytes in the buffer until it receives an acknowledgement.
The colored area contains bytes to be sent by the sending TCP. After the bytes in the gray chamber are acknowledged, the chambers are recycled and available for use by the sending process. This is why there's a circular buffer.
48
Sending and receiving buffers contd.. BUFFER AT RECEIVER SIDE: At the receiver the circular buffer is divided into two
areas. The white area contains empty chambers to be filled by
bytes received from the network. The colored section contain received bytes that can be
read by the receiving process. When a byte is read by the receiving process, the
chamber is recycled and added to the pool of empty chambers.
49
Segments At transport layer, TCP groups a number of bytes together into a packet called
segment. TCP adds header to each segment and delivers the segment to the IP layer for
transmission. Encapsulation is performed at the sender side and decapsulation at the
receiver side.
50
Full-duplex communication
TCP offers full duplex service, where data can flow in both directions at the same time.
Each TCP then has a sending and receiving buffer and segments move in both directions.
51
Connection oriented service TCP is connection oriented protocol. When a process at site A wants to send and receive data from
another process at site B, the following occurs:
1. The two TCPs establish a connection between them.
2. Data are exchanged in both the directions.
3. The connection is terminated.
• This is a virtual connection.
• The TCP segment is encapsulated in an IP datagram and can be sent out of order, lost or corrupted, and then resent.
• Each may use different path to reach the destination.
52
Reliable service
TCP is a reliable transport protocol. It uses an acknowledgment mechanism to
check the safe and sound arrival of data.
53
For obtaining the TCP service, it is necessary for both sender and receiver to create sockets
Each socket has a socket address A socket address is made of a port number and IP
address The port number below 1024 are known as well
known port numbers as they are reserved All TCP connections are point to point and full
duplex TCP does not support multicasting and broadcasting
The TCP Service Model
54
The TCP Service ModelSome assigned ports.
Port Protocol Use21 FTP File transfer23 Telnet Remote login25 SMTP E-mail69 TFTP Trivial File Transfer Protocol79 Finger Lookup info about a user80 HTTP World Wide Web
110 POP-3 Remote e-mail access119 NNTP USENET news
55
The TCP Service Model
A TCP connection is byte stream and not message stream
(a) Four 512-byte segments sent as separate IP datagrams.
(b) The 2048 bytes of data delivered to the application in a single READ CALL.
56
PUSH flag and buffering: The message boundaries are not preserved end to end.
When an application passes data to the TCP it may send it immediately or may collect the data for some time and send at once
But if an application wants data to be sent immediately then it can use the PUSH flag which will force the TCP to send data, without any delay
Urgent data: If the sending application puts some control information in
the data stream and gives it to TCP along with URGENT flag then the TCP will stop accumulating the data and transmit everything it has for that connection immediately
When the urgent data reaches the destination, the receiving application is interrupted and the urgent data is presented to it
The TCP Service Model
57
TCP segment header
58
Fields: Source port address: This is a 16-bit field that defines the port
number of the application program in the host that is sending the segment. This serves the same purpose as the source port address in the UDP header.
Destination port address: This is a 16-bit field that defines the port number of the application program in the host that is receiving the segment. This serves the same purpose as the destination port address in the UDP header.
Sequence number: 32-bit field defines the number assigned to the first byte of data contained in this segment. To ensure connectivity, each byte to be transmitted is numbered. The sequence number tells the destination which byte in the sequence comprises the first byte in the segment.
59
Acknowledgement number: 32-bit field defines the byte number that the receiver of the segment is expecting to receive from the other party. If the receiver of the segment has received byte number x from the other party, it defines x+1 as the acknowledged number. Acknowledgment and data can be piggybacked together.
Header length: 4-bit field indicated number of 4-byte words in the TCP header. Header length can be between 20 and 60 bytes. SO, value of this field can be between 5(5*4=20) and 15(15*4=60)
Reserved: 6-bit field reserved for future use. Control: defines 6 different control bits or flags. One or more
of these bits can be set at a time. These bits enable flow control, connection establishment and termination, connection abortion, and mode of data transfer in TCP.
60
Control field
Description of flags in control field
61
Window size: defines the size of the window in bytes, that the other party must maintain. It is 16-bits so maximum size is 65,535 bytes. Referred to as the receiving window (rwnd) and is determined by the receiver.
Checksum: 16-bit field contains the checksum. Inclusion of checksum in TCP is mandatory.
Urgent pointer: 16-bit field which is valid only if the urgent flag is set, is used when the segment contains urgent data. It defines the number added to the sequence number to obtain the number of the last urgent byte in the data section of the segment.
Options: There can be up to 40 bytes of optional information in the TCP header.
62
Pseudoheader added to TCP
63
TCP connection establishment Connection establishment is done by three way
handshake It synchronizes both ends of connection by allowing
both sides to agree upon initial sequence numbers This mechanism also guarantees that both sides are
ready to transmit data and know that the other side is ready to transmit as well
Each host randomly chooses a sequence number used to track bytes within the stream it is sending and receiving
64
To establish a connection, one side say the server passively waits for an incoming connection by executing the LISTEN and ACCEPT primitives either by specifying a particular side or nobody
The other side executes a connect primitive, specifying the IP and port to which it wants to connect, the maximum TCP segment size, possibly some other options and optionally some user data
The CONNECT primitives sends a TCP segment with the SYN bit on and the ACK bit off and waits for a response
TCP connection establishment
65
TCP Connection Establishment
(a) TCP connection establishment in the normal case.(b) Call collision.
6-31
66
Fig a) When the segment sent by host 1 reaches the
destination i.e. host 2 the receiving server checks to see if there is a process that has done a LISTEN on the port given in the destination port field.
If not it sends a reply with the RST bit on to reject the connection
Otherwise it gives the TCP segment to the listening process, which can accept or refuse the connection
On accepting a SYN is send, otherwise a RST A SYN occupies 1 byte of sequence space
TCP connection establishment
67
Call collision: If two hosts try to establish a connection simultaneously between
the same two sockets then the sequence of events is as shown in fig. b
Under such circumstances only one connection is established Both the connections cannot be established because the
connections are identified by their endpoints If the first step results in a connection which is identified by (x, y)
and second connection is also set up then only one table entry will be made i.e. for (x, y)
For the initial sequence number a clock based scheme is used, with a clock pulse coming after every 4 µs
For ensuring additional safety, when host crashes, it may not reboot for 120 sec which is maximum packet lifetime.
This is to make sure that no packets from previous connections are roaming around
TCP connection establishment
68
TCP connection release A TCP is a full duplex connection But we can consider TCP connection to be a pair of simplex
conncetions Each simplex connection is being released independently Releasing a simplex connection is symmetric Either part can send a TCP segment with the FIN bit set,
meaning it has no more data to send When the FIN is acknowledged, that direction is shut down, but
data may continue to flow indefinitely in the other direction If a response to a FIN is not received within 2 maximum packet
lifetimes, the sender of the FIN releases the connection The receiver will eventually notice that it receives no more data
and time-out as well Normally four TCP segments are required to release a
connection i.e. one FIN and one ACK in each direction However the first ACK and second FIN can be combined in the
same segment
69
TCP Connection Management Modeling
The states used in the TCP connection management finite state machine.
70
TCP Connection Management Modeling TCP connection management finite state machine. The heavy solid line is the normal path for a client. The heavy dashed line is the normal path for a server. The light lines are unusual events. Each transition is labeled by the event causing it and the action resulting from it, separated by a slash.
71
From clients point of view: An application on the client machine issues a CONNECT
request, the local TCP entity marks it as SYN SENT state and sends a SYN segment
When the SYN+ACK arrives, the TCP sends the final ACK of the three way handshake and goes into the ESTABLISHED state. It is now possible to send and receive data
When sending data is finished, an application executes a CLOSE primitive. This will cause the local TCP entity to send FIN segment and then wait for ACK
When this ACK is obtained, a transition is made to state FIN WAIT 2 to close the connection in one direction. When the other side also closes, a FIN comes in from that side which is acknowledged. Now both sides are closed
But TCP waits for a time equal to the maximum packet lifetime to ensure that all packets die out. When the timer goes out, TCP deletes the connection record.
TCP Connection Management Modeling
72
Connection management from servers point of view: The server does LISTEN and waits. When a SYN comes
in it is acknowledged and the server enters into SYN REVD state
When the servers SYN is acknowledged, the three way handshake is complete and the server goes to ESTABLISHED state. Data can now be transferred
When the client does a CLOSE this will cause a FIN to arrive at the server . Then the server is also CLOSED, a FIN is sent to the client. After receiving ACK from client, the server releases the connection and deletes the connection record
TCP Connection Management Modeling
73
TCP Transmission Policy
Window management in TCP.
74
Let the receiver has a 4 kbyte i.e. 4096 byte buffer space The sender transmits a 2048 byte segment with a sequence
number SEQ=0 These bytes occupy half space of the receiver’s buffer and the
receiver send back an acknowledgment of this segment (ACK 2048, WIN =2048)
Here WIN= 2048 is the window which advertises an empty buffer space of 2048
Now the sender sends another 2k i.e. 2048 bytes segment which is acknowledged by the receiver (ACK=4096, WIN =0) which shows that window = 0 because the receiver buffer space is 0
The sender must now be blocked until the application process on the receiver removes some data from the buffer
As soon as the application on the receiver side reads 2k bytes, the buffer becomes partially empty and an acknowledgment with a window of 2k (ACK = 4096, WIN =2048) is sent back to sender
TCP Transmission Policy
75
The sender may send upto 2 kbytes When the window= 0, the sender should not
normally send any segment. But under 2 exceptional conditions the sender will continue to send data
1. first urgent data may be send, eg. to allow the user to kill the process running on the other machine
Second, the sender may send a 1 byte segment to make receiver renounce the next byte expected and the window size. This is used to prevent deadlock if a window announcement ever gets lost
TCP Transmission Policy
76
Senders are not supposed to transmit data as soon as it arrives from an application. The receivers also are not supposed to send acknowledgments as soon as possible
This is to reduce the usage of the system. To reduce the system usage, an Nagle’s algorithm is used. It is stated as follows:
When data come into the sender one byte at a time, just the first byte is send and rest is buffered until the outstanding byte is ACKed
Nagle’s algorithm is widely used but sometime it is better not to use it. For example consider an X-windows application being run over the internet
The mouse movements are to be sent to the remote computer If we gather the mouse movements together and send them in
front of a burst then the mouse cursor movements will be eratic. So each mouse movement must be sent separately. This degrades the TCP performance
TCP Transmission Policy
77
TCP Transmission Policy (2)
Silly window syndrome.
78
Problem that can degrade TCP performance Occurs when the sender transmits data in large
blocks, but an interactive application on the receiver side reads data 1 byte at a time
1. Initially the reciever’s buffer is full so it send a window size 0 to block the sender
2. But the interactive application reads one byte from the buffer. So one byte space becomes empty
The receiving TCP sends a window update to the sender informing that it can send 1 byte
The sender send 1 new byte The buffer again is full and the window size is 0.
This behavior can continue forever.
Silly window syndrome
79
Solution to silly window syndrome
Clark suggested the solution to silly window syndrome He suggested that the receiver should not send a
window update for 1 byte Instead it must wait until it has substantial amount of
buffer space available and then send the window update The receiver should not send a window update until it
can handle the maximum window size it has advertised at the time of establishing a connection or its buffer is half empty whichever is smaller
The sender can also help to improve the situation. It should not send tiny segments. Instead it must wait and send a full segment or at least one containing half of the receivers buffer size
80
TCP congestion control Principle of congestion control:
Do not inject a new packet into the network until an old one is delivered
TCP does this by dynamically manipulating the window size 1. prevent the congestion: all TCP algorithms assume that time-
outs are caused by congestion 2. Try to prevent the congestion:
Congestion may take place due to buffer overflow or Even if the buffer capacity is large, it may take place due to
internal carrying capacity of the network Conclusion: To prevent congestion TCP has to deal with two
problems separately – receiver capacity and network capacity So the sender maintains two windows, the window receiver has
granted and the congestion window Each window reflects the number of bytes the sender may
transmit. The number of bytes that the sender may transmit is the minimum of the two windows
81
TCP Congestion Control(a) A fast network feeding a low capacity receiver.(b) A slow network feeding a high-capacity receiver.
82
Slow start algorithm After establishing a connection, the sender initialises the
congestion window to the size if the maximum segment in use on the connection. It then send the maximum segment
If this segment is acknowledged, then it adds bytes corresponding to one full segment to the congestion window
So now the window is 2 maximum size segments. The sender then sends two segments As each of theses segments is acknowledged , the size of
the congestion window is increased by one maximum segment size
When the congestion window is n segments, if all n are ack. before time-out takes place, the congestion window is increased by the byte count corresponding to n segments
83
But there is a limit on exponentially growing congestion window. The congestion window stops growing as soon as either the time out occurs or receivers window size is reached
If the congestion window can grow at 1024 byte, 2048 byte but a burst of 4096 byte gives a time-out then we have to set congestion window at 2048 in order to avoid congestion
Once this is done, no data burst longer than 1024 bytes will be sent by the sender even if receiver grants a wider window
The name of this algorithm is slow algorithm and it is required to be supported by all TCP implementations
Slow start algorithm
84
Internet congestion control algorithm Initially a value called threshold is set to 64 kbyte When the time-out occurs, the threshold is set to
half of the current congestion window and the congestion window is reset to one maximum segment
The slow start algorithm is then used to find what the network can handle
But the exponential growth of the congestion window is stopped as soon as it reaches the threshold
After this point, the congestion window grows linearly by one maximum segment for each burst instead of one per segment
85
TCP Congestion Control
An example of the Internet congestion algorithm.
86
Internet congestion control algorithm The maximum segment size here is 1024 i.e. 1 kbyte. Initial value of congestion window was 64kl but time-out occurs.
So threshold is set to 32 k and congestion window to 1k at 0 Then the congestion window grows exponentially till the
congestion window size reaches the threshold of 32 k The threshold occurs at 32k so the congestion window grows
linearly after 32 k The time-out occurs at the 13th transmission. The threshold is set
to half the current window and slow start is initiated again The process repeats thereafter If no more time-out occurs, the size of congestion window
continues to grow up to the size of the receiver window
87
Timers in TCP
Retransmission timer: the timer is started as soon as a segment is sent. The timer is stopped if the segment ack. is received,
before the timer expires But if the timer expires before the arrival of ack. Then the
segment is retransmitted and the timer is started again
88
Persistence timer: It is designed to solve the following problem:
The receiver sends an ACK with the window size =0, so the sender will wait
After the receiver buffer becomes partially empty it sends a window update to the sender
But the packet containing this window update is lost on its way to sender
So the sender and receiver will waiting forever To solve this problem, the persistence timer is used. If it
goes off, then the sender sends a probe to the receiver The receiver sends the window size in response to this
probe If the window size is still zero then the persistence timer
is et again and the cycle continues. But if the window size is nonzero then sender can send data
Timers in TCP
89
Keepalive timer in timer: This is the third TCP. It is used when a connection is idle
for a long time When connection is idle for a very long time, the Keepalive
timer may go off. This will cause one side to check if the other side is still
there If the other side does not respond, then the connection is
terminated Timer for TIMED WAIT state:
This timer is used in the TIMED WAIT state while closing This timer is set to time equal to twice the maximum packet
lifetime to ensure that after closing a connection all the packets created by it die off
Timers in TCP
90
UDP UDP is connectionless, unreliable transport protocol. Does not add anything to the services of IP except
for providing process-to-process communication instead of host-to-host communication.
Performs little error checking UDP is very simple protocol using a minimum of
overhead. If a process wants to send a small message and
does not care much about reliability, it can use UDP. Sending a small message using UDP takes much
less interaction between the sender and receiver than using TCP.
91
• Allows multiple, application programs on a single machine to communicate concurrently
Message can be delayed, lost, or duplicated Messages can arrive out of order
92
User datagram format
93
Fields In A UDP Message
Source port number : identifies application (process) on original source host
• 16-bits long, range 0 to 65535• If source host is client, the port number is ephemeral port number• If source host is server, the port number is well known port number
Destination port number: identifies application on ultimate destination host
• 16-bits long, range 0 to 65535• If destination host is server, the port number is well known port
number• If destination host is client, the port number is ephemeral port
number. In this case, the server copies the ephemeral port number it has received in the request packet.
94
Fields In A UDP Message
Length: 16-bit field, defines the total length of the user datagram, header plus data.
• Range 0 to 65535 bytes. • But it is much less as user datagram is stored in IP datagram with total
length of 65535 bytes.
Checksum (Optional) : used to detect errors over the entire user datagram• Checksum = UDP Pseudo-Header + data coming from application
layer + 0-padding to multiple of 16 bits– If the field contains zeroes, receiver does not verify the checksum
• Note: IP addresses of source and destination do not appearexplicitly in header
95
96
Pseudoheader for checksum calculation
97
Checksum includes three sections: a pseudoheader, the UDP header, and the data coming from the application layer.
The pseudoheader is the part of the header of the IP packet in which the user datagram is to be encapsulated with some fields filled with 0s.
If the checksum does not include the pseudoheader, a user datagram may arrive safe and sound. But, if the IP header is corrupted it may be delivered to the wrong host.
Protocol field is added to ensure that the packet belongs to UDP and not TCP.
The value of the protocol field for UDP is 17. If this value is changed during transmission, the checksum
calculation at the receiver will detect it and UDP drops the packet. It is not delivered to the wrong host.