CSS432 End-to-End Protocols Textbook Ch5.1 – 5.2

CSS432: End-to-End Protocols 1

CSS432 End-to-End Protocols Textbook Ch5.1 – 5.2

Instructor: Joe McCarthy(based on Prof. Fukuda’s slides)

Overview

CSS432: Internetworking 2

bits

frames

packets

segments

Utilize host-to-host packet delivery service (network layer) to provide a process-to-process communication channel (transport layer)


http://www.tcpipguide.com/free/t_TCPDataHandlingandProcessingStreamsSegmentsandSequ-2.htm

http://www.tcpipguide.com/free/t_TCPDataHandlingandProcessingStreamsSegmentsandSequ-2.htm

4

IP Protocol Underlying “best-effort” network

May drop messages May re-order messages May deliver duplicate copies of a given message May deliver messages after an arbitrarily long delay Limits messages to a finite size IP addresses (globally unique)

M5, M4, M3, M2, M1 M5, M2, M1

M4, M3 M4

M3

M2, M1, M4M5

Request a retransmission of M3 and M5

M5, and M3M5, M5, M3

CSS432: End-to-End Protocols

5

End-to-End Protocols Common end-to-end services

support multiple application processes on each host guarantee message delivery deliver messages in FIFO order deliver at most one copy of each message support arbitrarily large messages support synchronization allow the receiver to flow control the sender

P1 P2 P3 P4

NetworkM5, M4, M3, M2, M1

m5, m4, m3, m2, m1CSS432: End-to-End Protocols

6

Simple Demultiplexor (UDP) User Datagram Protocol Adds multiplexing Unreliable & unordered No flow control Endpoints identified by ports

servers have well-known ports see /etc/services on Unix

Optional checksum UDP header + data +

pseudoheader(Src & Dst IP addrs, protocol #)


7

TCP Overview Connection-oriented Byte-stream

app writes bytes TCP assembles &

sends segments app reads bytes

Full duplex Flow control: keep sender from

overrunning receiver Congestion control: keep sender

from overrunning network


8

Transport vs. Data Link Layer


9

Transport vs. Data Link Layer Potentially connects many different hosts

need explicit connection establishment and termination Potentially long delay in network

need to be prepared for arrival of very old packets need to set MSL (Maximum Segment Lifetime)

Potentially high variation in RTT (Round Trip Time) need adaptive timeout mechanism

Potentially different capacity at destination need to accommodate different node capacity

Potentially different network capacities need to be prepared for network congestion


10

TCP Segment Format

Options (variable)

Data

Checksum

SrcPort DstPort

HdrLen 0 Flags

UrgPtr

AdvertisedWindow

SequenceNum

Acknowledgment

0 4 10 16 31

Each connection identified with 4-tuple: (SrcPort, SrcIPAddr,

DstPort, DstIPAddr) Sliding window + flow control

Acknowledgment, SequenceNum, AdvertisedWinow

Flags SYN: Establish a connection FIN: terminate a connection RESET: Confused, terminate PUSH: Section 5.2.7 URG: Sending urgent data ACK: Validating acknowledgment

field SequenceNum is incremented in

all cases other than ACK.

Sender

Data (SequenceNum)

Acknowledgment +AdvertisedWindow

Receiver


11

TCP Connection Establishment 3-Way Handshake

Client Initiate a connection to a

server with SeqNum=x Set a timer and retransmit

the request upon an expiration

Server Acknowledge the client

request with ACK=x+1 Initiate a reverse

connection with SeqNum=y Set a timer and retransmit

the request upon an expiration

Client Acknowledge the server

request with ACK=y+1 x and y are chosen at

random Protect against two

incarnations of the same connection using the same sequence number.


12

TCP Connection Tear-Down

3-Way Handshake Initiator: FIN Receiver: ACK/FIN Initiator: ACK

“Half-open” connection Receiver (of FIN) may still

have data to send Acknowledges FIN Keeps sending data Sends its own FIN Receiver acknowledges


http://en.wikipedia.org/wiki/Transmission_Control_Protocol

13

State Transition DiagramCLOSED

LISTEN

SYN_RCVD SYN_SENT

ESTABLISHED

CLOSE_WAIT

LAST_ACKCLOSING

TIME_WAIT

FIN_WAIT_2

FIN_WAIT_1

Passive open Close

Send/SYNSYN/SYN + ACK

SYN + ACK/ACK

SYN/SYN + ACK

ACK

Close/FIN

FIN/ACKClose/FIN

FIN/ACKACK + FIN/ACK Timeout after two segment lifetimes(2 * MSL)FIN/ACK

ACK

ACK

ACK

Close/FIN

Close

CLOSED

Active open/SYN Open

Active open A client connect()

Passive open A server listen() Can change active

Close Active close

A client or a server First close() Both side can be

active Passive close

A client or server close() in response to

the first close()CSS432: End-to-End Protocols

14

Timing ChartClient Server

( connect( ) ) SYN_SENT SYN seq=x

ACK=y + 1

SYN_RCVD

ESTABLISHED

LISTEN ( listen( ) )

SYN seq=y, ACK=x + 1

ESTABLISHED

( write( ) )

( read( ) )

seq=x+1 ACK=y + 1

ACK x + 2

( close( ) ) FIN_WAIT_1 FIN seq=x+2 ACK=y + 1 CLOSE_WAIT

LAST_ACK( close( ) )ACK x + 3

FIN seq = y + 1FIN_WAIT_2

TIME_WAITACK=y + 2

Est

ablis

hmen

tTe

rmin

atio

nD

ata

Tran

sfer

You may see this with tcpdump in assignment 3.CSS432: End-to-End Protocols



http://www.tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMachineF-2.htm


http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm







21

Sliding Window Revisited

Sending side LastByteAcked

≤ LastByteSent≤ LastByteWritten

buffer bytes between [LastByteAcked, LastByteWritten]

Sending application

LastByteWrittenTCP

LastByteSentLastByteAcked

Receiving application

LastByteReadTCP

LastByteRcvdNextByteExpected

Receiving side LastByteRead

< NextByteExpected≤ LastByteRcvd + 1

buffer bytes between[LastByteRead, LastByteRcvd]



http://www.tcpipguide.com/free/t_TCPSlidingWindowAcknowledgmentSystemForDataTranspo-6.htm

23

Flow ControlSending application

LastByteWrittenTCP



LastByteReadTCP

LastByteRcvdNextByteExpected

LastByteRcvd – LastByteRead ≤ MaxRcvbuffer

AdvertisedWindow= MaxRcvBuffer – ( (NextByteExpected – 1) – LastByteRead )

LastByteSent – LastByteAcked

≤

AdvertisedWindow

EffectiveWindow= AdvertisedWindow – (LastByteSent – LastByteAcked)

LastByteWritten – LastByteAcked ≤ MaxSendBuffer

block sender if (LastByteWritten - LastByteAcked) + y > MaxSendBuffer

y

Send ACK with an advertise windowin response to arriving data segments• as long as all the preceding bytes have also arrived and• until the advertised window reaches 0. (ACK returned at the first time when it reaches 0)


Options (variable)

Data

Checksum

SrcPort DstPort

HdrLen 0 Flags

UrgPtr

AdvertisedWindow

SequenceNum

Acknowledgment

0 4 10 16 31

LastByteSent – LastByteAcked

AdvertisedWindow= MaxRcvBuffer – ( (NextByteExpected – 1) – LastByteRead )= 0

24

Flow Control with a Slower ReceiverSending application

LastByteWrittenTCP


LastByteReadTCP

LastByteRcvd =NextByteExpected - 1

LastByteRcvd – LastByteRead ≤ MaxRcvbuffer

0

y y

No more send, no more ack, thus it staysIn the same value

Read slow.



EffectiveWindow= AdvertisedWindow – (LastByteSent – LastByteAcked)

LastByteWritten – LastByteAcked ≤ MaxSendBuffer

Flow Control AdvertisedWindow = 0: sender won’t send

any more data. Receiver only responds to sender

Will not initiate update when AdvertisedWindow > 0

How can the sender find out when the receiver can receive more data?

25CSS432: End-to-End Protocols

Flow Control AdvertisedWindow = 0: sender won’t send

any more data. Receiver only responds to sender

Will not initiate update when AdvertisedWindow > 0

How can the sender find out when the receiver can receive more data?Periodically send a byte

“Smart sender / dumb receiver”26CSS432: End-to-End Protocols

27

32-bit SequenceNum Maximum Segment Lifetime(MSL) = 120 seconds

SequenceNum should not wrap around within MSL time period

Bandwidth Time Until Wrap AroundT1 (1.5 Mbps) 6.4 hoursEthernet (10 Mbps) 57 minutesT3 (45 Mbps) 13 minutesFDDI (100 Mbps) 6 minutesSTS-3 (155 Mbps) 4 minutesSTS-12 (622 Mbps) 55 secondsSTS-24 (1.2 Gbps) 28 seconds

Wraparound


Options (variable)

Data

Checksum

SrcPort DstPort

HdrLen 0 Flags

UrgPtr

AdvertisedWindow

SequenceNum

Acknowledgment

0 4 10 16 31

28

Keeping the Pipe Full 16-bit AdvertisedWindow = 64KB Assuming that RTT = 100msec,

the advertised window’s capacity x Network bandwidthBandwidth RTT(100msec) x Bandwidth ProductT1 (1.5 Mbps) 18KBEthernet (10 Mbps) 122KBT3 (45 Mbps) 549KBFDDI (100 Mbps) 1.2MBSTS-3 (155 Mbps) 1.8MBSTS-12 (622 Mbps) 7.4MBSTS-24 (1.2 Gbps) 14.8MB


Options (variable)

Data

Checksum

SrcPort DstPort

HdrLen 0 Flags

UrgPtr

AdvertisedWindow

SequenceNum

Acknowledgment

0 4 10 16 31

29

Segment Transmission

Segments are buffered until send triggered:1. Buffer reaches Maximum Segment Size (MSS)

= Maximum Transfer Unit (MTU) – ( TCP header size + IP header size )

2. TCP invokes a push operation that flushes the unsent data

3. When a timer expires May precipitate silly window syndrome


30

Silly Window Syndrome

Sender aggressively takes advantage of any available window, The receiver empties every window regardless of its size and thus small

windows will never disappear. The problem occurs only when

Sender transmits a small segment Receiver opens the AdvertisedWindow a small amount

What should be done? And who should do it?

MMS 1

MMS 2

Ad Window

Ad Window

small

Sender Receiver


31

Silly Window Syndrome

Sender aggressively takes advantage of any available window, The receiver empties every window regardless of its size and thus small

windows will never disappear. The problem occurs only when

Sender transmits a small segment Receiver opens the AdvertisedWindow a small amount

The receiver could delay ACKs to make a larger window How long does it wait?

The sender should make a decision (“smart sender/dumb receiver”) Nagle’s Algorithm (Programming assignment 3)

MMS 1

MMS 2

Ad Window

Ad Window

small

Sender Receiver


CSS432: Internetworking 32http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow.htm


The client's send window is 360, and it has lots of data to send. It immediately sends a 360 byte segment to the server. This uses up its entire send window.

When the server gets this segment it acknowledges it. However, it can only remove 120 bytes so the server reduces the window size from 360 to 120. It sends this in the Window field of the acknowledgment.

The client receives an acknowledgment of 360 bytes, and sees that the window size has been reduced to 120. It wants to send its data as soon as possible, so it sends off a 120 byte segment.

The server has removed 40 more bytes from the buffer by the time the 120-byte segment arrives. The buffer thus contains 200 bytes (240 from the first segment, less the 40 removed). The server is able to immediately process one-third of those 120 bytes, or 40 bytes. This means 80 bytes are added to the 200 that already remain in the buffer, so 280 bytes are used up. The server must reduce the window size to 80 bytes.

The client will see this reduced window size and send an 80-byte segment.

The server started with 280 bytes and removed 40 to yield 240 bytes left. It receives 80 bytes from the client, removes one third, so 53 are added to the buffer, which becomes 293 bytes. It reduces the window size to 67 bytes (360-293).

http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow.htm

34

Nagle’s Algorithm

Ack works as a timer to fire a new segment transmission. The algorithm may not respond to interactive or real-time

applications TCP_NODELAY Option: Transmit data as soon as possible

setsockopt(sockfd, SOL_TCP, TCP_NODELAY, &intFlag, sizeof(intFlag))

When the application produces new data to send if both the new data & available window ≥ MSS send a full segment // send MSS bytes right now else if there is unAcked data in transit buffer new data until an ACK arrives // wait for empty MSS segment else send all the new data now // Can’t avoid silly window syndrome


35

Timeouts

Why timeout?


36

Timeouts & Retransmissions

Timeout required for reliable transmissionRetransmit a lost packetDetect congestion / invoke congestion controlBut: RTT can vary widely

When to timeout (how long to wait)?


37

Adaptive Retransmission

Timeout required for reliable transmissionRetransmit a lost packetDetect congestion / invoke congestion controlBut: RTT can vary widely

Timeout using RTT estimation algorithmsOriginal AlgorithmKarn/Partridge AlgorithmJacobson/Karels Algorithm


38

Original Algorithm Measure SampleRTT for each segment / ACK pair


39

Original Algorithm Measure SampleRTT for each segment / ACK pair Compute weighted average of RTT

EstRTT = x EstRTT + x SampleRTT where + = 1¨ between 0.8 and 0.9 (smoothing function)¨ between 0.1 and 0.2


40

Original Algorithm Measure SampleRTT for each segment / ACK pair Compute weighted average of RTT

EstRTT = x EstRTT + x SampleRTT where + = 1¨ between 0.8 and 0.9 (smoothing function)¨ between 0.1 and 0.2

Set timeout based on EstRTT TimeOut = 2 x EstRTT Conservative: EstRTT cannot respond quickly to

deviations in SampleRTT


41

Karn / Partridge Algorithm (1987)


42

Karn / Partridge Algorithm (1987)

Do not sample RTT when retransmitting Can’t figure out which transmission the latest ACK corresponds to.

Double timeout (vs. EstRTT) after each retransmission Exponential backoff Congestion most likely cause of lost segments


43

Jacobson / Karels Algorithm (1988) Original Algorithm

EstRTT = x EstRTT + x SampleRTT 0.8 and 0.9 0.1 and 0.2 TimeOut = EstRTT * 2

New Algorithm that takes into accountlarge variations among SampleRTTs EstRTT = EstRTT + (SampleRTT – EstRTT)

0.125 Diff Dev = Dev + (|SampleRTT – EstRTT| – Dev)

Diff

TimeOut = x EstRTT + x Dev 1 4


44

Reviews UDP TCP: three-way handshake and state transition Sliding window and flow control Segment transmission: silly window syndrome and

Nagle’s algorithm Adaptive retransmission: original, Karn/Partridge, and

Jacobson/Karels Exercises in Chapter 5

Ex. 5, 14, 22, and 39 (TCP state transition) Ex. 9(a) (Sliding window) Ex. 20 (Nagle’s algorithm)


Exercise 5 When closing a TCP

connection, why is the two-segment lifetime timeout not necessary on the transition from LAST_ACK to CLOSED?


Exercise 14 If host A receives two SYN packets from the same port

from remote host B, the second may be either a retransmission of the original or, if B has crashed and rebooted, an entirely new connection request.

(a) Describe the difference as seen by host A between these two cases.

(b) Give an algorithmic description of what the TCP layer needs to do upon receiving a SYN packet. Consider the duplicate/new cases above and the possibility that nothing is listening to the destination port


Exercise 9(a)

You are hired to design a reliable byte-stream protocol that uses a sliding window (like TCP). This protocol will run over a 1-Gbps network. The RTT of the network is 100 ms, and the maximum segment lifetime is 30 seconds.

(a) How many bits would you include in the AdvertisedWindow and SequenceNum fields of your protocol header?


Exercise 20 The Nagle algorithm, built into most TCP implementations, requires

the sender to hold a partial segment’s worth of data (even if PUSHed) until either a full segment accumulates or the most recent outstanding ACK arrives.

(a) Suppose the letters abcdefghi are sent, one per second, over a TCP connection with an RTT of 4.1 seconds. Draw a timeline indicating when each packet is sent and what it contains.

(b) If the above were typed over a full-duplex Telnet connection, what would the user see?

(c) Suppose that mouse position changes are being sent over the connection. Assuming that multiple position changes are sent each RTT, how would a user perceive the mouse motion with and without the Nagle algorithm?


Exercise 22 Explain why

TIME_WAIT is a somewhat more serious problem if the server initiates the close than if the client does. Describe a situation in which this might reasonably happen.


Exercise 39 When TCP sends a

SYN, SequenceNum = x or FIN, SequenceNum = x, the consequent ACK has Acknowledgement = x + 1, i.e., SYNs and FINs each take up one unit in sequence number space.

Is this necessary? If so give an example of an ambiguity that would arise if the corresponding Acknowledgement were x instead of x + 1; if not, explain why.


[not used]


52

State Transition Diagram

In what condition can the state transit from FIN_WAIT_1 to TIME_WAIT?

What is the purpose of the TIME_WAIT state?


53

Jacobson/ Karels AlgorithmSampleRTT –= (EstimatedRTT >> 3)

EstimatedRTT += SampleRTT;

If (SampleRTT < 0)

SampleRTT = – SampelRTT;

SampleRTT –= (Deviation >> 3);

Deviation += SampleRTT;

TimeOut = (EstimatedRTT >> 3) + (Deviation >> 1)

EstimatedRTT = 8 EstRTTDeviation = 8 DevSampleRTT = (SampleRTT – 8 EstRTT) / 8

= SampleRTT – EstRTT)

diff

8 EstRTT = 8EstRTT + SampleRTT= 8EstRTT + (SampleRTT – EstRTT)

EstRTT = EstRTT + 1/8 (SampleRTT – EstRTT)

diff

8 Dev = 8 Dev + |SampleRTT – EsRTT| - DevDev = Dev + 1/8( |SampleRTT – EstRTT| - Dev )

TimeOut = 8 EstRTT / 8 + 8 Dev / 2TimeOut = EstRTT + 4 Dev

|SampleRTT – EstRTT| – 8Dev/8

|diff| Notes

Algorithm does not work accurately with a large granularity of clock (500ms on Unix)

Accurate timeout mechanism important to congestion control


54

UDP: Simple Demultiplexerint sd;sd = socket(AF_INET, SOCK_DGRAM, 0);

struct sockaddr_in server;server.sin_family =AF_INET;server.sin_addr.s_addr = htonl( INADDR_ANY)server.sin_port = htons( 12345 );bind( sd, (struct sockaddr *)&server, sizeof( server ) );

recv( sd, buf, sizeof( buf ), 0 );

struct sockaddr_in server;struct hostent *hp, *gethostbyname( );Server.sin_family = AF_INET;hp = gethostbyname( );bcopy( hp->h_addr, &( server.sin_addr.s_addr ), sizeof( hp->h_length) );server.sin_port = htons( 12345 );

sendto( sd, buf, sizeof( buf ), 0, (struct sockaddr *)&server, sizeof( server ) );

socket()

sendto()

socket()

bind()

recv()

Port:12345

socket()

bind()

recv()

Port: 13579

13579

13579

UDP

Packetsdemultiplexed

M5, M4, M3, M2, M1CSS432: End-to-End Protocols

55

Sockets (Code Example)int sd, newSd;sd = socket(AF_INET, SOCK_STREAM, 0);

sockaddr_in server;bzero( (char *)&server, sizeof( server ) );server.sin_family =AF_INET;server.sin_addr.s_addr = htonl( INADDR_ANY )server.sin_port = htons( 12345 );bind( sd, (sockaddr *)&server, sizeof( server ) );

struct hostent *host = gethostbyname( arg[0] );sockaddr_in server;bzero( (char *)&server, sizeof( server ) );server.sin_family = AF_INET;server.s_addr = inet_addr( inet_ntoa( *(struct in_addr*)*host->h_addr_list ) );server.sin_port = htons( 12345 );

connect( sd, (sockaddr *)&server, sizeof( server ) );

sockaddr_in client; socklen_t len=sizeof(client);while( true ) { newSd = accept(sd, (sockaddr *)&client, &len);

write( sd, buf1, sizeof( buf ) );write( sd, buf2, sizeof( buf ) ); if ( fork( ) == 0 ) {

close( sd ); read( newSd, buf1, sizeof( buf1 ) ); read( newSd, buf2, sizeof( buf2 ) );

} close( newSd );}

read() read()

socket()

connect()

write()

socket()

connect()

write()

listen( sd, 5 );

socket()

bind()

listen()

accept()

buf2, buf1

buf2, buf1close( newsd);exit( 0 );

int sd = socket(AF_INET, SOCK_STREAM, 0);


Documents

CSS432 End-to-End Protocols Textbook Ch5.1 – 5.2