CSE 3214: Computer Networks Protocols and Applications€¦ · Transport vs. network layer n network layer: logical communication between hosts n transport layer: logical communication

2/9/2017 CSE 3214 - S.Datta 1

CSE 3214: Computer NetworksProtocols and Applications

Suprakash [email protected]

Office: CSEB 3043Phone: 416-736-2100 ext 77875

Course page: http://www.cse.yorku.ca/course/3214

These slides are adapted from Jim Kurose’s slides.

mailto:[email protected]

2/9/2017 CSE 3214 - S.Datta 2

Next

n The transport layer

2/9/2017 CSE 3214 - S.Datta 3

Chapter 3: Transport Layer

Our goals:n understand principles

behind transport layerservices:n multiplexing/demultiplex-

ingn reliable data transfern flow controln congestion control

n learn about transport layerprotocols in the Internet:n UDP: connectionless

transportn TCP: connection-oriented

transportn TCP congestion control

2/9/2017 CSE 3214 - S.Datta 4

Chapter 3 outline

n 3.1 Transport-layerservices

n 3.2 Multiplexing anddemultiplexing

n 3.3 Connectionlesstransport: UDP

n 3.4 Principles of reliabledata transfer

- LEAVE OUT

n 3.5 Connection-orientedtransport: TCPn segment structuren reliable data transfern flow controln connection management

n 3.6 Principles ofcongestion control

n 3.7 TCP congestioncontrol

2/9/2017 CSE 3214 - S.Datta 5

Transport services and protocols

n provide logical communicationbetween app processesrunning on different hosts

n transport protocols run in endsystemsn send side: breaks app

messages into segments,passes to network layer

n rcv side: reassemblessegments into messages,passes to app layer

n more than one transportprotocol available to appsn Internet: TCP and UDP

applicationtransportnetworkdata linkphysical


networkdata linkphysical



networkdata linkphysicalnetwork

data linkphysicallogical end-end

transport

2/9/2017 CSE 3214 - S.Datta 6

Transport vs. network layer

n network layer: logicalcommunication between hosts

n transport layer: logicalcommunication betweenprocessesn relies on, enhances, network

layer services

Household analogy:12 kids sending letters to 12

kidsn processes = kidsn app messages = letters in

envelopesn hosts = housesn transport protocol = Ann and

Billn network-layer protocol =

postal service

2/9/2017 CSE 3214 - S.Datta 7

Internet transport-layer protocols

n reliable, in-order delivery(TCP)n congestion controln flow controln connection setup

n unreliable, unordered delivery:UDPn no-frills extension of “best-

effort” IPn services not available:

n delay guaranteesn bandwidth guarantees






networkdata linkphysicalnetwork

data linkphysicallogical end-end

transport

2/9/2017 CSE 3214 - S.Datta 8

Chapter 3 outline








2/9/2017 CSE 3214 - S.Datta 9

Multiplexing/demultiplexing

application

transport

network

link

physical

P1 application

transport

network

link

physical

application

transport

network

link

physical

P2P3 P4P1

host 1 host 2 host 3

= process= socket

delivering received segmentsto correct socket

Demultiplexing at rcv host:gathering data from multiplesockets, enveloping data withheader (later used fordemultiplexing)

Multiplexing at send host:

2/9/2017 CSE 3214 - S.Datta 10

How demultiplexing works

n host receives IP datagramsn each datagram has source IP

address, destination IPaddress

n each datagram carries 1transport-layer segment

n each segment has source,destination port number(recall: well-known portnumbers for specificapplications)

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

source port # dest port #

32 bits

applicationdata

(message)

other header fields

TCP/UDP segment format

2/9/2017 CSE 3214 - S.Datta 11

Connectionless demultiplexing

n Create sockets with port numbers:DatagramSocket mySocket1 = new

DatagramSocket(99111);DatagramSocket mySocket2 = new

DatagramSocket(99222);n UDP socket identified by two-tuple:(dest IP address, dest port number)

n When host receives UDPsegment:n checks destination port

number in segmentn directs UDP segment to

socket with that port numbern IP datagrams with

different source IPaddresses and/or sourceport numbers directed tosame socket

2/9/2017 CSE 3214 - S.Datta 12

Connectionless demux (cont)

DatagramSocket serverSocket = new DatagramSocket(6428);

ClientIP:B

P2

client IP: A

P1P1P3

serverIP: C

SP:6428DP:9157

SP:9157DP:6428

SP:6428DP:5775

SP:5775DP:6428

SP provides “return address”

2/9/2017 CSE 3214 - S.Datta 13

Connection-oriented demux

n TCP socket identified by4-tuple:n source IP addressn source port numbern dest IP addressn dest port number

n recv host uses all four valuesto direct segment toappropriate socket

n Server host may support manysimultaneous TCP sockets:n each socket identified by its

own 4-tuplen Web servers have different

sockets for each connectingclientn non-persistent HTTP will have

different socket for eachrequest

2/9/2017 CSE 3214 - S.Datta 14

Connection-oriented demux (cont)

ClientIP:B

P1

client IP: A

P1P2P4

serverIP: C

SP: 9157DP: 80

SP:9157

DP: 80

P5

P6 P3

D-IP:CS-IP: AD-IP:C

S-IP: B

SP:5775

DP: 80

D-IP:CS-IP: B

2/9/2017 CSE 3214 - S.Datta 15

Connection-oriented demux: Threaded Web Server

ClientIP:B

P1

client IP: A

P1P2

serverIP: C

SP: 9157DP: 80

SP:9157

DP: 80

P4 P3

D-IP:CS-IP: AD-IP:C

S-IP: B

SP:5775

DP: 80

D-IP:CS-IP: B

2/9/2017 CSE 3214 - S.Datta 16

Chapter 3 outline








2/9/2017 CSE 3214 - S.Datta 17

UDP: User Datagram Protocol [RFC 768]

n “no frills,” “bare bones”Internet transport protocol

n “best effort” service, UDPsegments may be:n lostn delivered out of order to

appn connectionless:

n no handshaking betweenUDP sender, receiver

n each UDP segmenthandled independently ofothers

Why is there a UDP?n no connection establishment

(which can add delay)n simple: no connection state

at sender, receivern small segment headern no congestion control: UDP

can blast away as fast asdesired

2/9/2017 CSE 3214 - S.Datta 18

UDP: more

n often used for streamingmultimedia appsn loss tolerantn rate sensitive

n other UDP usesn DNSn SNMP

n reliable transfer over UDP:add reliability at applicationlayern application-specific error

recovery!


32 bits

Applicationdata

(message)

UDP segment format

length checksumLength, in

bytes of UDPsegment,including

header

2/9/2017 CSE 3214 - S.Datta 19

UDP checksum

Sender:n treat segment contents

as sequence of 16-bitintegers

n checksum: addition (1’scomplement sum) ofsegment contents

n sender puts checksumvalue into UDPchecksum field

Receiver:n compute checksum of received

segmentn check if computed checksum

equals checksum field value:n NO - error detectedn YES - no error detected.

But maybe errorsnonetheless?

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

2/9/2017 CSE 3214 - S.Datta 20

Internet Checksum Example

n Noten When adding numbers, a carryout from the most significant

bit needs to be added to the resultn Example: add two 16-bit integers

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 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 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

wraparound

sumchecksum

2/9/2017 CSE 3214 - S.Datta 21

Chapter 3 outline








2/9/2017 CSE 3214 - S.Datta 22

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

n full duplex data:n bi-directional data flow in

same connectionn MSS: maximum segment

sizen connection-oriented:

n handshaking (exchange ofcontrol msgs) init’s sender,receiver state before dataexchange

n flow controlled:n sender will not overwhelm

receiver

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

n reliable, in-order byte steam:n no “message boundaries”

n pipelined:n TCP congestion and flow

control set window sizen send & receive buffers

2/9/2017 CSE 3214 - S.Datta 23

TCP segment structure


32bits

applicationdata

(variable length)

sequence numberacknowledgement number

Receive windowUrg data pnterchecksum

FSRPAUheadlen

notused

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)

# bytesrcvr willingto accept

countingby bytesof data(not segments!)

Internetchecksum

(as in UDP)

2/9/2017 CSE 3214 - S.Datta 24

TCP seq. #’s and ACKs

Seq. #’s:n byte stream “number”

of first byte insegment’s data

ACKs:n seq # of next byte

expected from otherside

n cumulative ACKQ: how receiver handles out-

of-order segmentsn A: TCP spec doesn’t

say, - up toimplementor

Host A Host B

Seq=42, ACK=79, data = ‘C’

Seq=79, ACK=43, data = ‘C’

Seq=43, ACK=80

Usertypes

‘C’

host ACKsreceipt

of echoed‘C’

host ACKsreceipt of‘C’, echoes

back ‘C’

timesimple telnet scenario

2/9/2017 CSE 3214 - S.Datta 25

TCP Round Trip Time and Timeout

Q: how to set TCP timeoutvalue?

n longer than RTTn but RTT varies

n too short: prematuretimeoutn unnecessary

retransmissionsn too long: slow reaction to

segment loss

Q: how to estimate RTT?n SampleRTT: measured time from

segment transmission until ACKreceiptn ignore retransmissions

n SampleRTT will vary, want estimatedRTT “smoother”n average several recent

measurements, not just currentSampleRTT

2/9/2017 CSE 3214 - S.Datta 26


EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT

n Exponential weighted moving averagen influence of past sample decreases exponentially fastn typical value: = 0.125

2/9/2017 CSE 3214 - S.Datta 27

Example RTT estimation:

2/9/2017 CSE 3214 - S.Datta 28


Setting the timeoutn EstimtedRTT plus “safety margin”

n large variation in EstimatedRTT -> larger safety marginn first estimate of how much SampleRTT deviates from EstimatedRTT:

TimeoutInterval = EstimatedRTT + 4*DevRTT

DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|(typically, = 0.25)

Then set timeout interval:

2/9/2017 CSE 3214 - S.Datta 29

Chapter 3 outline

n 3.1 Transport-layer servicesn 3.2 Multiplexing and

demultiplexingn 3.3 Connectionless transport:

UDPn 3.4 Principles of reliable data

transfer


n 3.6 Principles of congestioncontrol

n 3.7 TCP congestion control

2/9/2017 CSE 3214 - S.Datta 30

TCP reliable data transfer

n TCP creates rdt service on topof IP’s unreliable service

n Pipelined segmentsn Cumulative acksn TCP uses single retransmission

timer

n Retransmissions are triggeredby:n timeout eventsn duplicate acks

n Initially consider simplified TCPsender:n ignore duplicate acksn ignore flow control, congestion

control

2/9/2017 CSE 3214 - S.Datta 31

TCP sender events:

data rcvd from app:n Create segment with seq #n seq # is byte-stream number

of first data byte in segmentn start timer if not already

running (think of timer as foroldest unacked segment)

n expiration interval:TimeOutInterval

timeout:n retransmit segment that

caused timeoutn restart timer Ack rcvd:n If acknowledges previously

unacked segmentsn update what is known to be

ackedn start timer if there are

outstanding segments

2/9/2017 CSE 3214 - S.Datta 32

TCPsender

(simplified)

NextSeqNum = InitialSeqNum SendBase = InitialSeqNum

loop (forever) { switch(event)

event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data)

event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer

event: ACK received, with ACK field value of y if (y >= SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer }

} /* end of loop forever */

Comment:• SendBase-1: lastcumulativelyack’ed byteExample:• SendBase-1 = 71;y= 73, so the rcvrwants 73+ ;y > SendBase, sothat new data isacked

2/9/2017 CSE 3214 - S.Datta 33

TCP: retransmission scenarios

Host A

Seq=100, 20 bytes data

ACK=100

timepremature timeout

Host B


ACK=120


Seq=

92ti

meo

ut

ACK=120

HostA

Seq=92, 8 bytesdata

ACK=100

loss

tim

e-ou

t

lost ACK scenario

HostB

X

Seq=92, 8 bytesdata

ACK=100

time

Seq=

92 t

imeo

utSendBase

= 100

SendBase= 120

SendBase= 120

Sendbase= 100

2/9/2017 CSE 3214 - S.Datta 34

TCP retransmission scenarios (more)

HostA

Seq=92, 8 bytesdata

ACK=100

loss

tim

e-ou

t

Cumulative ACK scenario

HostB

XSeq=100, 20 bytesdata

ACK=120

time

SendBase= 120

2/9/2017 CSE 3214 - S.Datta 35

TCP ACK generation [RFC 1122, RFC 2581]

Event at Receiver

Arrival of in-order segment withexpected seq #. All data up toexpected seq # already ACKed

Arrival of in-order segment withexpected seq #. One othersegment has ACK pending

Arrival of out-of-order segmenthigher-than-expect seq. # .Gap detected

Arrival of segment thatpartially or completely fills gap

TCP Receiver action

Delayed ACK. Wait up to 500msfor next segment. If no next segment,send ACK

Immediately send single cumulativeACK, ACKing both in-order segments

Immediately send duplicate ACK,indicating seq. # of next expected byte

Immediate send ACK, provided thatsegment starts at lower end of gap

2/9/2017 CSE 3214 - S.Datta 36

Fast Retransmit

n Time-out period often relativelylong:n long delay before resending

lost packetn Detect lost segments via

duplicate ACKs.n Sender often sends many

segments back-to-backn If segment is lost, there will

likely be many duplicate ACKs.

n If sender receives 3 ACKs forthe same data, it supposesthat segment after ACKeddata was lost:n fast retransmit: resend

segment before timer expires

2/9/2017 CSE 3214 - S.Datta 37

event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y }

Fast retransmit algorithm:

a duplicate ACK foralready ACKed segment

fast retransmit

2/9/2017 CSE 3214 - S.Datta 38

Chapter 3 outline




transfer




2/9/2017 CSE 3214 - S.Datta 39

TCP Flow Control

n receive side of TCP connectionhas a receive buffer:

n speed-matching service:matching the send rate tothe receiving app’s drain rate

n app process may be slow atreading from buffer

sender won’t overflowreceiver’s buffer by

transmitting toomuch,

too fast

flow control

2/9/2017 CSE 3214 - S.Datta 40

TCP Flow control: how it works

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

n spare room in buffer= RcvWindow= RcvBuffer-[LastByteRcvd -

LastByteRead]

n Rcvr advertises spare roomby including value ofRcvWindow in segments

n Sender limits unACKed datato RcvWindown guarantees receive buffer

doesn’t overflow

2/9/2017 CSE 3214 - S.Datta 41

Chapter 3 outline




transfer




2/9/2017 CSE 3214 - S.Datta 42

TCP Connection Management

Recall: TCP sender, receiverestablish “connection” beforeexchanging data segments

n initialize TCP variables:n seq. #sn buffers, flow control info

(e.g. RcvWindow)n client: connection initiator Socket clientSocket = new

Socket("hostname","portnumber");

n server: contacted by client Socket connectionSocket =

welcomeSocket.accept();

Three way handshake:Step 1: client host sends TCP

SYN segment to servern specifies initial seq #n no data

Step 2: server host receives SYN,replies with SYNACK segmentn server allocates buffersn specifies server initial seq. #

Step 3: client receives SYNACK,replies with ACK segment,which may contain data

2/9/2017 CSE 3214 - S.Datta 43

TCP Connection Management (cont.)

Closing a connection:

client closes socket:clientSocket.close();

Step 1: client end system sendsTCP FIN control segment toserver

Step 2: server receives FIN,replies with ACK. Closesconnection, sends FIN.

client

FIN

server

ACK

ACK

FIN

close

close

closed

tim

ed w

ait

2/9/2017 CSE 3214 - S.Datta 44

TCP Connection Management (cont.)

Step 3: client receives FIN,replies with ACK.

n Enters “timed wait” - willrespond with ACK toreceived FINs

Step 4: server, receives ACK.Connection closed.

Note: with small modification,can handle simultaneous FINs.

client

FIN

server

ACK

ACK

FIN

closing

closing

closed

tim

ed w

ait

closed

2/9/2017 CSE 3214 - S.Datta 45

TCP Connection Management (cont)

TCP clientlifecycle

TCP serverlifecycle

Documents

CSE 3214: Computer Networks Protocols and Applications€¦ · Transport vs. network layer n network layer: logical communication between hosts n transport layer: logical communication