chp3.ppt_0

8/2/2019 chp3.ppt_0

1/220

8/2/2019 chp3.ppt_0

2/220

[email protected]@iust.ac.ir ITransport LayerITransport Layer 3-3-22

Chapter 3 OutlineChapter 3 Outline

3. Introduction 3.1 Transport-layer

services

3.2 Multiplexing anddemultiplexing

3.3 Connectionlesstransport: UDP

3.4 Principles of reliabledata transfer

3.5 Connection-orientedtransport: TCP segment structure

reliable data transfer

flow control

connection management

3.6 Principles of congestioncontrol

3.7 TCP congestion control

3.8 Multimedia Stream & TCP

3.9 TCP fairness 3.10 TCP modeling

3.11 http modeling

8/2/2019 chp3.ppt_0

3/220


Protocols/ServicesProtocols/Services

application

transport

network

link

physical

Data TransportData Transport

ServicesServices

Application ProgramApplication Program

ServicesServices

Hop-to-HopHop-to-Hop

protocolsprotocols

End-to-EndEnd-to-End

protocolsprotocols

8/2/2019 chp3.ppt_0

4/220


Data Transport Services1Data Transport Services1

(API)

(API)

App. SoftwareApp. Software

App. SoftwareApp. Software

transport

network

link

physical

application

ControlledControlled

by OSby OS

ControlledControlled

by App. Soft.by App. Soft.

the applicationthe application

transport

network

link

physical

the applicationthe application

Data

Transport

Services

8/2/2019 chp3.ppt_0

5/220


Data Transport Services2Data Transport Services2

Data

Transport

Services

Data

Transport

Services

Computer NetworkComputer NetworkComputer Network

application processapplication process


application processapplication processapplication processapplication process



Applications Messages, Objects, Files

Data Transport Services are provided to the applicationData Transport Services are provided to the application

process. The main services are:process. The main services are:

Breaking down the messages, in source, andBreaking down the messages, in source, andassembling the message, in destination.assembling the message, in destination.

Source-Destination routing, finding the path,Source-Destination routing, finding the path,through the links and routers (switches) of thethrough the links and routers (switches) of thenetwork.network.

SourceDestination (end to end) flow control. ItSourceDestination (end to end) flow control. Itmakes possible slow-running process wellmakes possible slow-running process wellcommunicate with fast-running process.communicate with fast-running process.

Error detection and correction.Error detection and correction. ......

8/2/2019 chp3.ppt_0

6/220


Services & Layer ProtocolsServices & Layer Protocols

Transport-layer Protocols:

They take care of application processes. The processes aredistinguished by means of port numbers.

They control flow intensity between the communicatingprocesses.

They apply acknowledgment scheme and make a reliable inter-inter-

process communication. Network-layer Protocols:

They manage to pass packets router-by-router, from sourcesource hostto destinationdestination host. Hosts are distinguished by means of IP add.

They do accounting for inter-inter-hosthost traffic. Link-layer Protocols and Physical-layer Protocols:

They make frames move into links, repeaters, hubs, switches, androutes in a way from source host to destination host.

They take care of channel coding and error correction system.

They regulate flow intensity between adjacent intermediate

Transport-layer Protocols:

They take care of application processes. The processes aredistinguished by means of port numbers.

They control flow intensity between the communicatingprocesses.

They apply acknowledgment scheme and make a reliable inter-inter-

process communication. Network-layer Protocols:

They manage to pass packets router-by-router, from sourcesource hostto destinationdestination host. Hosts are distinguished by means of IP add.

They do accounting for inter-inter-hosthost traffic. Link-layer Protocols and Physical-layer Protocols:

They make frames move into links, repeaters, hubs, switches, androutes in a way from source host to destination host.

They take care of channel coding and error correction system.

They regulate flow intensity between adjacent intermediate

Data

Transport

Services

transportnetwork

linkphysical

8/2/2019 chp3.ppt_0

7/[email protected]@iust.ac.ir ITransport LayerITransport Layer 3-3-77

network layer:logical communication between host-router, router-router, router-host.

transport layer:logical communication betweenprocesses. relies on: enhances from network layer services extends host-to-host communication to process-to-

process communication

Computer Network -Computer Network - UniversityUniversityanalogyanalogyIUST studentssend letters to TU students

processes = students, Port number = students ID number,

application messages = letters in envelopes, hosts = universities, IP add. = universitys address, transport protocol = post office of universities network-layer protocol = postal service of state

Transport Layer vs. Network LayerTransport Layer vs. Network Layer

8/2/2019 chp3.ppt_0



3. Introduction

3.1 Transport-layerservices






flow control






3.11 http modeling

8/2/2019 chp3.ppt_0


provide logical communication

between application processesrunning on different hosts transport protocols run in end

systems sending side: breaks app

messagesmessages into segments,passes to network layer

receiving side:reassembles segments intomessagesmessages, passes toapplication layer

more than one transportprotocol available toapplications.

Internet: TCP and UDP

provide logical communication

between application processesrunning on different hosts transport protocols run in end

systems sending side: breaks app

messagesmessages into segments,passes to network layer

receiving side:reassembles segments intomessagesmessages, passes toapplication layer

more than one transportprotocol available toapplications.

Internet: TCP and UDP

network

data link

physical

application

transport

network

data link

physical

application

transportnetwork

data link

physical

Transport Services and ProtocolsTransport Services and Protocols

LogicalLogical end to end transportend to end transport

8/2/2019 chp3.ppt_0


Ht

Message

applicationHa Message

transport

Ht Ht Ht

network

App. Process decides to send

a message to its counterpart

App. Layer adds its header,

sends the message to transport layer

Transport layer breaks down

the message into several parts,

add its header to each part

And makes segments.

It sends one-by-one segmentsto network layer

Protocol layering and dataProtocol layering and data

App. ProcessApp. ProcessApp. ProcessApp. Process

8/2/2019 chp3.ppt_0


reliable, in-orderdelivery (TCP) congestion control,

flow control,

connection setup. unreliable, unordered

delivery (UDP) no-frills extension of

best-effort IP. services not available:

delay guarantees,

bandwidth guarantees.

reliable, in-orderdelivery (TCP) congestion control,

flow control,

connection setup. unreliable, unordered

delivery (UDP) no-frills extension of

best-effort IP. services not available:

delay guarantees,

bandwidth guarantees.

Logical end to endLogical end to end

transporttransport

Internet Transport-Layer ProtocolsInternet Transport-Layer Protocols

network

data link

physical

network

data link

physical

application

transport

network

data link

physical

application

transportnetwork

data link

physical

8/2/2019 chp3.ppt_0



3. Introduction


3.2 Multiplexing anddemultiplexing 3.3 Connectionless

transport: UDP




flow control






3.11 http modeling

8/2/2019 chp3.ppt_0


applicationapplicationapplicationapplication

transporttransporttransporttransport

networknetworknetworknetwork

linklinklinklink

physicalphysicalphysicalphysical

P1 applicationapplicationapplicationapplication



linklinklinklink





linklinklinklink


P2P3 P4P1

host 1 host 2 host 3

= process = socket

Multiplexing at Sending Host

gathering data from multiple sockets, enveloping data

with header (later used for demultiplexing)

Multiplexing at Sending Host

gathering data from multiple sockets, enveloping data

with header (later used for demultiplexing)

Multiplexing/DemultiplexingMultiplexing/Demultiplexing

multiplexingmultiplexing

8/2/2019 chp3.ppt_0





linklinklinklink


P1 applicationapplicationapplicationapplication



linklinklinklink





linklinklinklink


P2P3 P4P1

host 1 host 2 host 3

= process = socket

Demultiplexing at Receiving Host

delivering received segments

to correct socket

Demultiplexing at Receiving Host

delivering received segments

to correct socket

Multiplexing/DemultiplexingMultiplexing/Demultiplexing

demultiplexingdemultiplexing

8/2/2019 chp3.ppt_0


host receives IP datagrams: each datagram has source IPsource IP

address, destination IP addressaddress, destination IP address

each datagram carries 1

transport-layer segment each segment has source,source,

destination port numberdestination port number(recall: well-known port numbersfor specific applications).

host uses IP addresses & portnumbers to direct segment toappropriate socket.

How Demultiplexing WorksHow Demultiplexing Works

TCP/UDP segment formatTCP/UDP segment format

source port # dest port #32 bits

applicationapplication

datadata

(message)(message)

other header fieldsother header fields

source port # dest port #

applicationapplication

datadata

(message)(message)

other header fieldsother header fields

8/2/2019 chp3.ppt_0


Apps create sockets indestination:

sd1 = Socket(PF-Inet,sock-Dgram,Ipproto_TCP);

Bind(sd1, Socket,Socket length);

UDP Socket identified by2-tuple: Dest. IP address Dest. Port number. It means:

Socket =(dest IP address , dest port number)

When host receives UDPWhen host receives UDPsegment:segment: checks destination portchecks destination port

number in segment,number in segment, directs UDP segment todirects UDP segment to

SocketSocket (process) with that(process) with thatport number,port number, IP datagrams with differentIP datagrams with different

source IP addresses and/orsource IP addresses and/orsource port numbers directedsource port numbers directedto sameto same socketsocket (process)(process)..

Connectionless Demultiplexing1Connectionless Demultiplexing1

8/2/2019 chp3.ppt_0



create socket,port=x, forincoming request:serverSocket =DatagramSocket()

read request fromserverSocket

write reply toserverSocket

specifying clienthost address,port number

Server

(running on IP address:C)

closeclientSocket

read reply fromclientSocket

create socket,clientSocket =DatagramSocket()

Create, address (hostid, port=x,send datagram requestusing clientSocket

Client

(running on IP address:A)

8/2/2019 chp3.ppt_0


Client

IP:B

P2

client

IP: A

P1P3

server

IP: C


P1

server (datagram) sockets: (C, 5193)client socket: (A, 4012)

SP: 5193SP: 5193

DP: 801DP: 801

C to BC to B

SP: 801SP: 801

DP: 5193DP: 5193

B to CB to CB to CB to C

SP: 5193SP: 5193

DP: 4012DP: 4012

C to A

SP: 4012SP: 4012

DP: 5193DP: 5193

A to C

Two arriving UDP segments with

different source IP address or sourceport number will be directed to a

socket.

client socket: (B, 801)

8/2/2019 chp3.ppt_0


TCP socket identifiedby 4-tuple: source IP address source port number dest IP address dest port number

receiving host uses allfour values to directsegment to appropriatesocket.

TCP socket identifiedby 4-tuple: source IP address source port number dest IP address dest port number

receiving host uses allfour values to directsegment to appropriatesocket.

Server host may supportmany simultaneous TCPsockets: each socket identified by

its own 4-tuple

Example: Web servershave different socketsfor each connectingclient non-persistent HTTP will

have different socket foreach request.

Server host may supportmany simultaneous TCPsockets: each socket identified by

its own 4-tuple

Example: Web servershave different socketsfor each connecting

client non-persistent HTTP will

have different socket foreach request.

Connection-Oriented Demultiplexing1Connection-Oriented Demultiplexing1

8/2/2019 chp3.ppt_0


create socket,connect to

hostidhostid, port=

xxclientSocket =Socket()

read reply fromclientSocket

closeclientSocket

send request usingclientSocket

wait for incoming

connection requestconnectionSocket =welcomeSocket.accept()

create socket,port=xx, forincoming request:welcomeSocket =

ServerSocket()

closeconnectionSocket

Create and read request fromconnectionSocket

write reply toconnectionSocket

TCPconnection setup

Client/Server Socket Interaction: TCPClient/Server Socket Interaction: TCP

Client(running on IP address:A)

Server

(running on IPaddress:C)

8/2/2019 chp3.ppt_0


Sockets in Connection-OrientedSockets in Connection-Oriented

ClientsocketClientsocket

ConnectionsocketConnectionsocket

Welcoming

socket

Welcoming

socket

Three

-wayh

andshake

Client processClient process Server processServer process

Client IP Address&

Port Number

Server IP Address&

Port Number2

Server IP Address&

Port Number1

bytes

Server

(running on IPaddress:C)

Client(running on IP address:A)

Client IP Address&

Port Number+

4-tuple identifier

8/2/2019 chp3.ppt_0


client

IP: A

server

IP: C


P1

SP: 2549SP: 2549

DP: 1324DP: 1324

C to A

P2

SP: 1324SP: 1324

DP: 80DP: 80

A to C

connection socket (A, C, 1324, 2549)client sockets (C, A, 2549, 1324)

SP: 1324SP: 1324

DP: 2549DP: 2549

AA toto CCAA toto CC

8/2/2019 chp3.ppt_0



Client

IP:B

P1

client

IP: A

P1P3P5

server

IP: C

SP: 9157SP: 9157DP: 2053DP: 2053

P6

A to C

SP: 5775SP: 5775DP: 2053DP: 2053

B to C

SP: 1807SP: 1807

DP: 2053DP: 2053

A to C

P4P2

Server host may support many simultaneous TCP sockets, with each socket attached to a process.

Each socket is identified by its own 4-tuple.

All 4 fields are used to direct (demultiplex) the segment to the appropriate socket.

Server host may support many simultaneous TCP sockets, with each socket attached to a process.

Each socket is identified by its own 4-tuple.

All 4 fields are used to direct (demultiplex) the segment to the appropriate socket.

In contrast with UDP, two arriving TCP segments with different source IP address or

source port number will be directed to two different sockets.

In contrast with UDP, two arriving TCP segments with different source IP address or

source port number will be directed to two different sockets.

8/2/2019 chp3.ppt_0



Client

IP:B

P1

client

IP: A

P1P3P4

server

IP: C

SP: 9157SP: 9157DP: 2053DP: 2053

A to C

SP: 5775SP: 5775DP: 2053DP: 2053

B to C

SP: 1807SP: 1807

DP: 2053DP: 2053

A to C

P2

Threaded Server

8/2/2019 chp3.ppt_0

25/220


Chapter 3 outlineChapter 3 outline

3. Introduction







flow control






3.11 http modeling

8/2/2019 chp3.ppt_0

26/220


simple Internet transportprotocol.

best effort service, UDPsegments may be:

Lost, Delivered out of order

to app,

connectionless:

no handshaking betweenUDP sender, receiver.

each UDP segmenthandled independently

of others.

Why is there a UDP? no connection

establishment (which can

add delay). simple: no connection state

at sender, receiver.

small segment header.

no congestion control: UDPcan blast away as fast asdesired

UDP: User Datagram ProtocolUDP: User Datagram Protocol [RFC 768][RFC 768]

d

8/2/2019 chp3.ppt_0

27/220


often used for streamingmultimedia apps

loss tolerant

rate sensitive

other UDP uses DNS

SNMP

reliable transfer over UDP:add reliability at applicationlayer

application-specificerror recovery!


32 bits

ApplicationApplication

datadata

(message)(message)

UDP segment format

length checksumLength, in

bytes of UDP

segment,

including

header

UDP HeaderUDP Header

Ch k

8/2/2019 chp3.ppt_0

28/220


Sender:

treat segment contents assequence of 16-bitintegers.

checksum: addition (1s

complement sum) ofsegment contents.

sender puts checksumvalue into UDP checksumfield.

Sender:

treat segment contents assequence of 16-bitintegers.

checksum: addition (1s

complement sum) ofsegment contents.

sender puts checksumvalue into UDP checksumfield.

Receiver:

compute checksum ofreceived segment

check if computed checksumequals checksum field value:

NO - error detected YES - no error detected.

Receiver:

compute checksum ofreceived segment

check if computed checksumequals checksum field value:

NO - error detected YES - no error detected.

Goal: detect errors (e.g., flipped bits) in transmitted segment

UDP ChecksumUDP Checksum

Ch k E l

8/2/2019 chp3.ppt_0

29/220


Checksum ExampleChecksum Example

Source Port #:

Destin. Port #:

1scompleme

ntChecksum:

Note That: Source Port# + Dest. Port# + Checksum =1111111111111111

Sum:

1 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0

1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 11 1 1 0 0 1 0 1 0 1 1 0 0 1 0 1 0

Length:

0 0 1 1 0 1 0 1 0 0 1 1 0 1 0 1

Checksum Example When msb is not ZeroChecksum Example When msb is not Zero

8/2/2019 chp3.ppt_0

30/220


Checksum Example-When msb is not ZeroChecksum Example-When msb is not Zero

Note

When adding numbers, a carryout from the mostsignificant bit needs to be added to the result

Example: add two 16-bit integers

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0

1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0

1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

wraparound

Sum:Checksum:

Ch 3 liCh 3 li

8/2/2019 chp3.ppt_0

31/220



3. Introduction


3.2 Multiplexing and

demultiplexing


3.4 Principles ofreliable data transfer



flow control






3.11 http modeling

Ch 3 liCh 3 li

8/2/2019 chp3.ppt_0

32/220


Important in: app., transport, link layers.Important in: app., transport, link layers.

ap

plication

ap

plication

layer

layer

ap

plication

ap

plication

layer

layer

(a) Service model

(b) Service implementation


characteristics of unreliable channel will

determine complexity of reliable data

characteristics of unreliable channel will

determine complexity of reliable data

R li bl D T f G i dR li bl D T f G i d

8/2/2019 chp3.ppt_0

33/220


send

side

receive

side

rdt_send():called fromabove, (e.g., by app.). Passed

data to

deliver to receiver upper layer

udt_send():called by

rdt,

to transfer packet over

rdt_rcv():called when

packet arrives on rcv-side of

channel

deliver_data():called by rdt to deliver

data to upper

Reliable Data Transfer: Getting startedReliable Data Transfer: Getting started

R li bl D T f i dR li bl D t T f tti t t d

8/2/2019 chp3.ppt_0

34/220


We will:

incrementally develop sender, receiver sides ofreliable data transfer protocol (rdt)

consider only unidirectional data transfer but control info will flow on both directions!

use finite state machines (FSM) to specifysender, receiver

We will:

incrementally develop sender, receiver sides ofreliable data transfer protocol (rdt)

consider only unidirectional data transfer but control info will flow on both directions!

use finite state machines (FSM) to specifysender, receiver

state: when in

this state

next state

uniquely

determined

state

1state

2

event causing state transitionactions taken on state transition

eventactions

Reliable Data Transfer: getting startedReliable Data Transfer: getting started

R li bl D t T f U li bl Ch lR li bl D t T f U li bl Ch l

8/2/2019 chp3.ppt_0

35/220


Reliable Data Transfer over Unreliable ChannelReliable Data Transfer over Unreliable Channel

rdt1.0: underlying channel perfectly reliable.

rdt2.0: underlying channel may flip bits in packet. ACK/NAK +Stop&Wait.

rdt2.1: What happens if ACK/NAK corrupted?

Sender handles defected ACK/NAKs.

rdt2.2: a NAK-free protocol. Instead of NAK, receiver sends ACK for last pkt received

OK.

Duplicate ACK at sender results in same action as NAK:

retransmit current pkt. rdt3.0: Channels with errors andloss (Timer).

Stop&Wait: Performance is low.

Pipelining increase the performance: Go-Back-N, Selective

Repeat.

rdt1.0: underlying channel perfectly reliable.

rdt2.0: underlying channel may flip bits in packet. ACK/NAK +Stop&Wait.

rdt2.1: What happens if ACK/NAK corrupted?

Sender handles defected ACK/NAKs.

rdt2.2: a NAK-free protocol. Instead of NAK, receiver sends ACK for last pkt received

OK.

Duplicate ACK at sender results in same action as NAK:

retransmit current pkt. rdt3.0: Channels with errors andloss (Timer).

Stop&Wait: Performance is low.

Pipelining increase the performance: Go-Back-N, Selective

Repeat.

dt1 0dt1 0 l f l l li bl h ll f l l li bl h l

8/2/2019 chp3.ppt_0

36/220


underlying channel perfectly reliable no bit errors no loss of packets

separate FSMs for sender, receiver: sender sends data into underlying channel

receiver read data from underlying channel

underlying channel perfectly reliable no bit errors no loss of packets

separate FSMs for sender, receiver: sender sends data into underlying channel

receiver read data from underlying channel

Wait forcall fromabove

sndpkt = make_pkt(data)udt_send(sndpkt)

rdt_send(data)

sender

rdt_send(data) event, creates a packet

containing the data via the action

make_pkt(data) and sends the packet via the

action udt_send(packet).

Wait forcall from

belowextract (rcvpkt,data)deliver_data(data)

rdt_rcv(rcvpkt)

receiver

rdt_rcv(rcvpkt)event, removes the data from the

packet via the action extract(rcvpkt, data) and

passes the data up to upper layer via the action

deliver_data(data).

rdt1.0:rdt1.0: a protocol for a completely reliable channela protocol for a completely reliable channel

dt2 0 h l ith bitdt2 0 h l ith bit

8/2/2019 chp3.ppt_0

37/220


underlying channel may flip bits in packet

recall: UDP checksum to detect bit errors. thequestion: how to recover from errors:

acknowledgements (ACKs):receiver explicitly tells sender thatpkt received OK.

negative acknowledgements (NAKs):receiver explicitly tellssender that pkt had errors (Please repeat that.)

sender retransmits pkt on receipt of NAK.

new mechanisms in rdt2.0 (beyond rdt1.0):

error detection. receiver feedback: Reciever sends control message (ACK,NAK)

to sender.

raliable data transfer based the retransmission is known as:

ARQ (Automatic Repeat reQuest).

underlying channel may flip bits in packet

recall: UDP checksum to detect bit errors. thequestion: how to recover from errors:

acknowledgements (ACKs):receiver explicitly tells sender thatpkt received OK.

negative acknowledgements (NAKs):receiver explicitly tellssender that pkt had errors (Please repeat that.)

sender retransmits pkt on receipt of NAK.

new mechanisms in rdt2.0 (beyond rdt1.0):

error detection. receiver feedback: Reciever sends control message (ACK,NAK)

to sender.

raliable data transfer based the retransmission is known as:

ARQ (Automatic Repeat reQuest).

rdt2.0: channel with bit errorsrdt2.0: channel with bit errors

dt2 0 FSM ifi tidt2 0 FSM ifi ti (S & i )(S &W i )

8/2/2019 chp3.ppt_0

38/220


extract(rcvpkt,data)deliver_data(data)

udt_send(ACK)

rdt_rcv(rcvpkt) &&notcorrupt(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) &&corrupt(rcvpkt)

Wait forcall from

belowReceiver

(one state)

Wait forcall from

aboveudt_send(sndpkt)

rdt_rcv(rcvpkt) &&isNAK(rcvpkt)Wait for

ACK or

NAK

Sender

(two states)

sndpkt = make_pkt(datadata, checksum)udt_send(sndpkt)

rdt_send(datadata)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for call from above

ACK packet is received.

NACK packet is received.

rdt2.0: FSM specificationrdt2.0: FSM specification (Stop&Wait)(Stop&Wait)

dt2 0 ti ithdt2 0 ti ith

8/2/2019 chp3.ppt_0

39/220



Wait forACK or

NAK

Wait forcall from

below

sndpkt = make_pkt(datadata, checksum)

udt_send(sndpkt)

rdt_send(datadata)

udt_send(sndpkt)

rdt_rcv(rcvpkt) &&isNAK(rcvpkt)


Wait for call form above

udt_send(NAK)


extract(rcvpkt,datadata)deliver_data(datadata)

udt_send(ACK)


rdt2.0: operation with no errorsrdt2.0: operation with no errors

dt2 0 irdt2 0: error scenario

8/2/2019 chp3.ppt_0

40/220



Wait forACK or

NAK

Wait forcall from

below

sndpkt = make_pkt(datadata, checksum)

udt_send(sndpkt)

rdt_send(datadata)


Wait for call from above

udt_send(NAK)


extract(rcvpkt,datadata)deliver_data(datadata)

udt_send(ACK)


udt_send(sndpkt)

rdt_rcv(rcvpkt) &&isNAK(rcvpkt)

rdt2.0: error scenariordt2.0: error scenario

dt2 0 h f t l d f t ACK/NAK C tirdt2 0 has a fatal defect: ACK/NAK Corruption

8/2/2019 chp3.ppt_0

41/220


What happens ifACK/NAK corrupted?

sender doesnt know whathappened at receiver!

cant just retransmit:possible duplicate

What to do?

sender ACKs/NAKsreceivers ACK/NAK? Whatif sender ACK/NAK lost?

retransmit, but this mightcause retransmission ofcorrectly received pkt!

What happens ifACK/NAK corrupted?

sender doesnt know whathappened at receiver!

cant just retransmit:possible duplicate

What to do?

sender ACKs/NAKsreceivers ACK/NAK? Whatif sender ACK/NAK lost?

retransmit, but this mightcause retransmission of

correctly received pkt!

Handling duplicates: sender adds sequence

numberto each pkt

sender retransmits current

pkt if ACK/NAK is recieved receiver discards (doesnt

deliver up) duplicate pkt

Handling duplicates: sender adds sequence

numberto each pkt

sender retransmits current

pkt if ACK/NAK is recieved receiver discards (doesnt

deliver up) duplicate pkt

Sender sends one packet,then waits for receiver

response

stop and wait

rdt2.0 has a fatal defect: ACK/NAK Corruptionrdt2.0 has a fatal defect: ACK/NAK Corruption

dt2 1rdt2 1: S dSender h dl d f t d ACK/NAKhandles defected ACK/NAKs

8/2/2019 chp3.ppt_0

42/220


Wait for call0 fromabove

Wait forACK orNAK 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) &&( corrupt(rcvpkt) ||

isNAK(rcvpkt) )

sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) &&( corrupt(rcvpkt) ||isNAK(rcvpkt) )

Wait forcall 1 from

above

Wait forACK orNAK 1

rdt_rcv(rcvpkt)&& notcorrupt(rcvpkt)

&& isACK(rcvpkt)

Wait for call 1from above


rdt_send(data)

rdt_rcv(rcvpkt)&& notcorrupt(rcvpkt)

&& isACK(rcvpkt)

Wait for call 0from above

Seq. no=1

Seq. no=0

rdt2.1:rdt2.1: SenderSenderhandles defected ACK/NAKs.handles defected ACK/NAKs.

rdt2 1:rdt2 1: ReceiverReceiver handles defectedhandles defected ACK/NAKACK/NAKs

8/2/2019 chp3.ppt_0

43/220


Wait for1 frombelow

Wait for0 frombelow

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)&& has_seq1(rcvpkt)

extract(rcvpkt,data)deliver_data(data)

sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

&& has_seq0(rcvpkt)extract(rcvpkt,data)deliver_data(data)


sndpkt = make_pkt(NAK, chksum)

udt_send(sndpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt)

rdt_rcv(rcvpkt) &&notcorrupt(rcvpkt) &&

has_seq0(rcvpkt)


rdt_rcv(rcvpkt) &&not corrupt(rcvpkt) &&

has_seq1(rcvpkt)


rdt_rcv(rcvpkt) && (corrupt(rcvpkt)

sndpkt = make_pkt(NAK, chksum)

udt_send(sndpkt)

rdt2.1:rdt2.1: ReceiverReceiverhandles defectedhandles defected ACK/NAKs.ACK/NAKs.

rdt2 1: discussionrdt2 1: discussion

8/2/2019 chp3.ppt_0

44/220


Sender: seq # added to pkt two seq. #s (0,1) will

suffice. Why? must check if received

ACK/NAK corrupted. twice as many states.

state must rememberwhether current pkthas 0 or 1 seq. #

Sender: seq # added to pkt two seq. #s (0,1) will

suffice. Why? must check if received

ACK/NAK corrupted. twice as many states.

state must rememberwhether current pkthas 0 or 1 seq. #

Receiver: must check if received

packet is duplicate.

state indicates whether0 or 1 is expected pktseq #.

note: receiver can notknow if its last

ACK/NAK received OKat sender.

Receiver: must check if received

packet is duplicate. state indicates whether

0 or 1 is expected pktseq #.

note: receiver can notknow if its last

ACK/NAK received OKat sender.

rdt2.1: discussionrdt2.1: discussion

rdt2 2: a NAK free protocolrdt2 2: a NAK free protocol

8/2/2019 chp3.ppt_0

45/220


same functionality as rdt2.1, using ACKsonly

instead of NAK, receiver sends ACK forlast pkt received OK receiver must explicitlyinclude seq # of pkt

being ACKed

duplicate ACK at sender results in same

action as NAK: retransmit current pktretransmit current pkt

same functionality as rdt2.1, using ACKsonly

instead of NAK, receiver sends ACK forlast pkt received OK receiver must explicitlyinclude seq # of pkt

being ACKed

duplicate ACK at sender results in same

action as NAK: retransmit current pktretransmit current pkt

rdt2.2: a NAK-free protocolrdt2.2: a NAK-free protocol

rdt2 2: sender receiver fragmentsrdt2 2: sender receiver fragments

8/2/2019 chp3.ppt_0

46/220


Wait forcall 0 from

above


rdt_send(data)

udt_send(sndpkt)


isACK(rcvpkt,1) )Wait forACK

0

sender

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)&& has_seq1(rcvpkt)

extract(rcvpkt,data); deliver_data(data)sndpkt = make_pkt(ACK1, chksum)

udt_send(sndpkt)


has_seq1(rcvpkt) )

udt_send(sndpkt) Wait for0 from

below

receiver

rdt_rcv(rcvpkt)&& notcorrupt(rcvpkt)&&isACK(rcvpkt,0)

Wait for

rdt2.2: sender, receiver fragmentsrdt2.2: sender, receiver fragments

1

rdt3 0: Channels with errorsrdt3 0: Channels with errors andand loss (Timer)loss (Timer)

8/2/2019 chp3.ppt_0

47/220


New assumption:underlying channel canalso lose packets (dataor ACKs)

checksum, seq. #, ACKs,retransmissions will beof help, but not enough

Q: how to deal with loss?

sender waits untilcertain data or ACKlost, then retransmits

Timer drawbacks?

New assumption:underlying channel canalso lose packets (dataor ACKs)

checksum, seq. #, ACKs,retransmissions will beof help, but not enough

Q: how to deal with loss?

sender waits untilcertain data or ACKlost, then retransmits

Timer drawbacks?

Approach: sender waitsreasonable amount oftime for ACK

retransmits if no ACK

received in this time if pkt (or ACK) just delayed

(not lost):

retransmission will beduplicate, but use of seq.#s already handles this

receiver must specify seq# of pkt being ACKed

requires countdown timer

Approach: sender waitsreasonable amount oftime for ACK

retransmits if no ACK

received in this time if pkt (or ACK) just delayed

(not lost):

retransmission will beduplicate, but use of seq.#s already handles this

receiver must specify seq# of pkt being ACKed

requires countdown timer

rdt3.0: Channels with errorsrdt3.0: Channels with errors andandloss (Timer)loss (Timer)

rdt3 0: Senderrdt3 0: Sender

8/2/2019 chp3.ppt_0

48/220


sndpkt = make_pkt(0, data, checksum)

udt_send(sndpkt)start_timer

rdt_send(data)

Waitfor

ACK0

Wait forcall 1 from

above


start_timer

rdt_send(data)

rdt_rcv(rcvpkt)&& notcorrupt(rcvpkt)&& isACK(rcvpkt,0)

stop_timer

rdt_rcv(rcvpkt)

&& notcorrupt(rcvpkt)&& isACK(rcvpkt,1)

stop_timer


timeout


timeout

Wait forcall 0from

above

Waitfor

ACK1

Wait for call 1 from above

rdt_rcv(rcvpkt)


isACK(rcvpkt,1) )

Wait for ACK0rdt_rcv(rcvpkt)

Wait for call 0 from above

rdt_rcv(rcvpkt) &&

( corrupt(rcvpkt) ||isACK(rcvpkt,0) )

Wait for ACK1

rdt3.0: Senderrdt3.0: Sender

rdt3 0 in actionrdt3 0 in action

8/2/2019 chp3.ppt_0

49/220


(b) lost packet(a) operation with no loss

rdt3.0 in actionrdt3.0 in action

rdt3 0 in actionrdt3 0 in action

8/2/2019 chp3.ppt_0

50/220


(c) lost ACK (d) premature time

rdt3.0 in actionrdt3.0 in action

Performance of Stop & Wait (rdt3 0)Performance of Stop & Wait (rdt3 0)

8/2/2019 chp3.ppt_0

51/220


rdt3.0 works, but performance stinks

example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:

U sender: utilization fraction of time sender busy sending 1KB pkt every 30 msec = 33kB/sec throughput over 1 Gbps link

network protocol limits use of physical resources!

T

transmit

= 8kb/pkt

109 b/sec= 8 sec

L (packet length in bits)

R (transmission rate, bps) =

Usender

= 0.008 ms

15ms + 15ms + 0.008

ms

= 0.00027L / R

RTT + L / R=

Performance of Stop & Wait (rdt3.0)Performance of Stop & Wait (rdt3.0)

rdt3 0: stop and wait operationrdt3 0: stop-and-wait operation

8/2/2019 chp3.ppt_0

52/220


first packet bit transmitted, t = 0sender receiver

RTT

last packet bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

ACK arrives, send nextpacket, t = RTT + L / R

Usender

=0.008

30.008=

0.00027L / R

RTT + L / R=

rdt3.0: stop-and-wait operationrdt3.0: stop-and-wait operation

Pipelined protocolsPipelined protocols

8/2/2019 chp3.ppt_0

53/220


Pipelining: sender allows multiple, in-flight, yet-to-be-acknowledged pkts range of sequence numbers must be increased

buffering at sender and/or receiver

Two generic forms of pipelined protocols:go-Back-N,selective repeat

(b) A pipelined protocol in operatio(a)A stop-and-waitprotocol in operation

data packet

ACK packet

data packet

ACK packet

Pipelined protocolsPipelined protocols

Pipelining: Increasing UtilizationPipelining: Increasing Utilization

8/2/2019 chp3.ppt_0

54/220


first packet bit transmitted, t = 0

sender receiver

RTT

last bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

ACK arrives, send nextpacket, t = RTT + L / R

last bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACK

Usender

=.024

30.008= 0.0008

3 * L / R

RTT + L / R=

Increase utilization

by a factor of 3!

Pipelining: Increasing UtilizationPipelining: Increasing Utilization

Go-Back-NGo-Back-N

8/2/2019 chp3.ppt_0

55/220


Sender: k-bit seq # in pkt header

window of up to N, consecutive unacked pkts allowed

ACK(n): ACKs all pkts up to, including seq # n -

may deceive duplicate ACKs (see receiver)

timer for each in-flight pkt

timeout(n): retransmit pkt n and all higher seq # pkts in window

alreadyACKd

sent, not

yet ACKd

usable,not yet sent

not usable67891

0

1

1

1

2

1

3

1

4

54321 1

5

1

6

1

7

1

8

1

9

2

0

2

1

2

2

2

3

2

4

2

5

2

6

2

7

2

8

2

9

3

0window size

N AC

K

6

send_base nextseqnum

cumulative ACK

Go-Back-NGo Back N

GBN: Sender extended FSMGBN: Sender extended FSM

8/2/2019 chp3.ppt_0

56/220


Waitstart_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])udt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum < base+N) {

sndpkt[nextseqnum] =make_pkt(nextseqnum,data,chksum)

udt_send(sndpkt[nextseqnum])if (nextseqnum == base+N) start_timer

nextseqnum++ }elserefuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum)stop_timerelsestart_timer


base=1nextseqnum=1

rdt_rcv(rcvpkt)&& corrupt(rcvpkt)

base

nextseqnum

base+N

wait

start11

22

If a timeout occurs, the sender resendsIf a timeout occurs, the sender resends allall packets thatpackets that

have been previously sent but that have not yet beenhave been previously sent but that have not yet been

acknowledged.acknowledged.

If an ACK is received but thereIf an ACK is received but there

are still additional transmitted-are still additional transmitted-

but-yet-to-be-acknowledgedbut-yet-to-be-acknowledged

packets, the timer is restartedpackets, the timer is restarted

Timer can be thought of as aTimer can be thought of as atimer for the oldesttimer for the oldest

transmitted-but-not-yet-transmitted-but-not-yet-

acknowledged packet.acknowledged packet.

GBN: Sender extended FSMGBN: Sender extended FSM

GBN: Receiver extended FSMGBN: Receiver extended FSM

8/2/2019 chp3.ppt_0

57/220


ACK-only: always send ACK for correctly-received pktwith highest in-orderseq #

may generate duplicate ACKs need only remember expectedseqnum

out-of-order pkt: discard (dont buffer) -> no receiver buffering!

Re-ACK pkt with highest in-order seq #

Wait

udt_send(sndpkt)

default

rdt_rcv(rcvpkt)&& notcurrupt(rcvpkt)&& hasseqnum(rcvpkt,expectedseqnum)

extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(expectedseqnum,ACK,chksum)udt_send(sndpkt)

expectedseqnum++

expectedseqnum=1sndpkt =make_pkt(expectedseqnum,ACK,chksum)

start

GBN: Receiver extended FSMGBN: Receiver extended FSM

8/2/2019 chp3.ppt_0

58/220

Selective RepeatSelective Repeat

8/2/2019 chp3.ppt_0

59/220


receiver individuallyacknowledges all correctlyreceived pkts buffers pkts, as needed, for eventual in-order delivery

to upper layer

sender only resends pkts for which ACK notreceived sender timer for each unACKed pkt

sender window N consecutive seq #s

again limits seq #s of sent, unACKed pkts

Selective RepeatSelective Repeat

Selective repeat: sender, receiver windowsSelective repeat: sender, receiver windows

8/2/2019 chp3.ppt_0

60/220


Selective repeat: sender, receiver windowsSelective repeat: sender, receiver windows

Selective repeatSelective repeat

8/2/2019 chp3.ppt_0

61/220


data from above : if next available seq # in

window, send pkt

timeout(n): resend pkt n, restart timer

ACK(n) in [sendbase,sendbase+N]:

mark pkt n as received if n smallest unACKed pkt,

advance window base tonext unACKed seq #

sender

pkt n in [rcvbase, rcvbase+N-1]

send ACK(n)

out-of-order: buffer

in-order: deliver (also deliver

buffered, in-order pkts),

advance window to next not-

yet-received pkt

pkt n in [rcvbase-N,rcvbase-1]

ACK(n)

otherwise:

ignore

receiver

Selective repeatSelective repeat

Selective repeat in actionSelective repeat in action

8/2/2019 chp3.ppt_0

62/220


Selective repeat in actionSelective repeat in action

Selective repeat: dilemmaSelective repeat: dilemma

8/2/2019 chp3.ppt_0

63/220


Example: seq #s: 0, 1, 2, 3

window size=3

receiver sees nodifference in twoscenarios!

incorrectly passesduplicate data as newin (a)

Q: what relationship

between seq # size and

Selective repeat: dilemmaSelective repeat: dilemma


8/2/2019 chp3.ppt_0

64/220


Chapter 3 outlineC p e 3 ou e

3. Introduction



demultiplexing 3.3 Connectionless

transport: UDP

3.4 Principles of reliable

data transfer 3.5 Connection-

oriented transport:TCP segment structure


flow control






3.11 http modeling

TCP: OverviewTCP: Overview RFCs: 793, 1122, 1323, 2018, 2581RFCs: 793, 1122, 1323, 2018, 2581

8/2/2019 chp3.ppt_0

65/220


full duplex data: bi-directional data flow in same

connection MSS: maximum segment size

connection-oriented: handshaking (exchange of control

msgs) inits sender, receiver statebefore data exchange

flow controlled: sender will not overwhelm receiver

no delay or bandwidth guarantee

point-to-point: one sender, one receiver Reliable:

guaranteed arrival no error in order delivery

in-order byte stream: no message boundaries

pipelined: TCP congestion and flow control set

window size send & receive buffersProcess

writes dataProcess

writes data

TCPsendbuffer

TCPsendbuffer

SocketSocket

Processreads data

Processreads data

TCPreceivebuffer

TCPreceivebuffer

SocketSocketsegment segment

TCP: OverviewTCP: Overview RFCs: 793, 1122, 1323, 2018, 2581RFCs: 793, 1122, 1323, 2018, 2581

TCP Reliable Data Transfer

8/2/2019 chp3.ppt_0

66/220


TCP provides reliable data transfer service on topof IPs unreliable service,

Cumulative ACKs,

Single retransmission timer, When the receiver receives out-of-order,

segments, it buffers them and re-ACK the last in-order data,

The sender retransmits at timeout or receivingduplicate ACKs,

Somewhere between Go-back-N and Selective

Repeat.


8/2/2019 chp3.ppt_0

67/220


pp


services



transport: UDP


data transfer 3.5 Connection-oriented

transport: TCP

segment structure


flow control






3.11 http modeling

TCP Segment StructureTCP Segment Structure

8/2/2019 chp3.ppt_0

68/220


gg

seq # is byte-stream number of firstdata byte in segment

URG: urgent data (generally not used)

ACK: ACK #valid

PSH: push data now

(generally not used)

RST, SYN, FIN:

connection estab

(setup, teardown

commands)

# bytes

rcvr willing

to accept

TCP checksum

(as in UDP)

Maximum Segment Size, window scaling factor,

Time-stamping, maximum segment length,

RFCs: 854, 1323

Header Length

[4Bytes]

TCP Segment StructureTCP Segment Structure

8/2/2019 chp3.ppt_0

69/220



32 bits

application

data(variable length)

sequence number

acknowledgement number

Receive window

Urg data pnterchecksum

FSRPAUhead

len

not

used

Options (variable length)

URG: urgent data

(generally not used)

ACK: ACK #

valid

PSH: push data now

(generally not used)RST, SYN, FIN:

connection estab

(setup, teardown

commands)

# bytes

rcvr willingto accept

TCP checksum

(as in UDP)

Maximum Segment Size,

window scaling factor,

Time-stamping,

maximum segment length,

RFCs: 854, 1323

[4Bytes]

seq # is byte-

stream number

of first data

byte in

segment

gg

TCP Segment Structure (con.)TCP Segment Structure (con.)

8/2/2019 chp3.ppt_0

70/220


applicatio

ntransport

rdt_send(data)

data

6000 B

(a) 6000 Byte

data

passed to TCP

Seq=001

Seq=1001

Seq=200

1

Se

q=3001

Seq=4001

Seq=5001

Byte

data

1 2 1001 2001 3001 4001

5001

(b) Data is broken into 6 1000-Byte-segments.

TCP Header

g ( )g ( )

TCP seq#s and Ack#sTCP seq#s and Ack#s

8/2/2019 chp3.ppt_0

71/220


Seq. #s:

byte streamnumber of firstbyte in segmentsdata

ACKs: seq # of next byte

expected fromother side

cumulative ACKQ: how receiver handles

out-of-order segments

A: TCP spec doesnt

say, it is up to

Host A Host BSeq=42,Ack=79,data=C

Seq=79,A

ck=43,data=C

Seq=43,Ack=80

User

types

C

host ACKs

receipt

of echoed

C

host ACKs

receipt of

C, echoesback C

timesimple telnet scenariosimple telnet scenario

qq

TCP Round Trip Time and TimeoutTCP Round Trip Time and Timeout

8/2/2019 chp3.ppt_0

72/220


Q: how to set TCPtimeout value?

longer than RTT but RTT varies

too short: prematuretimeout

unnecessaryretransmissions

too long: slow reaction

to segment loss

Q: how to set TCPtimeout value?

longer than RTT but RTT varies

too short: prematuretimeout

unnecessaryretransmissions

too long: slow reactionto segment loss

Q: how to estimate RTT?

SampleRTT: measured timefrom segment transmission

until ACK receipt ignore retransmissions

SampleRTT will vary, want

estimated RTT smoother average several recent

measurements, not justcurrent SampleRTT

Q: how to estimate RTT?

SampleRTT: measured timefrom segment transmission

until ACK receipt ignore retransmissions

SampleRTT will vary, want

estimated RTT smoother average several recent

measurements, not justcurrent SampleRTT

TCP uses a timeout/retransmit mechanism to recover from lost segment.TCP uses a timeout/retransmit mechanism to recover from lost segment.

pp

8/2/2019 chp3.ppt_0

73/220

Request for Comments: 2988, Nov 2000Request for Comments: 2988, Nov 2000

8/2/2019 chp3.ppt_0

74/220


q ,q

Until a round-trip time (RTT) measurement hasbeen made for a segment sent between the senderand receiver, the sender should set RTO 3 secs.

When the first RTT measurement SampleRTTismade, the host must set

1. StimatedRTTSampleRTT

2. DevRTTSampleRTT/23. RTO StimatedRTT+ max (G, 4DevRTT).

Experience has shown that finer clock granularities (G 100 msec)perform somewhat better than more coarse granularities.

Request for Comments: 2988, Nov 2000Request for Comments: 2988, Nov 2000

8/2/2019 chp3.ppt_0

75/220


q ,q ,

When a subsequent RTT measurement SampleRTT' is made, ahost must set

1. DevRTT(1 - )DevRTT + |StimatedRTT-SampleRTT'|

2. StimatedRTT (1 - ) StimatedRTT+ SampleRTT

3. RTO StimatedRTT+ max (G, 4 DevRTT)

The value of StimatedRTTused in the update to DevRTTis its

value before updating StimatedRTTitself using the second

assignment.

Whenever RTO is computed, if it is less than 1 second then the RTO

should be rounded up to 1 second.

The above should be computed using =1/8 and =1/4.

Example RTT estimationExample RTT estimation

8/2/2019 chp3.ppt_0

76/220


150

RTT(milisec)

350

300

100

200

250

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

n=time (seconds)

SampleRTT

EstimatedRTT


8/2/2019 chp3.ppt_0

77/220


p


services



transport: UDP



transport: TCP segment structure

reliable data transfer flow control






3.11 http modeling

TCP reliable data transferTCP reliable data transfer

8/2/2019 chp3.ppt_0

78/220


TCP creates rdtservice on top of IPsunreliable service

Pipelined segments

Cumulative acks TCP uses single

retransmission timer

TCP is a GBN styleprotocol. RFC 2018propose a SelectiveRepeat style for TCP.

TCP creates rdtservice on top of IPsunreliable service

Pipelined segments

Cumulative acks TCP uses single

retransmission timer

TCP is a GBN styleprotocol. RFC 2018propose a SelectiveRepeat style for TCP.

Retransmissions aretriggered by: timeout events

duplicate acks

Initially considersimplified TCP sender: ignore duplicate acks

ignore flow control,

congestion control

Retransmissions aretriggered by: timeout events

duplicate acks

Initially considersimplified TCP sender: ignore duplicate acks

ignore flow control,

congestion control

TCP sender events:TCP sender events:

8/2/2019 chp3.ppt_0

79/220


data rcvd from app:

Create segment withseq #

seq # is byte-streamnumber of first data

byte in segment start timer if not

already running (thinkof timer as for oldestunacked segment)

expiration interval:RTO

[TimeOutInterval]

data rcvd from app:

Create segment withseq #

seq # is byte-streamnumber of first data

byte in segment start timer if not

already running (thinkof timer as for oldestunacked segment)

expiration interval:RTO

[TimeOutInterval]

timeout:

retransmit segmentthat caused timeout

restart timer

Ack rcvd:

If acknowledgespreviously unackedsegments

update what is known tobe acked

start timer if there areoutstanding segments

timeout:

retransmit segmentthat caused timeout

restart timer

Ack rcvd:

If acknowledgespreviously unackedsegments

update what is known tobe acked

start timer if there areoutstanding segments

TCP SenderTCP Sender(simplified)(simplified)

8/2/2019 chp3.ppt_0

80/220


Comment:

SendBase-1: lastcumulatively

acked byte

Example:

SendBase-1 = 71y= 73, so the rcvr

wants 73+ ;

y > SendBase, so

that new data is

NextSeqNum = InitialSeqNumSendBase = InitialSeqNum

loop (forever) {

switch(event)

event: data received from application abovecreate TCP segment with sequence number NextSeqNumif (timer currently not running) start timerpass segment to IPNextSeqNum = NextSeqNum + length(data)

event: timer timeoutretransmit not-yet-acknowledged segment with

smallest sequence numberstart timer

event: ACK received, with ACK field value of y

if (y > SendBase) {SendBase = yif (there are currently not-yet-acknowledged segments)

start timer}

} /* end of loop forever */

NextSeqNum = InitialSeqNumSendBase = InitialSeqNum

loop (forever) {

switch(event)

event: data received from application abovecreate TCP segment with sequence number NextSeqNumif (timer currently not running) start timerpass segment to IPNextSeqNum = NextSeqNum + length(data)

event: timer timeoutretransmit not-yet-acknowledged segment with

smallest sequence numberstart timer

event: ACK received, with ACK field value of y

if (y > SendBase) {SendBase = yif (there are currently not-yet-acknowledged segments)

start timer}

} /* end of loop forever */

TCP: retransmission schemesTCP: retransmission schemes

8/2/2019 chp3.ppt_0

81/220


Ack=25001Win=000

Ack=25001Win=000

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 2122 2324 25 26

120010001

A data segment

1,2,3. .., 1000[B]

Win= RcvWindow

Win = 4000 [B]Win = 4000 [B]Seq=1Seq=1Ack=4001

Win=10000

Ack=4001

Win=10000

4001

Ack=12001

Win=5000

Ack=12001

Win=5000

TimeOut12001

Ack=18001Win=7000

Ack=18001

Win=7000

18001

Ack=20001

Win=5000

Ack=20001

Win=5000

20001

Host BHost A

ACKs from B is not detailed

TCP ACK generationTCP ACK generation[RFC 1122, RFC 2581]*[RFC 1122, RFC 2581]*

8/2/2019 chp3.ppt_0

82/220


Event at Receiver TCP Receiver action

Arrival of in-order segment

with

expected seq #. All data up to

expected seq # alreadyACKed.

Delayed ACK. Wait up to 500ms

for next segment. If no next

segment,

send ACK.

Arrival of in-order segment

with

expected seq #. One other

segment has ACK pending.

Immediately send single cumulative

ACK, ACKing both in-order

segments.

Arrival of out-of-order Immediately send duplicate ACK,

TCP retransmission (Normal ACK)*TCP retransmission (Normal ACK)*

8/2/2019 chp3.ppt_0

83/220


Seq=1,1000bytesdata

ACK=2001

Host B

Seq=4001

ACK=6

001

time

Host A

Seq=1001Seq=2001Seq=

3001

T

8/2/2019 chp3.ppt_0

84/220

TCP retransmission (Premature ACK)*TCP retransmission (Premature ACK)*

8/2/2019 chp3.ppt_0

85/220


Seq=1,1000bytesdata

ACK=

2001

Win2

Host BHost A

Seq=1001Seq=2001Seq=3001

T

8/2/2019 chp3.ppt_0

86/220


Sender keeps

transmission

based on

Win&SendBase

T

8/2/2019 chp3.ppt_0

87/220


TCP receiver sends an immediate ACK if it receivesan out-of-order segment.

This is a duplicate ACK.

This dupe ACK informs the sender and tells it whatsequence number the receiver expected.

Its unclear whether dupe ACKs indicate loss orsimply packet re-ordering on the network.

But, multiple duplicate ACKs probably indicate loss.

Fast RetransmitFast Retransmit

8/2/2019 chp3.ppt_0

88/220


Time-out period oftenrelatively long: long delay before

resending lost packet

Detect lost segmentsvia duplicate ACKs. Sender often sends

many segments back-to-back

If segment is lost,there will likely be manyduplicate ACKs.

If sender receives 3ACKs for the samedata, it supposes thatsegment after ACKeddata was lost: fast retransmit: resend

segment before timerexpires

8/2/2019 chp3.ppt_0

89/220

Fast retransmit algorithm:Fast retransmit algorithm:

8/2/2019 chp3.ppt_0

90/220


ent: ACK received, with ACK field value of yif (y > SendBase) {

SendBase = yif (there are currently not-yet-acknowledged segments)

start timer}

else {increment count of dup ACKs received for yif (count of ACKs received for y is 3) {

resend segment with sequence number y}

a duplicate ACK for

already ACKed segment

fast retransmit


8/2/2019 chp3.ppt_0

91/220



services



transport: UDP





flow control connection management





3.11 http modeling

TCP Flow ControlTCP Flow Control

8/2/2019 chp3.ppt_0

92/220


receive side of TCP

connection has a receivebuffer: RcvBuffer

Sender wont overflowreceivers buffer by

transmitting too much,

too fast. speed-matching

service: matching thesend rate to thereceiving apps drainrate.

App process may beslow at reading frombuffer.

TCP

data

in buffer

spare

buffer

data from IP

RcvW

indow

data to app proc.

RcvBuffer

TCP Flow Control: how it worksTCP Flow Control: how it works

8/2/2019 chp3.ppt_0

93/220


(Suppose TCP receiver discards out-of-order segments)

spare room in buffer =

Rcvr advertises spareroom by including valueof RcvWindow insegments

Sender limits unACKeddata to RcvWindow guarantees receive

buffer doesnt overflow

RcvWindow = RcvBuffer - [LastByteRcvd LastByteRead]

TCP

data

in buffer

spare

buffer

data from IP

RcvWind

ow

data to app proc.

RcvBuffer


8/2/2019 chp3.ppt_0

94/220



services



transport: UDP





flow control






3.11 http modeling

TCP Connection ManagementTCP Connection Management

8/2/2019 chp3.ppt_0

95/220


Recall:TCP sender, receiverestablish connectionbefore exchanging datasegments

initialize TCP variables:

seq. #s

buffers, flow controlinfo (e.g. RcvWindow)

client:connection initiatorSocket clientSocket = new

Socket("hostname","portnumber");

server:contacted by clientSocket connectionSocket =welcomeSocket.accept();

Three way handshake:

Step 1:client host sends TCPSYN segment to server

specifies initial seq #

no data

Step 2:server host receivesSYN, replies with SYNACKsegment

server allocates buffers

specifies server initial seq.#

Step 3: client receives SYNACK,replies with ACK segment,

which may contain data

TCP Connection Management (cont.)TCP Connection Management (cont.)

8/2/2019 chp3.ppt_0

96/220


client

SYN=1,ClientISN

server

ACK=1,S

YN=1,Se

r.ISN,Win

=X

ACK=1,Win=Y,SN=ISN

connection requestnopayload

connection accepted

nopayload

Payload(optional)

connection ack.

time time

Three way handshake:

Win= RcvWindow

ISN= Initial Sequence Number


8/2/2019 chp3.ppt_0

97/220


Closing a connection:Either of the two processes

participating in a TCPconnection can end theconnection.

Example

client closes socket:ClientSocket.close();

Step 1: client end systemsends TCP FIN controlsegment to server.

client

FIN=1

server

ACK=1

ACK=1

close

close

closedtimedw

ait

30

,60or120sec.

FIN=1mean

s:no

moredat a

from

sender

FIN=1

time

Final ACK lossFinal ACK loss

8/2/2019 chp3.ppt_0

98/220


If clients final ACK is lostthe server resends ACKand FIN.

If the resented ACK andFIN reaches client before

timed wait, client resendsits final ACK and waitsagain.

After timed out all

resources on client sidereleased (including portnumbers).

client

FIN=1

server

ACK=1

ACK=1

close

close

timed

wait

30

,60or

120sec.

FIN=1

time

FIN=1ACK=1

ACK=1The time is implementation-dependent.


8/2/2019 chp3.ppt_0

99/220


Step 2: server receives FIN, replies

with ACK. Closes connection, sends FIN.

Step 3: client receives FIN, replies with ACK. Enters timed wait - will respond with ACK to received FINs

Step 4: server, receives ACK. Connection closed.

Note:with small modification, can handle

simultaneous FINs.

TCP Connection Management (cont)TCP Connection Management (cont)

8/2/2019 chp3.ppt_0

100/220


TCP client

lifecycle

TCP server

lifecycle

State Transition DiagramState Transition Diagram(start)

8/2/2019 chp3.ppt_0

101/220


CLOSEDCLOSED

LISTENLISTEN

SYN_RCVDSYN_RCVD SYN_SENTSYN_SENT

ESTABLISHED

CLOSE_WAITCLOSE_WAIT

LAST_ACKLAST_ACKCLOSINGCLOSING

TIME_WAITTIME_WAIT

FIN_WAIT_2FIN_WAIT_2

FIN_WAIT_1FIN_WAIT_1

(Passive open)

SYN + ACK/ACKACK/-

Close/FIN

FIN/ACKClose/FIN

timed wait30,60.120 sec

FIN/ACK

ACK/-

ACK/-

Close /FIN

Close/-

Send/SYN

ACK+FIN/AC

K

SYN/SYN + ACK

FIN/ACK

ACK/-

CLOSEDCLOSED

Close/- (Active open)

Connect/SYN

(Passive

close)

(Activeclose)

(start)

(back to start)

Timeout/-

EVENT/ACTIONEVENT/ACTIONEVENT/ACTIONEVENT/ACTION

Open/-

Normal path for a clientNormal path for a client

Normal path for a serverNormal path for a server

Unusual eventUnusual event (Step 1 of the 3-way handshake)

RST/-

SYN/SYN + ACK(Step 2 of the 3-way handshake)

(Step 3 of the 3-way handshake)

CLOSED activi

TCP State There are several things that must beremembered about a connection. To

8/2/2019 chp3.ppt_0

102/220


LISTEN

SYN_RCVD

ESTABLISHED

CLOSING

TIME_WAIT

SYN_SENT

FIN_WAIT_1

CLOSE_WAIT

LAST_ACK

FIN_WAIT_2

iveopen,createTCB

sendSY

N

passive open,create TCB

sendSYN

receiveS

YN,

sendSYN,

ACK

receiv

e

RST

receiveACK receiveSYN,ACK,

sendACKapplic.

close,sendFIN

applic.

close,

sendF

IN

receiveFIN,sendACK

receive FIN

send ACK

receiveFIN,ACK

sendACKreceive

ACK

receive FIN

send ACK

receive

ACK

applic. close

sendFIN

receiveACK

applic. closeor timeout,delete TCB

2MSL timeoutdelete TCB

receive SYN,send ACK

applic.closediagram

store this information we imagine that

there is a data structure called a

Transmission Control Block (TCB).


8/2/2019 chp3.ppt_0

103/220



services



transport: UDP





flow control


3.6 Principles ofcongestion control 3.7 TCP congestion control



3.11 http modeling

Principles of Congestion ControlPrinciples of Congestion Control

8/2/2019 chp3.ppt_0

104/220


Congestion: too many sources sending too much data too fastfor networkto handle and competing for bottleneckbandwidth

Two common approaches:

rate-based: control rate of traffic (e.g., token bucket) window-based: limit number of unacknowledged packets

window size controls rate,

Flow control = prevents end-system buffer overflow

window-based control can be used for both.

source1

source2

source3

sink2

sink1

sink3

100Mbs100Mbps

100Mbps

10Mbps 100Mbps

10Mbps1.5Mbpsbottleneck

Congestion: A Close-up ViewCongestion: A Close-up View

8/2/2019 chp3.ppt_0

105/220


knee point after which throughput increases very slowly delay increases fast

cliff point after which

throughput starts to decreasevery fast to zero (congestioncollapse)

delay approaches infinity

Note (in an M/M/1 queue) delay = 1/(1 utilization)

Delay

Offered

Load

Throughput

knee cliff

congestion

collapse

packet

loss

Offered

Load

Congestion Control vs. Congestion AvoidanceCongestion Control vs. Congestion Avoidance

Congestion Control vs. Congestion AvoidanceCongestion Control vs. Congestion Avoidance

8/2/2019 chp3.ppt_0

106/220


Congestion control goal Stay left of cliff

Keeps network operating atfull capacity, but minimizespacket loss maximizegoodput

Congestion avoidance goal

stay left of knee Right of cliff:

Congestion collapse

Offered

Load

Throughput

knee cliff

congestion

collapse

packet

loss

Congestion CollapseCongestion Collapse

8/2/2019 chp3.ppt_0

107/220


Definition: Increase in network load results in decrease

ofuseful work done Many possible causes

Spurious retransmissions of packets still in flight

Undelivered packets

Packets consume resources and are dropped elsewhere in network

Fragments

Mismatch of transmission and retransmission units

Control traffic Large percentage of traffic is for control

Stale or unwanted packets

Packets that are delayed on long queues

Causes/Costs of Congestion: scenario 1Causes/Costs of Congestion: scenario 1

8/2/2019 chp3.ppt_0

108/220


Applications in A and B sending into connection at an

average rate ofin bytes/sec. Original" data: sent into the socket only once.

Simple transport protocol: no error recovery

(retransmission), flow control, or congestion control.

unlimited shared

output link buffers

Host A in: original datarate [B/s]

Host B

out

Shared link

R[B/s]

Causes/Costs of Congestion: scenario 1(cont)Causes/Costs of Congestion: scenario 1(cont)

8/2/2019 chp3.ppt_0

109/220


(a) Per-connection throughput.

[Byte/s]

[Byte/s]

out

(throughput)

in (offered load)R/2

R/2

(b) Per-connection delay.

[Byte/s]

[Byte/s]

D

elay(ms)


out = in out = R/2

Scenario 2: Two Sender, a Router with Finite BuffersScenario 2: Two Sender, a Router with Finite Buffers

8/2/2019 chp3.ppt_0

110/220


one router, finitebuffers

sender retransmission of lost packet

finite shared output link

buffers

Host A in : original data

Host B

outin: original data, plus

retransmitted data (offered loadto network)

Scenario 2: (cont)Scenario 2: (cont)

8/2/2019 chp3.ppt_0

111/220


Each connection is reliable. If a packet containing atransport-level segment is dropped at the router, itwill eventually be retransmitted by the sender.

in [Bytes/sec] = rate at which the application sends

original data into the socket.

in [Bytes/sec] = offered load to the network(containing original data orretransmitted data).

[Byte/s]

Scenario 2:Scenario 2: retransmission due to lost packetretransmission due to lost packet ((perfect retransmission)perfect retransmission)

8/2/2019 chp3.ppt_0

112/220


[Byte/s]

[Byte/s]


out

(throu

ghput)

R/2

R/3

R/4

Example: At in=R/2 --> out=R/3

in=R/2 = 0.333R Bytes/sec (on average) original data +

0.167R Bytes/sec (on average) retransmitted data.

Cost of a congested network: the sender must perform retransmissions inorder to compensate for dropped (lost) packets due to buffer overflow.

Scenario 2:Scenario 2: retransmission due to delayed (not lost) packetretransmission due to delayed (not lost) packet

8/2/2019 chp3.ppt_0

113/220


retransmission due to delayed (not lost) packet. Each

packet is assumed to be forwarded (on average) twice by

the router.

out

(throughput)


R/2

R/3

R/4

[Byte/s]

[Byte/s]

Scenario 2:Scenario 2: retransmission due to delayed (not lost) packetretransmission due to delayed (not lost) packet

8/2/2019 chp3.ppt_0

114/220


Sender timeouts and retransmit a packet that has beendelayed in the queue, but not yet lost.

Both the original data packet and the retransmission mayreach the receiver.The receiver will discard the retransmission.

The "work" done by the router in forwarding theretransmitted copy of the original packet was "wasted" as thereceiver will have already received the original copy of thispacket.

Cost of a congested network: unneeded retransmissions bythe sender in the face of large delays may cause a router touse its link bandwidth to forward unneeded copies of apacket.

8/2/2019 chp3.ppt_0

115/220

Causes/Costs of Congestion: scenario 3(Cont)Causes/Costs of Congestion: scenario 3(Cont)

8/2/2019 chp3.ppt_0

116/220


Extremely small

in: buffer overflows are rare, andout=in Larger in: , the overflows are still rare. Thus, an

increase in in results in an increase in out .

Causes/Costs of Congestion: scenario 3(Cont)Causes/Costs of Congestion: scenario 3(Cont)

8/2/2019 chp3.ppt_0

117/220


Extremely large in (and hence in): A-C traffic arriving to

R2 is at most R. If in is extremely large for all connections, then the arrival

rate of B-D traffic at R2 can be much larger than that of the

A-C traffic.

As the offered load approaches infinity, an empty buffer atR2 is immediately filled by a B-D packet, and the throughput

of the A-C connection at R2 goes to zero. When packet dropped (in R2), any upstream (R1) transmission

capacity used for that packet was wasted!

As the offered load approaches infinity, the throughput goes to

zero.

When packet dropped (in R2), any upstream (R1) transmission

capacity used for that packet was wasted!

As the offered load approaches infinity, the throughput goes to

zero.

Scenario 3 (cont)Scenario 3 (cont)

8/2/2019 chp3.ppt_0

118/220


[Byte/s]

[Byte/s]

out

(throughput)


R/2

A-C and B-D traffic compete at router R2 for the buffer, A-C

traffic that successfully gets through R2 becomes smaller and

smaller as the offered load from B-D gets larger and larger.

Host A

out

Host B

R1

chp3.ppt_0

Documents