MK-Review of TCP-IP Protocol Suite

8/9/2019 MK-Review of TCP-IP Protocol Suite

1/41

TECHNISCHEUNIVERSITTILMENAU

I n t e g r a

t e d H a r d - a n

d S o

f t w a r e

S y s

t e m s

h t t p : / / w w w

. t u - i

l m e n a u

. d e / i h s

Review ofInternet Protocol SuiteInternet Protocol Suite

Link Layer: Ethernet, PPP, ARP, MAC AddressingNetwork Layer: IP, ICMP, RoutingTransport Layer: TCP, UDP, Port Numbers, SocketsApplication Layer: FTP, Telnet & Rlogin, HTTP, RTP

TCP

Basic PropertiesTCP Datagram Format

Connection Setup and ReleaseMTU and MSSCumulative, Delayed and Duplicate AcknowledgementsSliding Window Mechanism

Flow and Error Control


2/41

Wireless Internet 2 Andreas Mitschele-Thiel 6-Apr-06

Internet Protocol Suite

TCP/IP = the Internet protocol suite = a family of protocols for the InternetInternet guesstimates 2003:

800 million users (x 2 each two years), 200 million permanent hostsStandardisation:

ISOC: Internet SocietyIAB: Internet Architecture Board

IETF : Internet Engineering Task Force:http://www.ietf.orgStandards & other informations are published as RFCs: Requests for

CommentsIRTF: Internet Research Task ForceImplementations:

De-facto standard: BSD 4.x implementations (Berkeley Software Distribution)

Subsequent versions come with new TCP features, e.g.4.3 BSD Tahoe (1988): slow start, congestion avoidance, fast retransmit4.3 BSD Reno (1990): fast recovery

Other TCP/IP stacks derived from BSDImplemented mechanisms, default parameter settings, and bugs aredifferent on different operating systems (e.g. versions of MS Windows)!


3/41


TCP/IP Layer Overview

Protocol ExamplesTasksTCP/IP Layers(OSI model*)

PPP, Ethernet, IEEE 802.x,ARP

Hardware interfacePacket transfer be-tween network nodes

Link(2)

IP, ICMPRouting of packetsbetween hostsNetwork

(3)

TCP, UDPEnd-to-end flow of databetween applicationprocesses

Transport(4)

Telnet, rlogin, FTP, SMTP,

SNMP, ...Application specificApplication

(7)

* Mapping between TCP/IP and OSI layers is not always exact.


4/41


TCP/IP Encapsulation

user data

user dataappl.

header

Application

ethheader

IPheader application data

TCPheader

ethtrailer

Ethernet

Driver

14 20 20 4Ethernet frame

Ethernet: 46...1500 bytes

application dataTCPheader

TCP

TCP segment

20

IPheader application data

TCPheader

IP

IP datagram20...65536 bytes

20

Example:Application datatransfer using TCP


5/41


Application Layer

Transport Layer

... Network Layer

... Link Layer

TCP/IP Basics: Link Layer

UserProcess

UserProcess

UserProcess

UserProcess

TCP UDP

IPICMP

HardwareInterfaceARP


6/41


Link Layer Protocols

Examples:Ethernet (encapsulation of higher layer packets is defined in RFC 894)PPP : Point-to-Point Protocol for serial lines (RFCs 1332, 1548)

MTU: Maximum Transfer Unit (or Max. Transmission Unit)

Maximum IP packet size in bytes (e.g. for Ethernet: 1500, X.25 FrameRelay: 576)Path MTU:

Smallest MTU of any data link in the path between two hosts

Used to avoid IP fragmentationTCP option: path MTU discovery (RFC 1191)

Loopback Interface:A client application can connect to the corresponding server applicationon the same host by using the loopback IP address localhost = 127.0.0.1Implemented at the link layer, i.e. full processing of transport and IP layers

ARP : Address Resolution Protocol (RFC 826)Address resolution from 32-bit IP addresses to hardware addresses (e.g.

48-bit)

modemMTU=576

ethMTU=1500

Path MTU=576


7/41


Application Layer

Transport Layer

... Network Layer

... Link Layer

TCP/IP Basics: Network Layer

UserProcess

UserProcess

UserProcess

UserProcess

TCP UDP

IPICMP



8/41


IP: Internet Protocol

IP providesrouting (forwarding) between hosts:Based on 32-bit IP addresses *Hop-by-hop using routing tables

Unreliable, connectionless datagram delivery service:packet loss, out-of-order delivery, duplication

IP fragmentation: used on any link with MTU < original datagram length:Duplicates IP header for each fragment and sets flags for re-assemblyRe-assembly at the receiving host only, never in the network

RFC 791

* Applications use the Domain Name Service (DNS ) to convert hostnames(e.g. www.lucent.com) into IP addresses (135.112.22.95) and vice-versa.IPv6 uses 128-bit addresses


9/41


QoSrequirements;

rarely usedand supported

IP Datagram Format

4-bitversion 8-bit type of service

16-bit identification

data

20 bytes

4-bit head-er length 16-bit total length (in bytes)

3-bitflags 13-bit fragment offset

8-bit time to live 8-bit protocol 16-bit IP header checksum

32-bit source IP address

32-bit destination IP address

options (if any)

IP datagramlength in bytes(limit = 65536)

- (reserved)- dont fragment- more fragments

Uniqueidentifier(counter)

Limit on the

number ofrouters(countdown)

Higher layeridentifier,

e.g.:ICMP=1TCP=6

UDP=17

Realfragmentoffset / 8IPv4

Numberof 32-bitwords

16-bit ones complement sum ofthe IP header only

checksum error =>discard datagram + try to sendICMP message


10/41


ICMP: Internet Control Message Protocol

ICMP packet consists of IP header + ICMP messageUsed for queries and to communicate error messages back to the sender,

e.g.:IP header badecho request (or reply)host unreachableMobile IP messages

Messages are used by higher layers, e.g.:ping, traceroute, TCP, ... HTTP

RFC 792


11/41


Application Layer

Transport Layer

... Network Layer

... Link Layer

TCP/IP Basics: Transport Layer

UserProcess

UserProcess

UserProcess

UserProcess

TCP UDP

IPICMP



12/41


UDP vs. TCP

UDP : User Datagram Protocol (RFC 768)Simple, unreliable, datagram-oriented transport of application datablocks

TCP : Transmission Control Protocol (RFC 793 + others)Connection-oriented, reliable byte stream serviceDetails: see section on TCP

Port numbers are used for application multiplexing:Unique address = IP address + port number = socket Concept of well-known ports, e.g. TCP port 21 for FTP (RFC 1340)

Popular API for TCP and UDP connections:Socket APIStream sockets use TCPDatagram sockets use UDP


13/41


UDP Datagram Format

16-bit source port number 16-bit destination port number

16-bit UDP length 16-bit UDP checksum

data (if any)

8 bytes

Optional 16-bit ones complementsum of UDP pseudo-header (12 bytesof the IP header ) + UDP header +data (padded to 16-bit multiple)

checksum error =>discard datagram silently

UDP datagramlength in bytes

(redundant)

Used forapplicationmultiplexing

Used forapplicationmultiplexing


14/41


ApplicationLayer

Transport Layer

... Network Layer

... Link Layer

TCP/IP Basics: Selected Applications

UserProcess

UserProcess

UserProcess

UserProcess

TCP UDP

IPICMP



15/41


FTP: File Transfer Protocol

File transfer based on TCPTCP control connection:

To well-known server port 21ASCII commands

TCP data connectionQoS requirements:

High throughput (optimise TCP bulk data flow)RFC 959


16/41


Telnet and Rlogin

Used for remote login based onTCPRlogin (RFC 1282):

Simple protocol designed for UNIX hostsTelnet (RFC 854):

Any OSOption negotiationMore flexible and better performance

Client operation principle:

Send each keystroke to the serverOption: TCPs Nagle algorithm groups multiple bytes into one segmentDisplay every response from the server

QoS requirements:

Low-RTT transport of small packets (optimise TCP interactive data flow)

RTT = round-trip-time (sender receiver sender)


17/41


HTTP: Hypertext Transfer ProtocolTransfer of webpages based on TCP :

Webpage typically consists of an HTML (Hyper Text Markup Language)document + various embedded objects, e.g. pictures

HTTP/1.0:Objects are (requested and received) seriallyFor each object, a new TCP connection is established, used andreleasedMultiple connections : several TCP connections can be used in parallel

HTTP/1.1: performance improvements by:Persistent Connections :

TCP connections are not released after each object, but used for thenext one

avoids TCP connection establishment and termination avoids slow start for each new connection

Pipelining :Multiple objects can be requested in one packetRequested objects are sent sequentially over one TCP connection

Together with multiple connections (HTTP/1.0 feature), these options result insignificant performance improvements


18/41


RTP: Real-time Transport Protocol

Transfer of real-time data based onUDPRTP:

for media with real-time characteristics (audio/video )services: payload type specification, sequence numbering,timestamping ,source identification & synchronization, delivery monitoringno guaranteed quality of service (QoS)

RTCP (Real-time Transport Control Protocol):

QoS monitoring & periodic feedback:Sender report (synchronisation, expected rates, distance)Receiver report (loss ratios, jitter)

Network independent: on top ofunreliable, low-delay transport service

RFC 1889ITU-T H.225.0 Annex A => H.323 => e.g. MS Netmeeting, VoIP


19/41


Summary: Internet Protocol Suite

The TCP/IP protocol suite is aheterogenous family of protocolsfor the global Internet

At the center and always used:IPRouting between hosts

Application data transport byUDP : unreliable datagram serviceTCP : reliable byte-stream service

TCP/IP stack is part of each operating system:Numerous different implementations and bugs exist

TCP performance is extremely important!

TCP carries 62% of the flows, 85% of the packets,and 96% of the bytes of Internet traffic(http://www.cs.columbia.edu/~hgs/internet/traffic.html)TCPs complex error control mechanisms aredesigned for wired networks

=> special problems for wireless transport


20/41


TCP (Transmission Control Protocol)

PropertiesConnection-oriented, reliable byte-stream service:Reliability by ARQ (Automatic Repeat reQuest):

TCP receiver sends acknowledgements (acks) back to TCP sender to confirmdelivery of received dataCumulative, positive acks for all contiguously received dataTimeout-based retransmission of segments

TCP transfers a byte stream:Segmentation into TCP segments, based on MTUHeader contains byte sequence numbers

Congestion avoidance + flow control mechanism

In the following examples: Packet sequence numbers (instead of byte sequence numbers)ack i acknowledges receipt of packets through packet i (instead of bytes)


21/41


TCP Segment Format

6 bits reserved

16-bit source port number

data (if any)

20 bytes

4-bit head-er length 16-bit window size

16-bit TCP checksum

32-bit sequence number

options (if any)

16-bit destination port number

32-bit acknowledgment number

6-bit flags

16-bit urgent pointer

16-bit ones complement sum of TCP

pseudo-header (12 bytes of the IPheader) + TCP header + data(padded to 16-bit multiple)

checksum error=> discard datagramsilently!=> using an erroneous header isdangerous; loss will be detected byother mechanisms

Identifies thenumber of thefirst data bytein this segmentwithin the bytestream

Ack for thereverse link:next sequencenumber that isexpected to bereceived

Number of 32-bit words

URGACKPSHRSTSYNFIN

Advertisedwindowsize:number ofbytes thereceiver iswilling to

acceptTCP is full duplex:Each segment contains an ack for thereverse link

A pure ack is a segment with empty data


22/41


TCP Connection Establishment and Termination

Client Server

Segment 3: ACK

Three-way handshake

*ISN: initial sequence number(RFC 793)

Segment 1:SYN + ISN* +options, e.g. MSS

Active open:

Segment 2:SYN, ACK + ISN +options, e.g. MSS

Passive open:

Application close =>Segment 1: FIN

Active close:Passive close:

=> Send EOF toapplication

Segment 2: ACK ;application can still send data

Half-close #1

Application close =>Segment 3: FINSegment 4: ACK

Half-close #2

=> Connection establishment & termination take at least 1 RTT


23/41


MTU and MSS: Maximum Segment Size

Client Server Application

TCP

IP

Link Layer

Request to connect to Server

SYN, MSS=536TCP Connectionestablishment

MSS is optionally announced(not negotiated) by each host at TCP connectionestablishment. The smaller value is used by both ends, i.e. 536 in the above example.

Note that real TCP payload is smaller if TCP options are used.

MSS = 536

- Fixed TCP header = 20

- Fixed IP header = 20

MTU = 576 (e.g. modem)

MSS = 1460

- Fixed TCP header = 20

- Fixed IP header = 20

MTU = 1500 (e.g. ethernet)

SYN, ACK, MSS=1460

findnetworkinterface


24/41


Cumulative Acknowledgements

A new cumulative ack is generated only on receipt of anew in-sequencesegment

i data acki

TCPsender

TCPreceiverRouter4 0 3 9 3 73 8

received:...35

36

4 1 4 0 3 83 9

3 5 3 73 63 4

received:...353637

timestep

3 53 3 3 63 4


25/41


Delayed Acknowledgements

Delaying acks reduces ack trafficAn ack is delayed until

another segment is received, ordelayed ack timer expires (200 ms typical)

4 0 3 9 3 73 8

3 53 3

received:...3536

New ack not producedon receipt of segment 36,

but on receipt of 37

4 1 4 0 3 83 9

3 5 3 7

received:...353637


26/41


Duplicate Acknowledgements 1

Adupack is generated whenever an out-of-order segment arrives at thereceiver (packet 37 gets lost)

4 0 3 9 3 73 8

3 63 4

received:...36

4 2 4 1 3 94 0

3 6 3 6

received:...36x

38

dupackon receipt of 38

2 timesteps

packet loss


27/41



Dupacks are not delayedDupacks may be generated when

a segment is lost (see previous slide), ora segment is delivered out-of-order :

4 0 3 9 3 83 7

3 63 4

4 1 4 0 3 73 9

3 6 3 6

dupackon receipt of 38

received:...36x

38

received:...36

1 timestep


28/41



4 0 3 7 3 83 9

3 63 4

4 1 4 0 3 93 7

3 6 3 6

dupack

3 4

received:...36x

38

received:...36

4 2 4 1 3 74 0

3 6 3 6 3 6

dupackdupack

received:...36x

3839

4 3 4 2 4 04 1

3 6 3 6 3 9

new ackdupack

received:...363738

39

3 6

dupack

Number ofdupacksdepends on

how muchout-of-ordera packet is

A series ofdupacksallows the

sender toguess that asinglepacket hasbeen lost


29/41


Window Based Flow Control 1Sliding window protocol

Window sizeW is minimum ofreceivers advertised window - determined by available buffer spaceat the receiver and signalled with each ackcongestion window - determined by the sender, based on received

acksTCPs window based flow control is self-clocking:

New segments are sent when outstanding segments are ackd

2 3 4 5 6 7 8 9 10 11 131 12

Senders window

Acks received Not transmitted


30/41


Window Based Flow Control 2

Optimum window size:W = data rate * RTT =bandwidth-delay product(optimum use of link capacity: pipe is full)

3 8 3 73 94 0

3 33 5

3 43 6

packetdimensions:

rate

transmittime

TCPsender

TCPreceiverRouter

size

W = 8 segments (33...40)

What if window size is too large?Queuing at intermediate routers (e.g. at wireless access point)

=> increased RTT due to queuing delays=> potential of packet lossWhat if window size is too small?

Inefficiency: unused link capacity


31/41


Packet Loss Detection Based on TimeoutTCP sender starts a timer for a segment (only one segment at a time)If ack for the timed segment is not received before timer expires,

outstanding data are assumed to be lost and retransmitted=> go-back-N ARQ

Retransmission timeout (RTO) is calculated dynamically based onmeasured RTT:

RTO = mean RTT + 4 * mean deviation of RTTMean deviation = average of |sample mean| is easier tocalculate than standard deviation (and larger, i.e. moreconservative)

Large variations in the RTT increase the deviation, leading to largerRTORTT is measured as a discrete variable, in multiples of a tick:

1 tick = 500 ms in many implementationssmaller tick sizes in more recent implementations (e.g. Solaris)

RTO is at least 2 clock ticks

l k ff


32/41


Exponential Backoff

Double RTO on successive timeouts:

Total time until TCP gives up is up to 9 minRationale: Allow an intermediate, congested router to recoverProblem: If ack is lost, TCP just waits for the next timeout

Segmenttransmitted

Timeout occursbefore ack received,

segment retransmitted

Timeout interval doubledT1=RTO T2 = 2 * T1

P k t L D t ti B d D k


33/41


Packet Loss Detection Based on Dupacks:Fast Retransmit Mechanism

TCP sender considers timeout as a strong indication that there is asevere link problem

On the other hand, continuous reception of dupacks indicates that

following segments are delivered, and the link is ok=> TCP sender assumes that a (single) packet loss has occurred if itreceives three dupacks consecutively

=> Only the (single) missing segment is retransmitted

=> selective-repeat ARQ

Note: 3 dupacks are also generated if a segment is delivered at least 3places out-of-order

=> Fast retransmit useful only if lower layers deliver packetsalmostordered- otherwise, unnecessary fast retransmit

Fl C l b h S d


34/41


Flow Control by the SenderSlow StartInitially,congestion window size (cwnd)= 1 MSSIncrementcwnd by 1 MSS on each new ackSlow start phase ends when cwnd reaches ssthresh (slow-start

threshold)=> cwnd grows exponentially with time during slow start (in theory)Factor of 1.5 per RTT if every other segment is ackdFactor of 2 per RTT if every segment is ackd

In practice: increase is slower because of network delays (see next slide)Congestion AvoidanceOn each new ack, increase cwnd by 1/cwnd segments

=> cwnd grows linearly with time during congestion avoidance (intheory)1/2 MSS per RTT if every other segment ackd1 MSS per RTT if every segment ackd

Sl St t & C ti A id Th


35/41


0

2

4

6

8

10

12

14

0 1 2 3 4 5 6 7 8 9

Time / RTT

c w n

d ( s e g m e n

t s )

Slow Start

CongestionAvoidance

ssthresh

Slow Start & Congestion Avoidance Theory

Theoretical assumption: after sending n segments, n acks arrive within one RTT.Note that Slow Start

starts slowly, but speeds up quickly.

Receiversadvertisedwindow = 12

Slo St rt Re lit (Incl ding Net ork Del )


36/41


Slow Start Reality (Including Network Delay)Taking network delay into account, cwnd increases exponentially turns into:

cwnd increases sub-exponentiallypairs of segments are sent while pipe fills

Simple example:one-way delay = 1 timestepdata rate = 1 segment / timestep

Time-step Sender action cwnd

#segmentssent

#segmentsoutstanding

#segmentsrecv'd and

ack'd Receiver action

0 initial values1

0send segment 1 1 11 1 receive and ack segment 1

2 receive ack 1 2 0send segments 2 and 3 2 2

3 1 receive and ack segment 2

4 receive ack 2 3 1 1 receive and ack segment 3send segments 4 and 5 2 3

5 receive ack 3 4 2 1 receive and ack segment 4send segments 6 and 7 2 4

6 receive ack 4 5 3 1 receive and ack segment 5

send segments 8 and 9 2 5

sending rate > data rate (cwnd > 2)(timestep 4 onwards)

=> at some point in time there willbe a packet loss, causing TCPto slow down

Congestion Control after Packet Loss


37/41


Congestion Control after Packet Loss

Packet loss detected by timeout (=> severe link problem):Retransmit lost segmentsGo back to Slow Start :

Reduce cwnd to initial value of1 MSSSet ssthresh to half of window size before packet loss:

ssthresh = max((min(cwnd, receivers advertised window)/2 ), 2 MSS)

Packet loss detected by 3 dupacks (=> single packet loss, but link is ok):Fast Retransmit single missing segmentInitiateFast Recovery:

Set ssthresh and cwnd to half of window size before packet loss:ssthresh = max((min(cwnd, receivers advertised window)/2), 2 MSS)cwnd = ssthresh + number of dupacks

When a new ack arrives: continue withCongestion Avoidance:cwnd = ssthresh

Packet Loss Detected by Timeout


38/41


Packet Loss Detected by Timeout

0

5

10

15

20

25

0 3 6 9 1 2 1 5 2 0 2 2 2 5

Time / RTT

c w n d

( s e g m e n

t s )

ssthresh = 8

ssthresh = 10

cwnd = 20Timeout

cwnd = 1

Packet Loss Detected by 3 Dupacks


39/41


0

2

4

68

10

0 2 4 6 1 0 1 2 1 4

Time / RTT

c w n

d ( s e g m e n

t s )

After Fast Recovery

Packet Loss Detected by 3 Dupacks

After fast retransmit and fast recovery window size is reduced in halfMultiple packet losses within one RTT can result in timeout

ssthresh = 4

3 Dupacks

cwnd = 8

cwnd = 4

Summary: TCP


40/41


Summary: TCPTCP provides aconnection-oriented,

reliable byte-stream service:application data stream is transferred insegments based onlower layerMTU

receiver sends back cumulative acknowledgements(acks)sliding windowmechanism withflow controlbased onreceiversadvertised window,senders Slow Startand Congestion Avoidancemechanisms

Error control & packet loss detection based onadaptive retransmission timeout=> back to Slow Start,duplicate acknowledgments(dupacks) =>Fast Retransmit &Fast Recovery

References


41/41


References

The bible:W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols

Douglas E. Comer: Computernetzwerke und Internets. 3. Auflage,

Pearson Studium, Prentice Hall, 2002

The Internet...

Standards (RFCs): http://www.ietf.org/

MK-Review of TCP-IP Protocol Suite

Documents

Transcript of MK-Review of TCP-IP Protocol Suite