Transport Layer

Differences between the Data Link Layer and Transport Layer

✍ In data link layer, each outgoing line uniquely specifies a particular router. However,
in the transport layer, explicit addressing of destinations is required.
✍ The process of establishing a connection over a wire is simple. However, in transport
layer, initial connection establishment is more complicated.
✍ The existence of storage capacity in the subnet. In data link layer, the frame may
arrive or be lost, but it cannot bounce around for a while. However, in transport
layer, there is a no negligible probability that a packet may be stored for a number of
seconds and then delivered later.
✍ Buffering and flow control are needed in both layers, but in the transport layer may
require a different approach than we used in the data link layer.
ELEMENTS OF TRANSPORT PROTOCOLS

Environment of the (a) data link layer (b) transport layer

The relationship of network, transport, and application layers
Largest kernel subsystem is a network stack
Difference between networking programming and
socket programming
 Services provided to the upper layers
The transport service is similar to the network service, but there are also some
important differences.
First Difference: Network service is intended to model the service offered by real
networks-lose Packets.
Transport Service: Reliable service on top of an unreliable network
Second difference: network service is used only by the transport entities.
Transport Service Primitives
Addressing
TSAPs, NSAPs, and Transport connections
 A possible scenario for a transport connection is as follows:

✔ A mail server process attaches itself to TSAP 1522 on host 2 to wait for an incoming call. A call such as our LISTEN might be used, for
example.

✔ An application process on host 1 wants to send an email message, so it attaches itself to TSAP 1208 and issues a CONNECT request.
✔ The request specifies TSAP 1208 on host 1 as the source and TSAP 1522 on host 2 as the destination. This action ultimately
results in a transport connection being established between the application process and the server.

✔ The application process sends over the mail message.

✔ The mail server responds to say that it will deliver the message.

✔ The transport connection is released

 Connection Establishment
❖ Network uses datagrams inside and that every packet follows a different route.
❖ Stuck in a traffic jam, may be delayed
❖ User establishes a connection with a bank, sends messages telling the bank to transfer
a large amount of money to the account of a not-entirely-trustworthy person
❖ Initial batch of packets finally come out of hiding and arrive at the destination
❖ It must assume that this is a second, independent transaction, and transfers the money
again.
 Contd..
The crux of the problem is that the delayed duplicates are thought to
be new packets
☺ One way is to use throwaway transport addresses
☺ Another possibility is to give each connection a unique identifier
☺ After each connection is released, each transport entity can update a table listing
obsolete connections
☸ Flaw: it requires each transport entity to maintain a certain amount of history
information indefinitely
 Contd..
❖ Packet lifetime can be restricted to a known maximum using one (or more)
of the following techniques:
✔ Restricted network design.
✔ Putting a hop counter in each packet.
✔ Timestamping each packet.
Connection Establishment
 Connection Establishment (4)

Three protocol scenarios for establishing a connection using a

three-way handshake. CR denotes CONNECTION REQUEST. Old duplicate CONNECTION REQUEST
appearing out of nowhere.
 Connection Establishment (5)

Three protocol scenarios for establishing a connection using a

three-way handshake. CR denotes CONNECTION REQUEST. Duplicate CONNECTION REQUEST and duplicate
ACK
Connection Release (1)

Abrupt disconnection with loss of data

Connection Release (2)
The two-army problem
 Connection Release (3)

Four protocol scenarios for releasing a connection.

(a) Normal case of three-way handshake
 Connection Release (4)

Four protocol scenarios for releasing a connection.

(b) Final ACK lost.
 Connection Release (5)

Four protocol scenarios for releasing a connection.

(c) Response lost
 Connection Release (6)

Four protocol scenarios for releasing a connection.

(d) Response lost and subsequent DRs lost.
 Error Control and Flow Control
Source buffering and destination buffering depends on the type of traffic.
✍ For low-bandwidth bursty traffic, it is reasonable not to dedicate any buffers,
but rather to acquire them dynamically at both ends.
✍ high-bandwidth traffic, it is better if the receiver does dedicate a full window
of buffers, to allow the data to flow at maximum speed.
☸ This is the strategy that TCP uses.
Error Control and Flow Control (1)

(a) Chained fixed-size buffers. (b) Chained variable-sized buffers. (c) One
large circular buffer per connection.
Error Control and Flow Control (2)

Dynamic buffer allocation. The arrows show the direction of

transmission. An ellipsis (...) indicates a lost TPDU
The Internet Transport Protocols: TCP (2)
• TCP connection management modeling
• TCP sliding window
• TCP timer management
• TCP congestion control
• TCP futures
The TCP Segment Header

The TCP header.

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.

This connection identifier is called a 5 tuple because it consists of five

pieces of information: the protocol (TCP), source IP and source port, and
destination IP and destination port.

The Sequence number and Acknowledgement number fields perform their

usual functions.
The Sequence number and Acknowledgement number fields perform
their usual functions.
The TCP header length tells how many 32-bit words are contained in
the TCP header.

This information is needed because the Options field is of variable

length, so the header is, too. Now come eight 1-bit flags.
CWR and ECE are used to signal congestion when ECN (Explicit
Congestion Notification) is used.

CWR is set to signal Congestion Window Reduced from the TCP

sender to the TCP receiver so that it knows the sender has slowed
down and can stop sending the ECN-Echo.

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.
 TCP Connection Establishment

(a) TCP connection establishment in the normal case.

(b) Simultaneous connection establishment on both sides.
MAXIMUM SEGMENT SIZE (MSS)

Note –
Thus, Maximum Segment Size refers to highest
payload size, an end device is ready to accept
within single packet. The maximum Transmission
Unit is highest size of packet that can flow through
network without being divided.
 Specifying the Window Scale Factor

• Enter 0 (zero) or a positive value only if you want to enable window scaling.
• A scale factor of –1 means no scaling is performed
• To calculate the true window size, multiply the window size by 2^S where S
is the scale value.
• The TCP header uses a 16-bit window field to report the size of the receive
window to the sender. Therefore, the largest window that can be used is 216
or 65,535 bytes, and the largest amount of data that can be sent or received is
limited to 65,535 bytes.
It tells the computer to use a window size of 26752 from now on. The computer sends 18 segments with
1460 bytes and one segment of 472 bytes (26752 bytes in total). The last packet shows us “TCP Window
Full” message. This is something that wireshark reports to us, our computer has completely filled the
receive buffer
To calculate the true window size, multiply the window size by 2^S where S is
the scale value.
TABLE 1

Scale Factor Scale Value Initial Window Window Scaled

0 1 65535 or less 65535 or less
1 2 65535 131,070
2 4 65535 262,140
3 8 65535 524,280
4 16 65535 1,048,560
5 32 65535 2,097,120
6 64 65535 4,194,240
7 128 65535 8,388,480
8 256 65535 16,776,960
9 512 65535 33,553,920
10 1024 65535 67,107,840
11 2048 65535 134,215,680
12 4096 65535 268,431,360
13 8192 65535 536,862,720
14 16384 65535 1,073,725,440
Example:
If the window size is 65,535 bytes with a window scale factor of 3.
True window size = 65535*2^3
True window size = 524280
TCP Sliding Window (1)

Window management in TCP

• for example using SSH or telnet, that reacts on every keystroke.
• TCP creates a 21-byte TCP segment, which it gives to IP to send as a 41-byte IP datagram.
• receiving side, TCP immediately sends a 40-byte acknowledgement (20 bytes of TCP
header and 20 bytes of IP header).
• TCP sends a window update, moving the window 1 byte to the right. This packet is also 40
bytes.
• When the remote terminal has processed the character, it echoes the character for local
display using a 41-byte packet.
• Totally 162bytes
 Silly Window Syndrome
• Silly Window Syndrome is a problem that arises due to poor implementation
of TCP. It degrades the TCP performance and makes the data transmission
extremely inefficient.
The problem is called so because:

It causes the sender window size to shrink to a silly value.

The window size shrinks to such an extent that the data being transmitted is smaller
than TCP Header.
TCP Sliding Window (2)

Silly window syndrome

 The two major causes of this syndrome are as
follows

• Sender window transmitting one byte of data repeatedly.

• Receiver window accepting one byte of data repeatedly.

 How to solve the problem?
☺ Delayed Acknowledgements
☺ Nagle’s algorithm: when data come into the sender in small pieces, just send the
first piece and buffer all the rest until the first piece is acknowledged.
☺ send all the buffered data in one TCP segment and start buffering again until the
next segment is acknowledged.
☺ Nagle’s algorithm is widely used by TCP implementations, but there are times when
it is better to disable it.
☺ Interactive games
 Clark’s solution suggests

✔ Receiver should not send a window update for 1 byte.

✔ Receiver should wait until it has a decent amount of space available.

✔ Receiver should then advertise that window size to the sender.

Introduction to UDP (1)

The UDP header.

• UDP transmits segments consisting of an 8-byte header
• The two ports serve to identify the endpoints within the source and destination
machines
• UDP length field includes the 8-byte header and the data.(minimum length is 8
bytes, maximum length is 65,515 bytes)
• The checksum algorithm is simply to add up all the 16-bit words in one’s
complement and to take the one’s complement of the sum.
 Introduction to UDP (2)

The IPv4 pseudoheader included in the UDP checksum.

UDP prepends the pseudo header to
UDP datagram, and computes the
checksum for pseudo header, UDP
header and data.
The checksum value is then
inserted to the Checksum field of
UDP header. Pseudo header is used
only for calculating the checksum
value.
It is not a part of actual UDP packet
and it is never sent over network
 What is RPC?
Call a procedure (function, subroutine, method, …)
in a program
running on a remote machine,

while hiding communication details from the programmer.

Note: Think C, not java! We deal with objects later!

58
 Standards for RPC
RFC 1057: Remote Procedure Call
RFC 1014: External Data Representation
Author: Sun Microsystems Inc.

Others: see Comer.

Sun RPC Demo with the rpcgen tool:

• [Link]
ens/[Link]
• 20 Oct 2002 archived copy

59
 Conventional Procedure Call

a) Parameter passing in a local procedure call: the stack before the call to read
b) The stack while the called procedure is active
TvS 2.7 60
 Complications for Remote Calls
How to make it look like a function call, but actually use a
client and server?

Answer: use ‘stubs’ (‘proxies’)

How to handle parameters and return values?

Platform differences (e.g. endian issues)
Pass-by-reference

Answer: use ‘external data representation’

61
 Timing (Synchronous RPC)
RPC between a client and server program.

TvS 2.8 62
 Steps of a Remote Procedure Call
1. Client procedure calls client stub in normal way

2. Client stub builds message, calls local OS

3. Client's OS sends message to remote OS

4. Remote OS gives message to server stub

5. Server stub unpacks parameters, calls server

6. Server does work, returns result to the stub

7. Server stub packs it in message, calls local OS

8. Server's OS sends message to client's OS

9. Client's OS gives message to client stub

63
TvS 2.9

10. Stub unpacks result, returns to client

 RPC steps
• 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.

• Step 4 is the operating system 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.
65
 Passing Value Parameters
Steps involved in doing remote computation through RPC

2-8

TvS 2.10 66
 Problems
✍ A big one is the use of pointer parameters. With RPC, passing pointers is
impossible because the client and server are in different address spaces.
✍ A second problem is that in weakly typed languages, like C, it is perfectly
legal to write a procedure that computes the inner product of two vectors
(arrays), without specifying how large either one is. Each could be terminated
by a special value known only to the calling and called procedures. Under
these circumstances, it is essentially impossible for the client stub to marshal
the parameters: it has no way of determining how large they are.
67
 Cont..
✍ A third problem is that it is not always possible to deduce the types of the
parameters, not even from a formal specification or the code itself. An
example is printf, which may have any number of parameters (at least one),
and the parameters can be an arbitrary mixture of integers, shorts, longs,
characters, strings, floating- point numbers of various lengths, and other
types. Trying to call printf as a remote procedure would be practically
impossible because C is so permissive. However, a rule saying that RPC can
be used provided that you do not program in C (or C++) would not be
popular with a lot of programmers.

68
 Cont..
• A fourth problem relates to the use of global variables. Normally, the calling
and called procedure can communicate by using global variables, in addition
to communicating via parameters. But if the called procedure is moved to a
remote machine, the code will fail because the global variables are no longer
shared.

69