The Transport Layer

THE TRANSPORT LAYER

• Transport service
• Elements of transport protocol
• Simple Transport Protocol
• Internet transport layer protocols: UDP and TCP
• Introduction, The TCP service model
• The TCP protocol
• The TCP Segment Header
• TCP connection establishment, connection release
• TCP sliding window
• TCP Timer management
• TCP Congestion control
• Performance issues.
 The Transport Service
• Services Provided to the Upper Layers
• Transport Service Primitives
• Berkeley Sockets
 Services Provided to the Upper Layers
• The ultimate goal of the transport layer is to provide efficient, reliable, and cost-
effective service to its users, normally processes in the application layer.
• To achieve this goal, the transport layer makes use of the services provided by the
network layer.
• The hardware and/or software within the transport layer that does the work is
called the transport entity.
• Transport entity can be located in the operating system kernel, in a separate user
process, in a library package bound into network applications, or conceivably on
the network interface card.
Services Provided to the Upper Layers
 Services Provided to the Upper Layers
• Two types of transport service.
• Connection-oriented transport, connections have three phases: establishment,
data transfer, and release.
• Connectionless network service.
• The transport code runs entirely on the users‘ machines, but the network layer
mostly runs on the routers.
• The bottom four layers can be seen as the transport service provider.
• The upper layer(s) are the transport service user
 Transport service primitives
• Transport service primitives allows transport user like application programs to
access transport service. Difference between network service and transport
service.
• 1. network service is used only by transport layer, while transport service is used
by number of application programs.
• 2. network layer service model services offered by real network, real network
can lost the packet, so network layer services are not 100% reliable.
• Transport layer services are reliable, it provides reliable service using unreliable
network.
 Transport Service Primitives
• The primitives for a simple transport service.
 Transport Service Primitives

• Listen: executed by server. It means server is ready to accept connection. It blocks the
process of server until connection request comes.
• Connect: executed by client to request the connection. It sends connection req.
TPDU(transport protocol data unit) (packet) to server. If server is able to handle
connection then it sends Connection accepted TPDU.
• Send: executed to send data to other end.
• Receive: when ever client or server is waiting for data, It executes Receive primitive. This
is also blocking primitive.
• Disconnect: to disconnect connection.
• Two variants of disconnect. 1. Asymmetric: either side issues disconnect, connection will
be released. 2. Symmetric: both the side need to separately execute disconnect.
 Berkeley Sockets
Socket is used for establishing a TCP Connection
The socket primitives for TCP
 Elements of Transport Protocols

• Addressing
• Connection Establishment
• Connection Release
• Flow Control and Buffering
• Multiplexing
• Crash Recovery
 Addressing
• When an application (e.g., a user) process wishes to set up a connection to a
remote application process, it must specify which one to connect to.
• The method normally used is to define transport addresses to which processes
can listen for connection requests. In the Internet, these end points are called
ports.
• We will use the generic term TSAP, (Transport Service Access Point).The
analogous end points in the network layer (i.e., network layer addresses) are then
called NSAPs. IP addresses are examples of NSAPs
Addressing
 Three-way handshake protocol
• Once both transport entities have agreed on the initial sequence number, any
sliding window protocol can be used for data flow control.
• Three-way handshake protocol is used. This protocol does not require both sides
to begin sending with the same sequence number.
• Host 1 chooses a sequence number, x, and sends a CONNECTION REQUEST TPDU
containing it to host 2.
• Host 2 replies with an ACK TPDU acknowledging x and announcing its own initial
sequence number, y.
• Finally, host 1 acknowledges host 2's choice of an initial sequence number in the
first data TPDU that it sends.
 Connection Establishment
CR denotes CONNECTION REQUEST. (a) Normal operation, (b) Old CONNECTION
REQUEST appearing out of nowhere. (c) Duplicate CONNECTION REQUEST and
duplicate ACK.
 Connection Release

Figure: Four protocol scenarios for releasing a connection. (a) Normal case of a three-way handshake.
(b) final ACK lost.
 Connection Release

Figure : (c) Response lost. (d) Response lost and subsequent DRs lost.
 Flow Control And Buffering

Figure (a) Chained fixed-size buffers. (b) Chained variable-sized buffers. (c) One large circular buffer per
connection
 Multiplexing

• If only one network address is available on a host, all transport connections on

that machine have to use it.
• When a TPDU comes in, some way is needed to tell which process to give it to.
This situation, called upward multiplexing,
• Multiplexing can also be useful in the transport layer for another reason.
Suppose, for example, that a subnet uses virtual circuits internally and imposes a
maximum data rate on each one.
• If a user needs more bandwidth than one virtual circuit can provide, a way out is
to open multiple network connections and distribute the traffic among them on a
round-robin basis, This modus operandi is called downward multiplexing
 Multiplexing

• Figure: (a) Upward multiplexing. (b) Downward multiplexing.

 Crash Recovery

• If hosts and routers are subject to crashes, recovery from these crashes becomes
an issue. If the transport entity is entirely within the hosts, recovery from
network and router crashes is straightforward.
• In an attempt to recover its previous status, the server might send a broadcast
TPDU to all other hosts, announcing that it had just crashed and requesting that
its clients inform it of the status of all open connections.
• Each client can be in one of two states:
• one TPDU outstanding, S1, or
• no TPDUs outstanding, S0.
• Based on only this state information, the client must decide whether to
retransmit the most recent TPDU.
 Crash Recovery
• Consider, for example, the situation in which the server's transport entity
first sends an acknowledgement, and then, when the acknowledgement
has been sent, writes to the application process. Writing a TPDU onto the
output stream and sending an acknowledgement are two distinct events
that cannot be done simultaneously.
• If a crash occurs after the acknowledgement has been sent but before the
write has been done, the client will receive the acknowledgement and
thus be in state S0.
• when the crash recovery announcement arrives. The client will therefore
not retransmit,(incorrectly) thinking that the TPDU has arrived. This
decision by the client leads to a missingTPDU.
 Crash Recovery
• At this point you may be thinking: ''That problem can be solved easily.
All you have to do is reprogram the transport entity to first do the
write and then send the acknowledgement.''
• Try again. Imagine that the write has been done but the crash occurs
before the acknowledgement can be sent. The client will be in state
S1 and thus retransmit, leading to an undetected duplicate TPDU in
the output stream to the server application process.
 A Simple Transport Protocol
• The Example Service Primitives
• Our concrete service definition consists of five primitives: CONNECT, LISTEN,
DISCONECT, SEND, and RECEIVE.
• Each primitive corresponds exactly to a library procedure that executes the primitive.
• The parameters for the service primitives and library procedures are as follows:
• – Connum = LISTEN(local)
• – Connum = CONNECT(local, remote)
• – Status = SEND (connum, buffer, bytes)
• – Status = RECEIVE (connum, buffer, bytes)
• – Status = DISCONNECT (connum)
 The Example Service Primitives

• LISTEN primitive announces the caller’s willingness to accept connection request.

• The CONNECT primitive takes two parameters, a local TSAP and remote TSAP.
• The SEND primitive transmits the contents of the buffer as a message.
• The RECEIVE primitive indicates the caller’s desire to accept data.
• The DISCONNECT primitive terminates a transport connection.
 The Example Transport Entity

Table: The network layer packets used in our example.

 The Example Transport Entity
• Each connection is in one of seven states:
• Idle – Connection not established yet.
• Waiting – CONNECT has been executed, CALL REQUEST sent.
• Queued – A CALL REQUEST has arrived; no LISTEN yet.
• Established – The connection has been established.
• Sending – The user is waiting for permission to send a packet.
• Receiving – A RECEIVE has been done.
• DISCONNECTING – a DISCONNECT has been done locally.
 The Internet Transport Protocols: UDP

• UDP provides a way for applications to send encapsulated IP datagrams and send
them without having to establish a connection.
• UDP transmits segments consisting of an 8-byte header followed by the payload.
• When a UDP packet arrives, its payload is handed to the process attached to the
destination port.
• The source port is primarily needed when a reply must be sent back to the source.
• The UDP length field includes the 8-byte header and the data. The UDP checksum is
optional and stored as 0 if not computed.
• UDP does not do flow control, error control, or retransmission upon receipt of a bad
segment.
• One area where UDP is especially useful is in client-server situations.
The UDP header
 Remote Procedure Call
• When a process on machine 1 calls a procedure on machine 2, the
calling process on 1 is suspended and execution of the called
procedure takes place on 2.
• Information can be transported from the caller to the callee in the
parameters and can come back in the procedure result.
• No message passing is visible to the programmer. This technique is
known as RPC (Remote Procedure Call).
• Traditionally, the calling procedure is known as the client and the
called procedure is known as the server.
 Remote Procedure Call
• Traditionally, the calling procedure is known as the client and the called
procedure is known as the server.
• The idea behind RPC is to make a remote procedure call look as much as
possible like a local one.
• In the simplest form, to call a remote procedure,
• The client program must be bound with a small library procedure, called the
client stub, that represents the server procedure in the client's address space.
• Similarly, the server is bound with a procedure called the server stub. These
procedures hide the fact that the procedure call from the client to the server
is not local.
 Remote Procedure Call
• The actual steps in making an RPC are :
• Step 1 is the client calling the client stub. This call is a local procedure call, with
the parameters pushed onto the stack in the normal way.
• Step 2 is the client stub packing the parameters into a message and making a
system call to send the message. Packing the parameters is called marshaling.
• Step 3 is the kernel sending the message from the client machine to the server
machine.
• Step 4 is the kernel passing the incoming packet to the server stub. Finally,
• Step 5 is the server stub calling the server procedure with the unmarshaled
parameters. The reply traces the same path in the other direction.
Remote Procedure Call
 The Real-Time Transport Protocol

• Having a generic real-time transport protocol for multiple applications would be a

good idea.
• Thus was RTP (Real-time Transport Protocol) born.
• The position of RTP in the protocol stack is somewhat strange.
• It operates as follows:
• The multimedia application consists of multiple audio, video, text, and possibly
other streams.
• These are fed into the RTP library, which is in user space along with the application.
• This library then multiplexes the streams and encodes them in RTP packets, which it
then stuffs into a socket.
 The Real-Time Transport Protocol

• At the other end of the socket (in the operating system kernel), UDP packets are
generated and embedded in IP packets. If the computer is on an Ethernet, the IP
packets are then put in Ethernet frames for transmission.
• Figure: (a)The position of RTP in the protocol stack. (b) Packet nesting
 The Real-Time Transport Protocol

• It is a little hard to say which layer RTP is in. Since it runs in user space and is linked to
the application program,
• It certainly looks like an application protocol.
• On the other hand, it is a generic, application-independent protocol that just provides
transport facilities,
• so it also looks like a transport protocol.
• Probably the best description is that it is a transport protocol that is implemented in the
application layer.
• The basic function of RTP is to multiplex several real-time data streams onto a single
stream of UDP packets.
• The UDP stream can be sent to a single destination (unicasting) or to multiple
destinations (multicasting).
 The Real-Time Transport Protocol
• Each packet sent in an RTP stream is given a number one higher than its
predecessor. This numbering allows the destination to determine if any packets
are missing.
• If a packet is missing, the best action for the destination to take is to approximate
the missing value by interpolation.
• Retransmission is not a practical option since the retransmitted packet would
probably arrive too late to be useful.
• As a consequence, RTP has no flow control, no error control, no
acknowledgements, and no mechanism to request retransmissions
The RTP header
 The RTP header
• The RTP header consists of three 32-bit words and potentially some extensions.
• The first word contains the Version field, which is already at 2.
• The P bit indicates that the packet has been padded to a multiple of 4 bytes. The last
padding byte tells how many bytes were added.
• The X bit indicates that an extension header is present, the first word of the extension
gives the length.
• The CC field tells how many contributing sources are present, from 0 to 15.
• The M bit is an application-specific marker bit. It can be used to mark the start of a video
frame, the start of a word in an audio channel, or something else that the application
understands.
• The Payload type field tells which encoding algorithm has been used (e.g.,
uncompressed 8-bit audio, MP3, etc.).
 The RTP header
• The Sequence number is just a counter that is incremented on each RTP packet sent. It is
used to detect lost packets.
• The timestamp is produced by the stream's source to note when the first sample in the
packet was made. This value can help reduce jitter at the receiver by decoupling the
playback from the packet arrival time.
• The Synchronization source identifier tells which stream the packet belongs to. It is the
method used to multiplex and demultiplex multiple data streams onto a single stream of
UDP packets.
• Finally, the Contributing source identifiers, if any, are used when mixers are present in the
studio.
• RTP has a little sister protocol (little sibling protocol?) called RTCP (Realtime Transport
Control Protocol). It handles feedback, synchronization, and the user interface but does not
transport any data.
 Introduction to TCP
• TCP (Transmission Control Protocol) was specifically designed to
provide a reliable end-to-end byte stream over an unreliable
internetwork.
• An internetwork differs from a single network because different parts
may have wildly different topologies, bandwidths, delays, packet sizes,
and other parameters.
• The IP layer gives no guarantee that datagrams will be delivered
properly, so it is up to TCP to time out and retransmit them as need
be.
• Datagrams that do arrive may well do so in the wrong order; it is also
up to TCP to reassemble them into messages in the proper sequence.
• In short, TCP must furnish the reliability that most users want and that
IP does not provide.
 The TCP Service Model
• TCP service is obtained by both the sender and receiver creating end
points, called sockets.
• Each socket has a socket number (address) consisting of the IP address
of the host and a 16-bit number local to that host, called a port.
• A port is the TCP name for a TSAP.
• For TCP service to be obtained, a connection must be explicitly
established between a socket on the sending machine and a socket on
the receiving machine.
• Port numbers below 1024 are called well-known ports and are
reserved for standard services.
• For example, any process wishing to establish a connection to a host
to transfer a file using FTP can connect to the destination host's port
21 to contact its FTP daemon.
The TCP Service Model

Port Protocol Use

21 FTP File transfer
23 Telnet Remote login
25 SMTP E-mail
69 TFTP Trivial File Transfer Protocol
79 Finger Lookup info about a user
80 HTTP World Wide Web
110 POP-3 Remote e-mail access
119 NNTP USENET news
 The TCP Service Model
• All TCP connections are full duplex and point-to-point.
• Full duplex means that traffic can go in both directions at the same
time.
• Point-to-point means that each connection has exactly two end points.
• TCP does not support multicasting or broadcasting.
• A TCP connection is a byte stream, not a message stream.
• Message boundaries are not preserved end to end.
• For example, if the sending process does four 512-byte writes to a TCP
stream, these data may be delivered to the receiving process as four
512-byte chunks, two 1024-byte chunks, one 2048-byte chunk or
some other way.
 The TCP Service Model

(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.
 The TCP Protocol
• A key feature of TCP, and one which dominates the protocol design, is
that every byte on a TCP connection has its own 32-bit sequence
number.
• The sending and receiving TCP entities exchange data in the form of
segments.
• A TCP segment consists of a fixed 20-byte header (plus an optional
part) followed by zero or more data bytes.
• Two limits restrict the segment size.
• First, each segment, including the TCP header, must fit in the
65,515-byte IP payload.
• Second, each network has a maximum transfer unit, or MTU, and
each segment must fit in the MTU.
• The basic protocol used by TCP entities is the sliding window protocol.
The TCP Segment Header

TCP Header.
 The TCP Segment Header
• Every segment begins with a fixed-format, 20-byte header. The fixed
header may be followed by header options.
• After the options, if any, up to 65,535 - 20 - 20 = 65,495 data bytes
may follow, where the first 20 refer to the IP header and the second to
the TCP header.
• Segments without any data are legal and are commonly used for
acknowledgements and control messages.
• The Source port and Destination port fields identify the local end
points of the connection.
• The source and destination end points together identify the
connection.
• A port plus its host's IP address forms a 48-bit unique end point.
 The TCP Segment Header

• The Sequence number and Acknowledgement number fields perform

their usual functions.
• Both are 32 bits long because every byte of data is numbered in a TCP
stream.
• The TCP header length tells how many 32-bit words are contained in
the TCP header. Technically, this field really indicates the start of the
data within the segment, measured in 32-bit words.
• Next comes a 6-bit field that is not used.
• Now come six 1-bit flags.
• URG is set to 1 if the Urgent pointer is in use. The Urgent pointer is
used to indicate a byte offset from the current sequence number at
which urgent data are to be found.
 The TCP Segment Header

• The ACK bit is set to 1 to indicate that the Acknowledgement number

is valid. If ACK is 0, the segment does not contain an
acknowledgement so the Acknowledgement number field is ignored.
• The PSH bit indicates PUSHed data. The receiver is hereby kindly
requested to deliver the data to the application upon arrival and not
buffer it until a full buffer has been received (which it might otherwise
do for efficiency).
• The RST bit is used to reset a connection that has become confused
due to a host crash or some other reason. It is also used to reject an
invalid segment or refuse an attempt to open a connection. In general,
if you get a segment with the RST bit on, you have a problem on your
hands.
• The SYN bit is used to establish connections.
• The FIN bit is used to release a connection.
 The TCP Segment Header

• Flow control in TCP is handled using a variable-sized sliding window.

• The Window size field tells how many bytes may be sent starting at the
byte acknowledged.
• A Window size field of 0 is also legal.
• A Checksum is also provided for extra reliability. It checksums the
header, the data, and the conceptual pseudoheader .
• When performing this computation, the TCP Checksum field is set to
zero .
• The checksum algorithm is simply to add up all the 16-bit words in
one's complement and then to take the one's complement of the sum.
• As a consequence, when the receiver performs the calculation on the
entire segment, including the Checksum field, the result should be 0.
• The Options field provides a way to add extra facilities not covered by
the regular header.
 TCP Connection Establishment

• Connections are established in TCP by means of the three-way

handshake.
• To establish a connection, one side, say, the server, passively waits by
executing the LISTEN and ACCEPT primitives, either specifying a specific
source or nobody in particular.
• The other side, say, the client, executes a CONNECT primitive, specifying
the IP address and port to which it wants to connect.
• The CONNECT primitive sends a TCP segment with the SYN bit on and
ACK bit off and waits for a response.
• At the destination, the TCP entity 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.
• If some process is listening to the port, that process is given the
incoming TCP segment. It can then either accept or reject the
connection. If it accepts, an acknowledgement segment is sent back.
 TCP Connection Establishment

6-31

(a) TCP connection establishment in the normal case.

(b) Call collision.
 TCP Connection Release

• TCP connections are full duplex, think of them as a pair of simplex

connections.
• Each simplex connection is released independently of its sibling.
• To release a connection, either party can send a TCP segment with the
FIN bit set, which means that it has no more data to transmit.
• When the FIN is acknowledged, that direction is shut down.
• Data may continue to flow indefinitely in the other direction.
• When both directions have been shut down, the connection is
released.
• Normally, four TCP segments are needed to release a connection, one
FIN and one ACK for each direction.
• However, it is possible for the first ACK and the second FIN to be
contained in the same segment, reducing the total count to three.
• To avoid the two-army problem, timers are used.
 TCP Transmission Policy
• window management in TCP is not directly tied to acknowledgements as it is in most
data link protocols.
• suppose the receiver has a 4096-byte buffer.
• If the sender transmits a 2048-byte segment that is correctly received, the receiver will
acknowledge the segment.
• However, since it now has only 2048 bytes of buffer space (until the application removes
some data from the buffer), it will advertise a window of 2048 starting at the next byte
expected.
• Now the sender transmits another 2048 bytes, which are acknowledged, but the
advertised window is 0.
• The sender must stop until the application process on the receiving host has removed
some data from the buffer, at which time TCP can advertise a larger window.
TCP Transmission Policy

Window management in TCP.

 TCP Transmission Policy
• When the window is 0, the sender may not normally send segments, with two
exceptions.
• First, urgent data may be sent, for example, to allow the user to kill the process
running on the remote machine.
• Second, the sender may send a 1-byte segment to make the receiver re-announce the
next byte expected and window size.
• The TCP standard explicitly provides this option to prevent deadlock if a window
announcement ever gets lost.
• A problem that can degrade TCP performance is the silly window syndrome (Clark,
1982).
• This problem occurs when data are passed to the sending TCP entity in large blocks,
but an interactive application on the receiving side reads data 1 byte at a time.
 TCP Transmission Policy

Silly window syndrome.

 TCP Transmission Policy
Silly window syndrome
This problem occurs when data are passed to the sending TCP entity in large blocks,
but an interactive application on the receiving side reads data 1 byte at a time.
• Nagle Solution: when data come into the sender one byte at a time, just send the
first byte and buffer all the rest until the outstanding byte is acknowledged.
• Clark Solution :Specifically, the receiver should not send a window update until it
can handle the maximum segment size it advertised when the connection was
established or until its buffer is half empty, which ever is smaller.
 TCP Congestion Control
(a) A fast network feeding a low capacity receiver.
(b) A slow network feeding a high-capacity receiver.
 TCP Congestion Control

• An example of the Internet congestion algorithm.