end-to-end protocols (udp, tcp, connection management)

23
1 End-to-End Protocols (UDP, TCP, Connection Management)

Upload: steven-edwards

Post on 03-Jan-2016

33 views

Category:

Documents


2 download

DESCRIPTION

End-to-End Protocols (UDP, TCP, Connection Management). Demultiplexing: delivering received segments to correct app layer processes. Multiplexing/demultiplexing. 32 bits. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: End-to-End Protocols (UDP, TCP, Connection Management)

1

End-to-End Protocols(UDP, TCP, Connection Management)

Page 2: End-to-End Protocols (UDP, TCP, Connection Management)

2

Multiplexing/demultiplexing

Multiplexing: gathering data from multiple app processes, enveloping data with header (later used for demultiplexing)

source port # dest port #

32 bits

applicationdata

(message)

other header fields

TCP/UDP segment format

Demultiplexing: delivering received segments to correct app layer processes

Page 3: End-to-End Protocols (UDP, TCP, Connection Management)

3

Multiplexing/demultiplexing: Example

Web clienthost A

Webserver B

Web clienthost C

Source IP: CDest IP: B

source port: x

dest. port: 80

Source IP: CDest IP: B

source port: y

dest. port: 80

Web server

Source IP: ADest IP: B

source port: x

dest. port: 80

Page 4: End-to-End Protocols (UDP, TCP, Connection Management)

4

UDP: User Datagram Protocol [RFC 768]

Often used for streaming multimedia apps loss tolerant rate sensitive

Other UDP uses DNS SNMP

Reliable transfer over UDP: add reliability at application layer application-specific

error recover!

source port # dest port #

32 bits

Applicationdata

(message)

UDP segment format

length checksumLength, in

bytes of UDPsegment,including

header

Page 5: End-to-End Protocols (UDP, TCP, Connection Management)

5

UDP Checksum

Sender: treat segment contents

as sequence of 16-bit integers

checksum: addition (1’s complement sum) of segment contents

sender puts checksum value into UDP checksum field

Receiver: compute checksum of

received segment check if computed checksum

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

But maybe errors nonethless? More later ….

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

Page 6: End-to-End Protocols (UDP, TCP, Connection Management)

6

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

A sliding window protocol providing reliable, in-order byte steam: no “message

boundaries” Flow controlled:

set window size according to the buffer size at the receiver

Congestion controlled set window size

according to the status of the network

End-to-end full duplex data transfer: one sender, one receiver bi-directional data flow

using the same connection

MSS: maximum segment size

Connection-oriented: Connection management

socketdoor

T C Psend buffer

T C Preceive buffer

socketdoor

segm ent

applicationwrites data

applicationreads data

Page 7: End-to-End Protocols (UDP, TCP, Connection Management)

7

TCP Segment Structure

source port # dest port #

32 bits

applicationdata

(variable length)

sequence number

acknowledgement numberrcvr window size

ptr urgent datachecksum

FSRPAUheadlen

notused

Options (variable length)RST, SYN, FIN:connection

management(reset, setup

teardowncommands)

# bytes rcvr willingto accept

ACK: ACK #valid

countingby bytes of data(not segments!)

Also in UDP

URG: urgent data (generally not used)

PSH: push data now(generally not used)

Page 8: End-to-End Protocols (UDP, TCP, Connection Management)

8

TCP Terminology: Seq. #’s and ACKs

Seq. #’s: byte stream

seq# of the first byte of a segment

ACKs: seq# of the next

byte expected from other side

cumulative ACK

If no data to send:Use the seq# of the next byte.

Host A Host B

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

Seq=43, ACK=80

Usertypes

‘C’

host ACKsreceipt

of echoed‘C’

host ACKsreceipt of

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

timesimple telnet scenario

Seq=80, ACK=43, data = ‘X’

Seq=43, ACK=81

Assume Host BSends data ‘x’Back to Host A

host ACKsReceipt

of echoed‘x’

Page 9: End-to-End Protocols (UDP, TCP, Connection Management)

9

Connection Management: Setup

The previous protocols assume we start with sequence number 0. Is there any problem with this approach?

The objectives of connection setup agree on initial sequence numbers agree on other initial parameters

Page 10: End-to-End Protocols (UDP, TCP, Connection Management)

10

Three Way Handshake (TWH) [Tomlinson 1975]

Host A

SYN(seq=x)

Host B

ACK(seq=x+1), SYN(seq=y)

ACK(seq=y+1)

DATA(seq=x+1)

SYN: indicates connection setup

Page 11: End-to-End Protocols (UDP, TCP, Connection Management)

11

Scenarios with Duplicate Request

Host A Host B

ACK(seq=x+1), SYN(seq=y)

REJECT(seq=y+1)

SYN(seq=x)

accept?

no suchrequest

reject

Page 12: End-to-End Protocols (UDP, TCP, Connection Management)

12

Scenarios with Duplicate Request/Reply

Host A Host B

ACK(seq=x+1), SYN(seq=y)

REJECT(seq=y+1)

SYN(seq=x)

accept?

no suchrequest

reject

ACK(seq=z)

Page 13: End-to-End Protocols (UDP, TCP, Connection Management)

13

Connection Management: Close

FIN: indicates connection close

Host A Host B

FIN

DATA

DATA

no data is deliveredafter FIN

Page 14: End-to-End Protocols (UDP, TCP, Connection Management)

14

The First Attempt: Agreeing on Connection Close

client

I am done. Are you done too?

server

I am done too. Goodbye!

init. close

close

close

Is this approach right?

Page 15: End-to-End Protocols (UDP, TCP, Connection Management)

15

Four Way Teardown

Host A

FIN

Host B

ACK

ACK

FIN

close

close

closed

tim

ed w

ait

Page 16: End-to-End Protocols (UDP, TCP, Connection Management)

16

%netstat --tcp -a CLOSED

LISTEN

SYN RCVD

SYN

SYN/ACK

ACK

CLOSED

SYN SENT

ESTABLSIHED

ESTABLSIHED

FIN

ACK

ACK

FINWAIT 1

ESTABLSIHED ESTABLSIHED

CLOSEWAIT

FINLASTACK

FINWAIT 2

TIMEWAIT

Page 17: End-to-End Protocols (UDP, TCP, Connection Management)

17

00 sendbase = initial_sequence number agreed by TWH01 nextseqnum = initial_sequence number by TWH

02 loop (forever) { 03 switch(event) 04 event: data received from application above05 if (window allow send)06 create TCP segment with sequence number nextseqnum06 start timer for segment nextseqnum 07 pass segment to IP08 nextseqnum = nextseqnum + length(data)

else put packet in buffer09 event: timer timeout for segment with sequence number y 10 retransmit segment with sequence number y 11 compute new timeout interval for segment y 12 restart timer for sequence number y13 event: ACK received, with ACK field value of y 14 if (y > sendbase) { /* cumulative ACK of all data up to y */ 15 cancel all timers for segments with sequence numbers < y 16 sendbase = y17 while (there are segments and window allow)18 sent a segment as in line 04;18 } 19 else { /* y==sendbase, duplicate ACK for already ACKed segment */ 20 increment number of duplicate ACKs received for y 21 if (number of duplicate ACKS received for y == 3) { 22 /* TCP fast retransmit */ 23 resend segment with sequence number y 24 restart timer for segment y 25 } 26 } /* end of loop forever */

TCP: reliable data transfer

SimplifiedTCPsender

Page 18: End-to-End Protocols (UDP, TCP, Connection Management)

18

TCP Receiver: ACK Generation [RFC 1122, RFC 2581]

Event

in-order segment arrival, no gaps,everything else already ACKed

in-order segment arrival, no gaps,one delayed ACK pending

out-of-order segment arrivalhigher-than-expect seq. #gap detected

arrival of segment that partially or completely fills gap

TCP Receiver action

delayed ACK. Wait up to 500msfor next segment. If no next segment,send ACK (this called delayed ACK)

immediately send singlecumulative ACK

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

immediate ACK if segment startsat lower end of gap

Discussion: Why delayed ACKs?

Page 19: End-to-End Protocols (UDP, TCP, Connection Management)

19

TCP: Retransmission Scenarios

Host A

Seq=92, 8 bytes data

ACK=100

loss

tim

eout

time lost ACK scenario

Host B

X

Seq=92, 8 bytes data

ACK=100

Host A

Seq=100, 20 bytes data

ACK=100

Seq=

92

tim

eout

premature timeout,cumulative ACKs

Host B

Seq=92, 8 bytes data

ACK=120

Seq=92, 8 bytes data

Seq=

10

0 t

imeou

t

ACK=120

Page 20: End-to-End Protocols (UDP, TCP, Connection Management)

20

TCP Timeout

Q: how to set TCP timeout value?

too short: premature timeout unnecessary

retransmissions too long: slow reaction

to segment loss even worse: RTT

fluctuates

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

segment transmission until ACK receipt ignore retransmissions,

cumulatively ACKed segments

SampleRTT will vary, want a “smoother” estimated RTT use several recent

measurements, not just current SampleRTT

Using the average of SampleRTT will generate many timeouts due to network variations consider variance as well

RTT

RTT

freq.

Page 21: End-to-End Protocols (UDP, TCP, Connection Management)

21

TCP Timeout: Initial Timeout

EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT exponential weighted moving average influence of given sample decreases exponentially fast typical value of x: 0.125

Estimate the variance of RTT

Timeout = EstimatedRTT + 4*Deviation

Deviation = (1-x)*Deviation + x*|SampleRTT-EstimatedRTT|

Estimate the average of RTT

Set initial timeout value

Page 22: End-to-End Protocols (UDP, TCP, Connection Management)

22

An Example of Initial Timeout

timeout value

per packet round-trip time

Page 23: End-to-End Protocols (UDP, TCP, Connection Management)

23

TCP Timeout: Repeated Retransmission

Exponential backoff: Double timeout value after each retransmission Max 64 seconds Max 12 restransmits Discussion: why exponential backoff?