Computer Networks: A Systems Approach, 5e

Larry L. Peterson and Bruce S. Davie

Chapter 5
End-to-End Protocols

Copyright 2010, Elsevier Inc. All rights Reserved

Chapter 5

Problem

How to turn this host-to-host packet delivery

service into a process-to-process communication
channel

Chapter 5

Chapter Outline
Simple Demultiplexer (UDP)
Reliable Byte Stream (TCP)

Chapter 5

Chapter Goal
Understanding the demultipexing service
Discussing simple byte stream protocol

Chapter 5

End-to-end Protocols

Common properties that a transport protocol can

be expected to provide

Guarantees message delivery

Delivers messages in the same order they were sent
Delivers at most one copy of each message
Supports arbitrarily large messages
Supports synchronization between the sender and the
receiver
Allows the receiver to apply flow control to the sender
Supports multiple application processes on each host

Chapter 5

End-to-end Protocols
Typical limitations of the network on which
transport protocol will operate

Drop messages
Reorder messages
Deliver duplicate copies of a given message
Limit messages to some finite size
Deliver messages after an arbitrarily long delay

Chapter 5

End-to-end Protocols

Challenge for Transport Protocols

Develop algorithms that turn the less-than-desirable

properties of the underlying network into the high level
of service required by application programs

Chapter 5

Simple Demultiplexer (UDP)

Extends host-to-host delivery service of the
underlying network into a process-to-process
communication service
Adds a level of demultiplexing which allows
multiple application processes on each host to
share the network

Chapter 5

Simple Demultiplexer (UDP)

Format for UDP header (Note: length and checksum fields

should be switched)

Chapter 5

Simple Demultiplexer (UDP)

UDP Message Queue

10

Chapter 5

Reliable Byte Stream (TCP)

In contrast to UDP, Transmission Control
Protocol (TCP) offers the following services

Reliable
Connection oriented
Byte-stream service

11

Chapter 5

Flow control VS Congestion control

Flow control involves preventing senders from

overrunning the capacity of the receivers
Congestion control involves preventing too much
data from being injected into the network,
thereby causing switches or links to become
overloaded

12

Chapter 5

End-to-end Issues

At the heart of TCP is the sliding window

algorithm (discussed in Chapter 2)
As TCP runs over the Internet rather than a
point-to-point link, the following issues need to
be addressed by the sliding window algorithm

TCP supports logical connections between processes

that are running on two different computers in the
Internet
TCP connections are likely to have widely different
RTT times
Packets may get reordered in the Internet
13

Chapter 5

End-to-end Issues
TCP needs a mechanism using which each side of a
connection will learn what resources the other side is
able to apply to the connection
TCP needs a mechanism using which the sending
side will learn the capacity of the network

14

TCP is a byte-oriented protocol, which means

that the sender writes bytes into a TCP
connection and the receiver reads bytes out of
the TCP connection.

Although byte stream describes the service

TCP offers to application processes, TCP does
not, itself, transmit individual bytes over the
Internet.

Chapter 5

TCP Segment

15

Chapter 5

TCP Segment

TCP on the source host buffers enough bytes

from the sending process to fill a reasonably
sized packet and then sends this packet to its
peer on the destination host.
TCP on the destination host then empties the
contents of the packet into a receive buffer, and
the receiving process reads from this buffer at its
leisure.
The packets exchanged between TCP peers are
called segments.

16

Chapter 5

TCP Segment

How TCP manages a byte stream.

17

Chapter 5

TCP Header

TCP Header Format

18

Chapter 5

TCP Header

The SrcPort and DstPort fields identify the source and

destination ports, respectively.
The Acknowledgment, SequenceNum, and
AdvertisedWindow fields are all involved in TCPs sliding
window algorithm.
Because TCP is a byte-oriented protocol, each byte of
data has a sequence number; the SequenceNum field
contains the sequence number for the first byte of data
carried in that segment.
The Acknowledgment and AdvertisedWindow fields carry
information about the flow of data going in the other
direction.
19

Chapter 5

TCP Header

The 6-bit Flags field is used to relay control information

between TCP peers.
The possible flags include SYN, FIN, RESET, PUSH,
URG, and ACK.
The SYN and FIN flags are used when establishing and
terminating a TCP connection, respectively.
The ACK flag is set any time the Acknowledgment field is
valid, implying that the receiver should pay attention to it.

20

Chapter 5

TCP Header

The URG flag signifies that this segment contains urgent

data. When this flag is set, the UrgPtr field indicates
where the nonurgent data contained in this segment
begins.
The urgent data is contained at the front of the segment
body, up to and including a value of UrgPtr bytes into the
segment.
The PUSH flag signifies that the sender invoked the push
operation, which indicates to the receiving side of TCP
that it should notify the receiving process of this fact.
Finally, the RESET flag signifies that the receiver has
become confused
21

Chapter 5

TCP Header

Finally, the RESET flag signifies that the receiver has

become confused, it received a segment it did not expect
to receiveand so wants to abort the connection.
Finally, the Checksum field is used in exactly the same
way as for UDPit is computed over the TCP header,
the TCP data, and the pseudoheader, which is made up
of the source address, destination address, and length
fields from the IP header.

22

Chapter 5

Connection Establishment/Termination in TCP

Timeline for three-way handshake algorithm

23

Chapter 5

Sliding Window Revisited

TCPs variant of the sliding window algorithm, which
serves several purposes:

(1) it guarantees the reliable delivery of data,

(2) it ensures that data is delivered in order, and
(3) it enforces flow control between the sender and the receiver.

24

Chapter 5

Sliding Window Revisited

Relationship between TCP send buffer (a) and receive buffer (b).

25

Sending Side

Chapter 5

TCP Sliding Window

LastByteAcked LastByteSent
LastByteSent LastByteWritten

Receiving Side

LastByteRead < NextByteExpected

NextByteExpected LastByteRcvd + 1

26

Chapter 5

TCP Flow Control

LastByteRcvd LastByteRead MaxRcvBuffer

AdvertisedWindow = MaxRcvBuffer
((NextByteExpected 1) LastByteRead)
LastByteSent LastByteAcked AdvertisedWindow
EffectiveWindow = AdvertisedWindow (LastByteSent
LastByteAcked)
LastByteWritten LastByteAcked MaxSendBuffer
If the sending process tries to write y bytes to TCP, but
(LastByteWritten LastByteAcked) + y > MaxSendBuffer
then TCP blocks the sending process and does not allow
it to generate more data.

27

SequenceNum: 32 bits longs

AdvertisedWindow: 16 bits long

TCP has satisfied the requirement of the sliding

window algorithm that is the sequence number

space be twice as big as the window size

232 >> 2 216

Chapter 5

Protecting against Wraparound

28

Chapter 5

Protecting against Wraparound

Relevance of the 32-bit sequence number space

The sequence number used on a given connection might

wraparound

A byte with sequence number x could be sent at one time, and

then at a later time a second byte with the same sequence
number x could be sent

Packets cannot survive in the Internet for longer than the MSL

MSL is set to 120 sec

We need to make sure that the sequence number does not wrap
around within a 120-second period of time

Depends on how fast data can be transmitted over the Internet

29

Chapter 5

Protecting against Wraparound

Time until 32-bit sequence number space wraps around.

30

16-bit AdvertisedWindow field must be big enough to

allow the sender to keep the pipe full

Clearly the receiver is free not to open the window as

large as the AdvertisedWindow field allows

If the receiver has enough buffer space

The window needs to be opened far enough to allow a full

delay bandwidth products worth of data

Assuming an RTT of 100 ms

Chapter 5

Keeping the Pipe Full

31

Chapter 5

Keeping the Pipe Full

Required window size for 100-ms RTT.

32

Chapter 5

Triggering Transmission
How does TCP decide to transmit a segment?

TCP supports a byte stream abstraction

Application programs write bytes into streams
It is up to TCP to decide that it has enough bytes to send a
segment

33

Chapter 5

Triggering Transmission
What factors governs this decision

Ignore flow control: window is wide open, as would be the case

when the connection starts
TCP has three mechanism to trigger the transmission of a
segment

1) TCP maintains a variable MSS and sends a segment as soon as

it has collected MSS bytes from the sending process

2) Sending process has explicitly asked TCP to send it

MSS is usually set to the size of the largest segment TCP can send without
causing local IP to fragment.
MSS: MTU of directly connected network (TCP header + and IP header)
TCP supports push operation

3) When a timer fires

Resulting segment contains as many bytes as are currently buffered for

transmission

34

Chapter 5

Silly Window Syndrome

If you think of a TCP stream as a conveyer belt with full

containers (data segments) going in one direction and
empty containers (ACKs) going in the reverse direction,
then MSS-sized segments correspond to large
containers and 1-byte segments correspond to very
small containers.
If the sender aggressively fills an empty container as
soon as it arrives, then any small container introduced
into the system remains in the system indefinitely.
That is, it is immediately filled and emptied at each end,
and never coalesced with adjacent containers to create
larger containers.

35

Chapter 5

Silly Window Syndrome

Silly Window Syndrome

36

Chapter 5

Nagles Algorithm
If there is data to send but the window is open less than
MSS, then we may want to wait some amount of time
before sending the available data
But how long?
If we wait too long, then we hurt interactive applications
like Telnet
If we dont wait long enough, then we risk sending a
bunch of tiny packets and falling into the silly window
syndrome

The solution is to introduce a timer and to transmit when the

timer expires

37

Chapter 5

Nagles Algorithm
We could use a clock-based timer, for example one that
fires every 100 ms
Nagle introduced an elegant self-clocking solution
Key Idea

As long as TCP has any data in flight, the sender will eventually
receive an ACK
This ACK can be treated like a timer firing, triggering the
transmission of more data

38

Chapter 5

Nagles Algorithm
When the application produces data to send
if both the available data and the window MSS
send a full segment
else
if there is unACKed data in flight
buffer the new data until an ACK arrives
else
send all the new data now

39

Chapter 5

Adaptive Retransmission
Original Algorithm
Measure SampleRTT for each segment/ ACK
pair
Compute weighted average of RTT

EstRTT = x EstRTT + (1 - )x SampleRTT

between 0.8 and 0.9

Set timeout based on EstRTT

TimeOut = 2 x EstRTT

40

Chapter 5

Original Algorithm

Problem

ACK does not really acknowledge a

transmission

It actually acknowledges the receipt of data

When a segment is retransmitted and then an

ACK arrives at the sender

It is impossible to decide if this ACK should be

associated with the first or the second transmission
for calculating RTTs

41

Chapter 5

Karn/Partridge Algorithm

Associating the ACK with (a) original transmission versus (b) retransmission

42

Chapter 5

Karn/Partridge Algorithm
Do not sample RTT when retransmitting
Double timeout after each retransmission

43

Karn-Partridge algorithm was an improvement over the original approach, but it does not
eliminate congestion

We need to understand how timeout is related to congestion

Chapter 5

Karn/Partridge Algorithm

If you timeout too soon, you may unnecessarily retransmit a segment which adds load to the network

44

Chapter 5

Karn/Partridge Algorithm
Main problem with the original computation is that it does not take variance of Sample
RTTs into consideration.
If the variance among Sample RTTs is small

Then the Estimated RTT can be better trusted

There is no need to multiply this by 2 to compute the timeout

45

Chapter 5

Karn/Partridge Algorithm
On the other hand, a large variance in the samples suggest that
timeout value should not be tightly coupled to the Estimated RTT
Jacobson/Karels proposed a new scheme for TCP retransmission

46

Chapter 5

Jacobson/Karels Algorithm
Difference = SampleRTT EstimatedRTT
EstimatedRTT = EstimatedRTT + ( Difference)
Deviation = Deviation + (|Difference| Deviation)
TimeOut = EstimatedRTT + Deviation

where based on experience, is typically set to 1 and is set to 4. Thus, when the variance is small, TimeOut is close to
EstimatedRTT; a large variance causes the deviation term to dominate the calculation.

47

We have discussed how to convert host-to-host packet delivery

service to process-to-process communication channel.

We have discussed UDP
We have discussed TCP

Chapter 5

Summary

48