1

UNIT – 6
TRANSPORT LAYER

The Internet Transport Protocols

The Internet has two main protocols in the transport layer, a connectionless protocol
and a connection- oriented one. The protocols complement each other. The connectionless
protocol is UDP. It does almost nothing beyond sending packets between applications, letting
applications build their own protocols on top as needed.

The connection-oriented protocol is TCP. It does almost everything. It makes

connections and adds reliability with retransmissions, along with flow control and congestion
control, all on behalf of the applications that use it. Since UDP is a transport layer protocol that
typically runs in the operating system and protocols that use UDP typically run in user s pace,
these uses might be considered applications.

UDP
INTROUCTION TO UDP
 The Internet protocol suite supports a connectionless transport protocol called UDP
(User Datagram Protocol). UDP provides a way for applications to send encapsulated IP
datagrams without having to establish a connection.

 UDP transmits segments consisting of an 8-byte header followed by the pay-load. The
two ports serve to identify the end-points within the source and destination machines.

 When a UDP packet arrives, its payload is handed to the process attached to the
destination port. This attachment occurs when the BIND primitive. Without the port
fields, the transport layer would not know what to do with each incoming packet. With
them, it delivers the embedded segment to the correct application.

Fig 4.9: The UDP header

Source port, destination port: Identifies the end points within the source and destination
machines.

UDP length: Includes 8-byte header and the data

UDP checksum: Includes the UDP header, the UDP data padded out to an even number of
bytes if need be. It is an optional field
 2

REMOTE PROCEDURE CALL

 In a certain sense, sending a message to a remote host and getting a reply back is like
making a function call in a programming language. This is to arrange request-reply
interactions on networks to be cast in the form of procedure calls.

 For example, just imagine a procedure named get IP address (host name) that works
by sending a UDP packet to a DNS server and waiting or the reply, timing out and
trying again if one is not forthcoming quickly enough. In this way, all the details of
networking can be hidden from the programmer.

 RPC is used to call remote programs using the procedural 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 application
programmer. This technique is known as RPC (Remote Procedure Call) and has
become the basis for many networking applications.
Traditionally, the calling procedure is known as the client and the called procedure is
known as the server.
 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.

Fig 4.10: Steps in making a RPC

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 operating system sending the message from the client machine to the server
machine.
 3

Step 4 is the operating system passing the incoming packet to the server stub.
Step 5 is the server stub calling the server procedure with the unmarshaled parameters. The
reply traces the same path in the other direction.

The key item to note here is that the client procedure, written by the user, just makes a
normal (i.e., local) procedure call to the client stub, which has the same name as the server
procedure. Since the client procedure and client stub are in the same address space, the
parameters are passed in the usual way.

Similarly, the server procedure is called by a procedure in its address space with the
parameters it expects. To the server procedure, nothing is unusual. In this way, instead of I/O
being done on sockets, network communication is done by faking a normal procedure call.
With RPC, passing pointers is impossible because the client and server are in different address
spaces.

UDP Applications

 UDP does not provide error control; it provides an unreliable service. Most
applications expect reliable service from a transport-layer protocol. Although a
reliable service is desirable.

 UDP is suitable for a process that requires simple request-response communication with
little concern for flow and error control

 UDP is suitable for a process with internal flow- and error-control mechanisms.
For example, the Trivial File Transfer Protocol (TFIP)

 UDP is a suitable transport protocol for multicasting. Multicasting capability is

embedded in the UDP software

 UDP is used for management processes such as SNMP

 UDP is used for some route updating protocols such as Routing Information Protocol
(RIP)

 UDP is normally used for interactive real-time applications that cannot tolerate
uneven delay between sections of a received message
 4

TCP
It was specifically designed to provide a reliable end-to end byte stream over an
unreliable network. It was designed to adapt dynamically to properties of the inter network and
to be robust in the face of many kinds of failures.
Each machine supporting TCP has a TCP transport entity, which accepts user data
streams from local processes, breaks them up into pieces not exceeding 64kbytes and sends
each piece as a separate IP datagram. When these datagrams arrive at a machine, they are
given to TCP entity, which reconstructs the original byte streams. It is up to TCP to time out
and retransmits them as needed, also to reassemble datagrams into messages in proper
sequence.
The different issues to be considered are:

1. The TCP Service Model

2. The TCP Protocol
3. The TCP Segment Header
4. The Connection Management
5. TCP Transmission Policy
6. TCP Congestion Control
7. TCP Timer Management.

The TCP Service Model

 TCP service is obtained by having both the sender and receiver create end points called
SOCKETS
 Each socket has a socket number(address)consisting of the IP address of the host,
called a “PORT” ( = TSAP )
 To obtain TCP service a connection must be explicitly established between a socket on
the sending machine and a socket on the receiving machine
 All TCP connections are full duplex and point to point i.e., multicasting or
broadcasting is not supported.
 A TCP connection is a byte stream, not a message stream i.e., the data is delivered as
chunks

E.g.: 4 * 512 bytes of data is to be transmitted.

 5

Sockets:
A socket may be used for multiple connections at the same time. In other words, 2 or
more connections may terminate at same socket. Connections are identified by socket
identifiers at same socket. Connections are identified by socket identifiers at both ends. Some
of the sockets are listed below:

Ports: Port numbers below 256 are called Well- known ports and are reserved for standard
services.
Eg:
PORT-21 To establish a connection to a host to transfer a file using FTP

PORT-23 To establish a remote login session using TELNET

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.
 When the Internet began, the lines between routers were mostly 56-kbps leased lines,
so a host blasting away at full speed took over 1 week to cycle through the sequence
numbers.
 The basic protocol used by TCP entities is the sliding window protocol.
 When a sender transmits a segment, it also starts a timer.
 When the segment arrives at the destination, the receiving TCP entity sends back a
segment (with data if any exist, otherwise without data) bearing an acknowledgement
number equal to the next sequence number it expects to receive.
 If the sender's timer goes off before the acknowledgement is received, the sender
transmits the segment again.

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.
 6

Fig 4.11: The TCP Header

Source Port, Destination Port : Identify local end points
of the connections Sequence number: Specifies the
sequence number of the segment Acknowledgement
Number: Specifies the next byte expected.

TCP header length: Tells how many 32-bit words are contained in
TCP header URG: It is set to 1 if URGENT pointer is in use, which
indicates start of urgent data. ACK: It is set to 1 to indicate that the
acknowledgement number is valid.
PSH: Indicates pushed data
RST: It is used to reset a connection that has become confused due to reject an invalid
segment or refuse an attempt to open a connection.

FIN: Used to release a connection.

SYN: Used to establish connections.

TCP Connection Establishment

To establish a connection, one side, say, the server, passively waits for an incoming
connection 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 maximum TCP segment size it is willing to
accept, and optionally some user data (e.g., a password).
The CONNECT primitive sends a TCP segment with the SYN bit on and ACK bit off
and waits for a response.
 7

Fig 4.12: a) TCP Connection establishment in the normal case b) Call

Collision

TCP Connection Release

 Although TCP connections are full duplex, to understand how connections are released
it is best to 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 for new data. Data may
continue to flow indefinitely in the other direction, however.
 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.
TCP Connection Management Modeling
The steps required establishing and release connections can be represented in a finite state
machine with the 11 states listed in Fig. 4.13. In each state, certain events are legal. When a
legal event happens, some action may be taken. If some other event happens, an error is
reported.

Figure 4.13. The states used in the TCP connection management finite state
machine.
 8

Figure 4.14 - TCP connection management finite state machine.

TCP Connection management from server’s point of view:

1. The server does a LISTEN and settles down to see who turns up.
2. When a SYN comes in, the server acknowledges it and goes to the SYNRCVD state
3. When the servers SYN is itself acknowledged the 3-way handshake is complete and
server goes to the ESTABLISHED state. Data transfer can now occur.
4. When the client has had enough, it does a close, which causes a FIN to arrive at the
server [dashed box marked passive close].
5. The server is then signaled.
6. When it too, does a CLOSE, a FIN is sent to the client.
7. When the client’s acknowledgement shows up, the server releases the connection
and deletes the connection record.
 9

TCP Transmission Policy

1. In the above example, the receiver has 4096-byte buffer.

2. If the sender transmits a 2048-byte segment that is correctly received, the receiver will
acknowledge the segment.
3. Now the receiver will advertise a window of 2048 as it has only 2048 of buffer space, now.
4. Now the sender transmits another 2048 bytes which are acknowledged, but the advertised
window is’0’.
5. 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 layer window.

SILLY WINDOW SYNDROME:

This is one of the problems that ruin the TCP performance, which occurs when data are
passed to the sending TCP entity in large blocks, but an interactive application on the receiving
side reads 1 byte at a time.
 Initially the TCP buffer on the receiving side is full and the sender knows this(win=0)
 Then the interactive application reads 1 character from tcp stream.
 Now, the receiving TCP sends a window update to the sender saying that it is all right to
send 1 byte.
 The sender obligates and sends 1 byte.
 The buffer is now full, and so the receiver acknowledges the 1 byte segment but sets
window to zero. This behavior can go on forever.
 10

TCP CONGESTION CONTROL:

TCP does to try to prevent the congestion from occurring in the first place in the
following way:

When a connection is established, a suitable window size is chosen and the receiver
specifies a window based on its buffer size. If the sender sticks to this window size, problems
will not occur due to buffer overflow at the receiving end. But they may still occur due to
internal congestion within the network. Let’s see this problem occurs.

Figure 4.16. (a) A fast network feeding a low-capacity receiver. (b) A slow network
feeding a high-capacity receiver.
In fig (a): We see a thick pipe leading to a small- capacity receiver. As long as the sender does
not send more water than the bucket can contain, no water will be lost.
In fig (b): The limiting factor is not the bucket capacity, but the internal carrying capacity of
the n/w. if too much water comes in too fast, it will backup and some will be lost.
 When a connection is established, the sender initializes the congestion window to the
size of the max segment in use our connection.
 It then sends one max segment .if this max segment is acknowledged before the timer
 11

goes off, it adds one segment s worth of bytes to the congestion window to make it two
maximum size segments and sends 2 segments.
 As each of these segments is acknowledged, the congestion window is increased by
one max segment size.
 When the congestion window is ‘n’ segments, if all ‘n’ are acknowledged on time, the
congestion window is increased by the byte count corresponding to ‘n’ segments.
 The congestion window keeps growing exponentially until either a time out occurs or
the receiver’s window is reached.
 The internet congestion control algorithm uses a third parameter, the “threshold” in
addition to receiver and congestion windows.

Different congestion control algorithms used by TCP are:

 RTT variance Estimation.
 Exponential RTO back-off Re-transmission Timer Management
 Karn’s Algorithm
 Slow Start
 Dynamic window sizing on congestion
 Fast Retransmit Window Management
 Fast Recovery

TCP TIMER MANAGEMENT:

TCP uses 3 kinds of timers:

1. Retransmission timer
2. Persistence timer
3. Keep-Alive timer.

1. Retransmission timer: When a segment is sent, a timer is started. If the segment is

acknowledged before the timer expires, the timer is stopped. If on the other hand, the timer
goes off before the acknowledgement comes in, the segment is retransmitted and the timer is
started again. The algorithm that constantly adjusts the time-out interval, based on continuous
measurements of n/w performance was proposed by JACOBSON and works as follows:
 for each connection, TCP maintains a variable RTT, that is the best current estimate of
the round trip time to the destination inn question.
 When a segment is sent, a timer is started, both to see how long the acknowledgement
takes and to trigger a retransmission if it takes too long.
 If the acknowledgement gets back before the timer expires, TCP measures how long
the measurements took say M
 It then updates RTT according to the formula
 12

RTT = αRTT + ( 1-α ) M

Where α = a smoothing factor that determines how much
weight is given to the old value. Typically, α =7/8

Retransmission timeout is calculated as

D = α D + ( 1-α ) | RTT-M |
Where D = another smoothed variable, Mean RTT = expected
acknowledgement value M = observed acknowledgement value

Timeout = RTT+(4*D)

2. Persistence timer:
It is designed to prevent the following deadlock:
 The receiver sends an acknowledgement with a window size of ‘0’ telling the sender to
wait later, the receiver updates the window, but the packet with the update is lost now
both the sender and receiver are waiting for each other to do something
 when the persistence timer goes off, the sender transmits a probe to the receiver the
response to the probe gives the window size
 if it is still zero, the persistence timer is set again and the cycle repeats
 if it is non zero, data can now be sent

3. Keep-Alive timer: When a connection has been idle for a long time, this timer may go off
to cause one side to check if other side is still there. If it fails to respond, the connection is
terminated.
 13

APPLICATION LAYER
DOMAIN NAME SYSTEM

This is primarily used for mapping host and e-mail destinations to IP addresses but
can also be used other purposes. DNS is defined in RFCs 1034 and 1035.

Working:-
 To map a name onto an IP address, an application program calls a library procedure
called Resolver, passing it the name as a parameter.
 The resolver sends a UDP packet to a local DNS server, which then looks up the
name and returns the IP address to the resolver, which then returns it to the caller.
 Armed with the IP address, the program can then establish a TCP connection with
the destination, or send it UDP packets.

1. The DNS name space.

2. Resource Records.
3. Name Servers.

1. THE DNS NAME SPACE:

The Internet is divided into several hundred top level domains, where each domain
covers many hosts. Each domain is partitioned into sub domains, and these are further
partitioned as so on. All these domains can be represented by a tree, in which the leaves
represent domains that have no sub domains. A leaf domain may contain a single host, or it
may represent a company and contains thousands of hosts. Each domain is named by the
path upward from it to the root. The components are separated by periods (pronounced
“dot”)
Eg: Sun Microsystems Engg. Department = eng.sun.com.

The top domain comes in 2 flavours:-

 Generic: com(commercial), edu(educational instructions), mil(the U.S armed
forces, government), int (certain international organizations), net( network
providers), org (non profit organizations).
 Country: include 1 entry for every country. Domain names can be either absolute (ends
with a period
e.g. eng.sum.com) or relative (doesn’t end with a period). Domain names are case
sensitive and the component names can be up to 63 characters long and full path
names must not exceed 255 characters.
 14

Figure 5-1. A portion of the Internet domain name space.

Insertions of a domain into the tree can be done in 2 days:-

 Under a generic domain ( Eg: cs.yale.edu)
 Under the domain of their country (E.g: cs.yale.ct.us)

2. RESOURCE RECORDS:
Every domain can have a sent of resource records associated with it. For a single host,
the most common resource record is just its IP address. When a resolver gives a domain
name to DNS, it gets both the resource records associated with that name i.e., the real
function of DNS is to map domain names into resource records. A resource record is a 5-
tuple and its format is as follows:

Domain Name Time to live Type Class Value

Domain _name : Tells the domain to which this record applies.

Time- to- live : Gives an identification of how stable the record is (High Stable = 86400 i.e. no.
of seconds
/day) ( High Volatile = 1 min)
Type: Tells what kind of record this is.
Class: It is IN for the internet information and codes for non internet information
Value: This field can be a number a domain name or an ASCII string
 15

3. NAME SERVERS:
It contains the entire database and responds to all queries about it. DNS name space is
divided up into non- overlapping zones, in which each zone contains some part of the tree
and also contains name servers holding the authoritative information about that zone.

Figure 5-2. Part of the DNS name space showing the division into zones.

When a resolver has a query about a domain name, it passes the query to one of the local name
servers:
1. If the domain being sought falls under the jurisdiction of name server, it returns the
authoritative resource records (that comes from the authority that manages the record,
and is always correct).
2. If the domain is remote and no information about the requested domain is available
locally the name server sends a query message to the top level name server for the
domain requested.
E.g.: A resolver of flits.cs.vle.nl wants to know the IP address of the host Linda.cs.yale.edu

Figure 5-3. How a resolver looks up a remote name in eight steps.

Step 1: Resolver sends a query containing domain name sought the type and the class to
local name server, cs.vu.nl.
Step 2: Suppose local name server knows nothing about it, it asks few others nearby name
servers. If none of them know, it sends a UDP packet to the server for edu-
server.net.
Step 3: This server knows nothing about Linda.cs.yale.edu or cs.yale.edu and so it
forwards the request to the name server for yale.edu.
Step 4: This one forwards the request to cs.yale.edu which must have authoritative resource
records.
Step 5 to 8: The resource record requested works its way back in steps 5-8 This query method
is known as Recursive Query
 16

3. When a query cannot be satisfied locally, the query fails but the name of the next
server along the line to try is returned.

ELECTRONIC MAIL

1. ARCHITECTURE AND SERVICES:

E-mail systems consist of two subsystems. They are:-
(1). User Agents, which allow people to read and send e-mail
(2). Message Transfer Agents, which move messages from
source to destination E-mail systems support 5 basic functions:-
a. Composition
b. Transfer
c. Reporting
d. Displaying
e. Disposition

(a). Composition: It refers to the process of creating messages and answers. Any text
editor is used for body of the message. While the system itself can provide assistance
with addressing and numerous header fields attached to each message.
(b). Reporting: It has to do with telling the originator what happened to the message that
is, whether it was delivered, rejected (or) lost.
(c). Transfer: It refers to moving messages from originator to the recipient.
(d). Displaying: Incoming messages are to be displayed so that people can read their email.
(e). Disposition: It concerns what the recipient dose with the message after receiving it.
Possibilities include throwing it away before reading (or) after reading, saving it and so
on.
Most systems allow users to create mailboxes to store incoming e-mail. Commands are
needed to create and destroy mailboxes, inspect the contents of mailboxes, insert and delete
messages from mailboxes, and so on.
 17

Figure 5-4: Envelopes and messages. (a) Paper mail. (b) Electronic mail.

(1) THE USER AGENT

A user agent is normally a program (sometimes called a mail reader) that accepts a
variety of commands for composing, receiving, and replying to messages, as well as for
manipulating mailboxes.

SENDING E-MAIL

To send an e-mail message, a user must provide the message, the destination address,
and possibly some other parameters. The message can be produced with a free-standing
text editor, a word processing program, or possibly with a specialized text editor built into
the user agent. The destination address must be in a format that the user agent can deal
with. Many user agents expect addresses of the form user@dns-address.

READING E-MAIL

When a user agent is started up, it looks at the user's mailbox for incoming e-mail
before displaying anything on the screen. Then it may announce the number of messages in
the mailbox or display a one-line summary of each one and wait for a command.
 18

(2) MESSAGE FORMATS

RFC 822

Messages consist of a primitive envelope (described in RFC 821), some number of header
fields, a blank line, and then the message body. Each header field (logically) consists of a
single line of ASCII text containing the field name, a colon, and, for most fields, a value.

Figure 5-5: RFC 822 header fields related to message transport

MIME — The Multipurpose Internet Mail Extensions

RFC 822 specified the headers but left the content entirely up to the users. Nowadays, on
the worldwide Internet, this approach is no longer adequate. The problems include sending
and receiving
1. Messages in languages with accents (e.g., French and German).
2. Messages in non-Latin alphabets (e.g., Hebrew and Russian).
3. Messages in languages without alphabets (e.g., Chinese and Japanese).
4. Messages not containing text at all (e.g., audio or images).
A solution was proposed in RFC 1341 called MIME (Multipurpose Internet Mail Extensions)

The basic idea of MIME is to continue to use the RFC 822 format, but to add
structure to the message body and define encoding rules for non-ASCII messages. By not
deviating from RFC 822, MIME messages can be sent using the existing mail programs
and protocols. All that has to be changed are the sending and receiving programs, which
users can do for themselves.
 19

Figure 5-6: RFC 822 headers added by MIME

MESSAGE TRANSFER

The message transfer system is concerned with relaying messages from the
originator to the recipient. The simplest way to do this is to establish a transport connection
from the source machine to the destination machine and then just transfer the message.

SMTP—THE SIMPLE MAIL TRANSFER PROTOCOL

SMTP is a simple ASCII protocol. After establishing the TCP connection to port
25, the sending machine, operating as the client, waits for the receiving machine, operating
as the server, to talk first. The server starts by sending a line of text giving its identity and
telling whether it is prepared to receive mail. If it is not, the client releases the connection
and tries again later.
Even though the SMTP protocol is completely well defined, a few problems can still
arise.

One problem relates to message length. Some older implementations cannot

handle messages exceeding 64 KB.

Another problem relates to timeouts. If the client and server have different
timeouts, one of them may give up while the other is still busy, unexpectedly
terminating the connection.

Finally, in rare situations, infinite mailstorms can be triggered.

For example, if host 1 holds mailing list A and host 2 holds mailing list B and each
list contains an entry for the other one, then a message sent to either list could generate a
never-ending amount of e-mail traffic unless somebody checks for it.
 20

FINAL DELIVERY

With the advent of people who access the Internet by calling their ISP over a modem, it breaks
down.

One solution is to have a message transfer agent on an ISP machine accept e-mail for its
customers and store it in their mailboxes on an ISP machine. Since this agent can be on-line
all the time, e-mail can be sent to it 24 hours a day.

POP3

Figure:5-7

(a) Sending and reading mail when the receiver has a permanent Internet
connection and the user agent runs on the same machine as
the message transfer agent.

(b) Reading e-mail when the receiver has a dial-up connection to an ISP

POP3 begins when the user starts the mail reader. The mail reader calls up the ISP (unless
there is already a connection) and establishes a TCP connection with the message transfer
agent at port 110. Once the connection has been established, the POP3 protocol goes
through three states in sequence:
1. Authorization.
2. Transactions.
3. Update.
 21

The authorization state deals with having the user log in.

The transaction state deals with the user collecting the e-mails and marking them for

deletion from the mailbox. The update state actually causes the e-mails to be deleted.

IMAP (Internet Message Access Protocol).

POP3 normally downloads all stored messages at each contact, the result is that the user's
e-mail quickly gets spread over multiple machines, more or less at random; some of them
not even the user's.

This disadvantage gave rise to an alternative final delivery protocol, IMAP (Internet
Message Access Protocol).

IMAP assumes that all the e-mail will remain on the server indefinitely in multiple
mailboxes. IMAP provides extensive mechanisms for reading messages or even parts of
messages, a feature useful when using a slow modem to read the text part of a multipart
message with large audio and video attachments.