1 Week 10 Transport Protocols, UDP, TCP. 2 Orientation r We move one layer up and look at the...

1

Week 10Transport Protocols, UDP, TCP

2

Orientation We move one layer up and look at the transport layer across the

Internet.

ApplicationLayer

IPLayer

Network protocols

IP

e.g., Ethernet

Media

TransportLayer

TCP UDP

User Process

User Process

User Process

User Process

3

Orientation TCP and UDP are end-to-end protocols

They are only implemented at the hosts

Application

TCP/UDP

IP

HOST

Network 1protocols

Network 1protocols

Network 2protocols

IP

Application

TCP/UDP

IP

HOST

Network 2protocols

IP Router

4

Transport Protocols in the Internet

UDP - User Datagram UDP - User Datagram

ProtocolProtocol

datagram oriented

unreliable, connectionless

simple

unicast and multicast

useful for multimedia applications

used for control protocols network management

(SNMP), routing (RIP), naming (DNS), etc.

TCP - Transmission Control Protocol

stream oriented

reliable, connection-oriented

complex

only unicast

used for data applications: web (http), email (smtp),

file transfer (ftp), SecureCRT, etc.

• The Internet supports 2 transport protocols

5

UDP - User Datagram Protocol

UDP extends the host-to-to-host delivery service of IP to an application process-to-application process delivery service

It does this by multiplexing and demultiplexing packets from multiple application-to-application communication sessions

UDP

IP IPIP

routerIP

routerIP

router

UDP

Applications Applications

6

UDP packet formatIP header UDP header UDP data (payload)

UDP message length Checksum

20 bytes 8 bytes

0 15 16 31

Source Port Number Destination Port Number

• Port numbers identify sending and receiving applications (processes). Maximum port number is 216-1= 65,535

• Message Length is between 8 bytes (i.e., data field can be empty) and 65,535 bytes (length of UDP header and data in bytes)

• Checksum is for UDP header and UDP data

7

Port Numbers UDP (and TCP) use port numbers to identify applications

There are 65,535 UDP ports per host.

IP

TCP UDP

User Process

Demultiplex

based on

Protocol field in IP

header

User Process

User Process

User Process

User Process

User Process

Demultiplex

based on

port number

8

TCP

Service offered by TCP

TCP Header

TCP Connection Establishment and Termination

Flow control

Error control

Congestion control

9

TCP = Transmission Control Protocol Provides a reliable unicast end-to-end

byte stream over an unreliable internetwork.

TCP

IP Internetwork

Byt

e S

trea

m

Byt

e S

trea

m

TCP

10

TCP is reliable

• Byte stream is broken up into chunks which are called

segments

• Detecting errors:• TCP has checksums for header and data. Segments with

invalid checksums are discarded

• Each segment that is transmitted has a sequence number.

• Receiver sends acknowledgments (ACKs) for segments

• Sender maintains a timer. An ACK is expected before the

timer times out

• Correcting errors:• Lost or errored segments are retransmitted.

• Selective repeat ARQ scheme

• Cumulative ACKs

11

Byte Stream Service

To the lower layers, TCP handles data in "segments"

To the higher layers TCP handles data as a sequence of bytes and does not identify boundaries between bytes

So: Higher layers do not know about the beginning and end of segments !

TCP

Application

1. write 100 bytes2. write 20 bytes

queue ofbytes to betransmitted TCP

queue ofbytes thathave beenreceived

Application1. read 40 bytes2. read 40 bytes3. read 40 bytes

Segments

12

TCP


TCP Header


Flow control

Error control

Congestion control

13

TCP Format

IP header TCP header TCP data

Sequence number (32 bits)

DATA (optional)

20 bytes 20 bytes

0 15 16 31

Source Port Number Destination Port Number

Acknowledgment number (32 bits)

window sizeheader length

0 Flags

Options (if any)

TCP checksum urgent pointer

20 bytes4 bits

6 bits

• TCP segments have a 20 byte plus options header with >= 0 data bytes

reserved

14

TCP header fields - Port Numbers Port Number:

• A port number identifies the endpoint of a connection.

• A pair <IP address, port number> identifies one endpoint of a connection.

• Two pairs <client IP address, client port number> and <server IP address, server port number> identify a TCP connection.

TCP

IP

Applications

23 10480Ports:

TCP

IP

Applications

7 1680 Ports:

15

TCP header fields - Sequence Number Sequence Number (SeqNo):

Sequence number is 32 bits long.

So the range of SeqNo is

0 <= SeqNo <= 232 -1 4.3 Gbyte

Each sequence number identifies the byte in the stream of data from the sending TCP to the receiving TCP that the first byte of data in this segment represents.

Initial Sequence Number (ISN) of a connection is set during connection establishment

Segment 1(Seq. No. 1)



1 500 501 1000 1001 1500

16

TCP header fields - Ack. No. Acknowledgment Number (AckNo):

Acknowledgments are piggybacked, i.e.,

a segment from A B contains an acknowledgement for a segment sent in the B A direction

The AckNo in the B A segment header contains the SeqNo for the next segment expected at B for the A B flow

Example: The acknowledgment for a 1500-byte segment with the sequence number 0 is AckNo=1500

A host uses the AckNo field to send acknowledgements.

If a host sends an AckNo in a segment it sets the “ACK flag”

17

TCP header fields - Ack. No. Contd. Example:

Sender sends two segments with bytes “1..1500” and “1501..3000”, but receiver only gets the second segment.

• What is the sequence number of the first segment?

• What is the sequence number of the second segment?

• What is the ACK number sent in response by the receiver when it receives the second segment?

18

TCP header fields - Header Length Header Length (4 bits):

Length of header in 32-bit words

Note that TCP header has variable length (minimum of 20 bytes)

19

TCP header fields - Flags Flag bits:

URG: Urgent pointer is valid

– If the bit is set, the following bytes contain an urgent message in the range:

SeqNo <= urgent message <= SeqNo+urgent

pointer

ACK: Acknowledgement Number is valid

PSH: PUSH Flag

– Notification from sender to the receiver that the receiver should pass all data that it has to the application as soon as possible.

– Normally set by sender when the sender’s buffer is empty (so TCP does not wait expecting more data)

20

TCP header fields - Flags Contd. Flag bits:

RST: Reset the connection

– The flag causes the receiver to reset the connection

– Receiver of a RST terminates the connection and indicates higher layer application about the reset

SYN: Synchronize sequence numbers

– Sent in the first packet when opening a connection

FIN: Sender is finished with sending

– Used for closing a connection

– Both sides of a connection must send a FIN

21

TCP header fields

Window Size: Each side of the connection advertises its receiving

window size

Window size is the maximum number of bytes that a receiver can accept.

Maximum window size is 216-1= 65535 bytes

TCP Checksum: TCP checksum covers both TCP header and TCP data

Urgent Pointer: Only valid if URG flag is set

22

TCP header fields - Options

Options - a few examples:

End ofOptions kind=0

1 byte

NOP(no operation) kind=1

1 byte

Maximum Segment Size kind=2

1 byte

len=4

1 byte

maximum segment size

2 bytes

23

TCP header fields

Options: NOP is used to pad TCP header to a

multiple of 4 bytes

Maximum Segment Size:• Sets the maximum length of the segments

• This option can only appear in a SYN segment

24

TCP


TCP Header


Flow control

Error control

Congestion control

25

Connection Management in TCP

Opening a TCP Connection

Closing a TCP Connection

Special Scenarios

State Diagram

26

TCP Connection Establishment TCP uses a three-way handshake to open a connection:

(1) ACTIVE OPEN: Client sends a segment with– SYN bit set

– port number of client, port number of server

– initial sequence number (ISN) of client

(2) PASSIVE OPEN: Server responds with a segment with– SYN bit set

– initial sequence number of server

– ACK for ISN of client

(3) Client acknowledges by sending a segment with:

– ACK ISN of server

27

Three-Way Handshake

aida.poly.edu mng.poly.edu

SYN (SeqNo = x)

SYN (SeqNo = y, AckNo = x + 1 )

ack (y + 1 )

28

A Closer Look with tcpdump

1 aida.poly.edu.1121 > mng.poly.edu.telnet: S 1031880193:1031880193(0)

win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp>

2 mng.poly.edu.telnet > aida.poly.edu.1121: S 172488586:172488586(0) ack 1031880194 win 8760 <mss 1460>

3 aida.poly.edu.1121 > mng.poly.edu.telnet: . ack 172488587 win 17520

4 aida.poly.edu.1121 > mng.poly.edu.telnet: P 1031880194:1031880218(24) ack 172488587 win 17520

5 mng.poly.edu.telnet > aida.poly.edu.1121: P 172488587:172488590(3) ack 1031880218 win 8736

6 aida.poly.edu.1121 > mng.poly.edu.telnet: P 1031880218:1031880221(3) ack 172488590 win 17520


aida issuesa "telnet mng"

29

Three-Way Handshake


S 1031880193:1031880193(0)win 16384 <mss 1460, ...>

S 172488586:172488586(0)

ack 1031880194 win 8760 <mss 1460>

ack 172488587 win 17520

30

First data segment sequence number Note that the data segment following

the three-way handshake will start with the sequence number following that of the SYN segment

31

Why to start with a new ISN

The problem with starting off each connection with a sequence number of 1 is that it introduces the possibility of segments from different connections getting mixed up.

Traditionally, each device chose the ISN by making use of a timed counter, like a clock of sorts, that was incremented every 4 microseconds. This counter was initialized when TCP started up and then its value increased by 1 every 4 microseconds until it reached the largest 32-bit value possible (4,294,967,295) at which point it “wrapped around” to 0 and resumed incrementing.

Period: 4 hours

32

TCP Connection Termination

Each end of the data flow must be shut down independently (“half-close”)

If one end is done it sends a FIN segment. This means that no more data will be sent

Four steps involved:(1) X sends a FIN to Y (active close)

(2) Y ACKs the FIN,

(at this time: Y can still send data to X)

(3) and Y sends a FIN to X (passive close)

(4) X ACKs the FIN.

33

Connection termination with tcpdump

1 mng.poly.edu.telnet > aida.poly.edu.1121: F 172488734:172488734(0)

ack 1031880221 win 8733

2 aida.poly.edu.1121 > mng.poly.edu.telnet: . ack 172488735 win 17484

3 aida.poly.edu.1121 > mng.poly.edu.telnet: F 1031880221:1031880221(0) ack 172488735 win 17520

4 mng.poly.edu.telnet > aida.poly.edu.1121: . ack 1031880222 win 8733


34

TCP Connection Termination


F 172488734:172488734(0)

ack 1031880221 win 8733

. ack 172488735 win 17484

. ack 1031880222 win 8733

F 1031880221:1031880221(0)ack 172488735 win 17520

35

TCP Half-close

FIN

ACK of FIN

DATA

ACK of DATA

FIN

ACK of FIN

36

MSS

A B

CMTU = 296

MTU = 1500

SYN <mss 1460>

SYN <mss 256>

Default is generally 536 bytes

37

Difference between TCP connections and connections in a connection-oriented network TCP “connections” are not the same as

connections in a connection-oriented network

In a connection-oriented network, a signaling procedure is used to reserve bandwidth for the connection on every link of the end-to-end path (e.g., circuit-switched networks)

A TCP connection involves the maintenance of state information at the end hosts Purpose is to provide error correction for TCP segments

Initial sequence number exchanged to avoid accidentally sending data to an old connection

38

TCP


TCP Header


Flow control

Error control

Congestion control

39

TCP flow control• Flow Control: How to prevent the sender

from overrunning the receiver buffer?

•Flow Control in TCP

• TCP implements sliding window flow control

• Window size is usually sent within acknowledgements.

40

Window Management in TCP The receiver returns two parameters to the sender in an

ACK

The interpretation is:• I am ready to receive new data with

SeqNo= AckNo, AckNo+1, …., AckNo+Win-1

Receiver can acknowledge data without opening the window

Receiver can change the window size without acknowledging data

AckNowindow size

(win)32 bits 16 bits

41

TCP Flow Control

receive side of TCP connection has a receive buffer:

speed-matching service: matching the send rate to the receiving app’s drain rate app process may be

slow at reading from buffer

sender won’t overflow

receiver’s buffer bytransmitting too

much, too fast

flow control

42

TCP Flow control: how it works

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

spare room in buffer= RcvWindow

= RcvBuffer-[LastByteRcvd -

LastByteRead]

Rcvr advertises spare room by including value of RcvWindow in segments

Sender limits unACKed data to RcvWindow guarantees receive

buffer doesn’t overflow

43

Sliding windows

Sent andAcknow.

Sent not acked

1 2 3 4 5 6 7 8 9 10 11 …

Usable window:Can send

ASAP

Can’t send until window

moves

Offered window advertised by receiver

44

Sliding Window: Example

3K

ReceiverBuffer

0 4KSendersends 2Kof data

2K

Sendersends 2Kof data

4K

Sender blocked

45

Sliding Window: In-class example

ack 1025 win 3072

1:1025(1024)

4K bytes

Sender Receiver

win 4096

How many more segments can it send now?

4K bytes

Sequence number:Is 1025 carried in TCP header?Is 1024 carried in TCP header?What is 1024?NOTATION

1025:2049(1024)

3 segments

How many segmentscan it send now?

2049:3073(1024)

3073:4097(1024) 1K

46

Sliding Window: In-class example answers

ack 1025 win 3072

1:1025(1024)

4K bytes

Sender Receiver

win 4096

How many more segments can it send now?

4K bytes

1025:2049(1024)

3 segments

How many segmentscan it send now? 0

2049:3073(1024)

3073:4097(1024) 1K

47

Silly Window Syndrome Let's say that the server

is only able to remove 1 byte of data from the buffer for every 3 it receives.

Let's say it also removes 40 additional bytes from the buffer during the time it takes for the next client's segment to arrive.

In the worst case, the client then sends a segment with exactly one byte, refilling the buffer until the application draws off the next byte.

48

TCP


TCP Header


Flow control

Error control

Congestion control

49

TCP error control

ARQ scheme with positive cumulative ACKs

Delayed ACKs: TCP delays transmission of ACKs for up to

200ms

The hope is to have data ready in that time frame. Then, the ACK can be piggybacked with the data segment.

50

Delayed ACK timer

This timer ticks every 200ms.

First timeout occurs based on when the timer was initialized, which is when the system was rebooted.

The figure below explains why the delay for the ACKdelay is UP TO 200 ms (and not equal to 200 ms).

somewhere hereTCP receives

segment

200 msper tick

Delayed ACK timer expires (ACK has to be sent atthis point whether or not TCP buffer has received

data to enable piggybacking)

431 2 65 7 121098 11

51

TCP Retransmission Timer Retransmission Timer:

The setting of the retransmission timer is crucial for efficiency

Timeout value too small -> results in unnecessary retransmissions

Timeout value too large -> long waiting time before a retransmission can be issued

A problem is that the delays in the network are not fixed

Therefore, the retransmission timers must be adaptive

52

Measuring TCP Retransmission Timers

aida.poly.edu rigoletto.poly.edu

ftp sessionfrom aidato rigoletto

•Transfer file from aida to rigoletto

• Unplug Ethernet cable in the middle of file transfer

53

tcpdump Trace 10:42:01.704681 aida.40001 > rigoletto.ftp-data: . 161189:162649(1460) ack 1 win 1752010:42:01.705603 aida.40001 > rigoletto.ftp-data: . 162649:164109(1460) ack 1 win 1752010:42:01.706753 aida.40001 > rigoletto.ftp-data: . 164109:165569(1460) ack 1 win 1752010:42:02.741764 aida.40001 > rigoletto.ftp-data: . 161189:162649(1460) ack 1 win 17520 10:42:05.741788 aida.40001 > rigoletto.ftp-data: . 161189:162649(1460) ack 1 win 1752010:42:11.741828 aida.40001 > rigoletto.ftp-data: . 161189:162649(1460) ack 1 win 1752010:42:23.741951 aida.40001 > rigoletto.ftp-data: . 161189:162649(1460) ack 1 win 1752010:42:47.742176 aida.40001 > rigoletto.ftp-data: . 161189:162649(1460) ack 1 win 1752010:43:35.742587 aida.40001 > rigoletto.ftp-data: . 161189:162649(1460) ack 1 win 1752010:44:39.743140 aida.40001 > rigoletto.ftp-data: . 161189:162649(1460) ack 1 win 1752010:45:43.743702 aida.40001 > rigoletto.ftp-data: . 161189:162649(1460) ack 1 win 17520 10:46:47.744271 aida.40001 > rigoletto.ftp-data: . 161189:162649(1460) ack 1 win 17520 10:47:51.752138 aida.40001 > rigoletto.ftp-data: . 161189:162649(1460) ack 1 win 17520 10:48:55.745547 aida.40001 > rigoletto.ftp-data: . 161189:162649(1460) ack 1 win 17520 10:49:59.746123 aida.40001 > rigoletto.ftp-data: . 161189:162649(1460) ack 1 win 1752010:51:03.745839 aida.40001 > rigoletto.ftp-data: R 165569:165569(0) ack 1 win 17520

54

Interpreting the Measurements

The interval between retransmission attempts in seconds is:

1.03, 3, 6, 12, 24, 48, 64, 64, 64, 64, 64, 64, 64.

Time between retransmissions is doubled each time (Exponential

Backoff Algorithm) Timer is not increased beyond 64

seconds

TCP gives up after 13th attempt and 9 minutes (total timeout, tcp_ip_abort_interval is 2 mins in Solaris and can be programmed by administrator - 9 mins is the commonly used old timeout value)

0

100

200

300

400

500

600

Se

con

ds

0 2 4 6 8 10 12

Transmission Attempts

55

TCP timers First timeout occurs based on when timer was initialized.

This explains why the first timeout occurs at 1.03 sec and not 1.5.

If the base timer clock is 500 ms, the first timeout occurs after 3 timer ticks. This happens to occur at 1.03 sec after first segment was

sent. Subsequent retransmissions occur at 3 sec, 6 sec, 12 sec, etc.

somewherehere TCP sends

first segment

500 msper tick

Retransmission timerexpires after three

ticks (<1.5 sec; in thiscase it happens to be

1.03 sec)

Retransmission timerexpires after six ticks

(3 sec)

431 2 65 7 121098 11

56

Adaptive mechanism The retransmission mechanism of TCP is adaptive The retransmission timers are set based on round-trip time

(RTT) measurements that TCP performs

RTT #1

RTT #2

RTT #3

The RTT is based on time difference between segment transmission and ACK

But: TCP does not ACK each segment

Can’t start a second RTT measurement if timing on one segment is in progress

Each connection has only one timer

57

Computation of RTO in adaptive scheme Retransmission timer is set to a Retransmission Timeout (RTO)

value.

RTO is calculated based on the RTT measurements.

The RTT measurements are smoothed by the following estimators A (mean RTT value) and D (smoothed mean deviation of RTT):Err = M - A

A A+ g Err=A(1-g)+gMD D+ h (|Err|-D)=D(1-h)+ h|Err|

RTO = A + 4D

The gains are set to h=1/4 and g=1/8– In the formula for computing the new smoothed mean RTT A, 0.125 times the newly measured value (M) is added to 0.875 times the old smoothed value of A

58

In-class example

Assume A=1, D=1 (initial values)

RT

T =

2

X (packet lost)

RTO?

RTO= ?

RTO= ?

RTO=?

RTO= ?

59

Example of RTO computation (adaptive) Assume A=1, D=1 (initial values)

• Err = 2 -1 =1 (since M, the measured RTT is 2)

• A = 1 + 0.125×1= 1.125; D = 1+0.25 (1-1)=1

• RTO = A+4D=1.125+4 = 5.125

• This is why in the figure below when segment 2 is lost, it is retransmitted after 5.125 sec.

RT

T =

2X (packet lost)R

TO

=

5.125

60

In-class example

Assume A=1, D=1 (initial values)

RT

T =

2

X (packet lost)

RTO?

RTO=A+4D=5

RTO=A+4D=5.125(adaptive: new A = 1.125; D=1)

RTO=10.25(doubling)

RTO=10.25(Karn's algorithm)

5.125 sec since that is theretransmission timer value

61

Karn’s Algorithm If an ACK for a retransmitted segment

is received, the sender cannot tell if the ACK belongs to the original or the retransmission.

The RTT measurement started for the original transmission should be terminated.

There will be no RTT measurement for the original or retransmitted segment

Therefore A and D cannot be updated when the ACK is received, and hence no new RTO computation at this point.

Don’t confuse this with the RTO being doubled when the segment is retransmitted following the exponential doubling rule.

Timeout !

RT

T ?

RT

T ?

• RTT measurement is suspended

• RTO is doubled

62

In-class example

At t1: RTO = 6 sec; A = 2; D

= 1

At t2: RTO= ?

At t3: RTO = ?

RTT #1 RTT #3

Seg

men

t 1

AC

K for S

egment 1

SY

N

SY

N

Time-out !

SY

N + A

CK

Seg

men

t 2S

egm

ent 3

AC

K for S

egment 2

AC

K for

Segm

ent 3

RTT #2

Seg

men

t 4

.

Seg

men

t 5

.

Segm

ent 6

.

AC

K for

Segm

ent 4

t1 t2 t3t4 t5 t6 t7

t8

AC

K

t9

3 sec

63

In-class example

At t1: RTO = 6 sec; A = 2; D = 1

At t2: RTO= 12 sec (doubling)

At t3: RTO = 12 sec (Karn's algorithm)

RTT #1 RTT #3

Seg

men

t 1

AC

K fo

r Seg

men

t 1

SY

N

SY

N

Time-out !=6sec

SY

N +

AC

K

Seg

men

t 2

Seg

men

t 3

AC

K fo

r Seg

men

t 2

AC

K fo

r

Seg

men

t 3

RTT #2

Seg

men

t 4

.

Seg

men

t 5

.

Seg

men

t 6

.

AC

K fo

r

Seg

men

t 4

t1 t2 t3 t4 t5t6 t7 t8

AC

K

t9

3 sec

64

Thus there are two schemes for determining RTO and two schemes for controlling RTT measurement

RTO Exponential backoff if a segment is retransmitted

Adaptive RTO as a function of RTT (A+4D)

• RTT measurement is in progress and a new segment sent then no RTT measurement is taken for new segment

RTT measurement Karn’s algorithm

• no RTT measurement on retransmitted segment

Can’t start a second RTT measurement if timing on one segment is in progress

1 Week 10 Transport Protocols, UDP, TCP. 2 Orientation r We move one layer up and look at the...

Documents

Transcript of 1 Week 10 Transport Protocols, UDP, TCP. 2 Orientation r We move one layer up and look at the...