css432 end-to-end protocols textbook ch5.1 – 5.2
Post on 31-Dec-2015
37 Views
Preview:
DESCRIPTION
TRANSCRIPT
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)
CSS432: Internetworking 3
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, m1
CSS432: 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 #)
CSS432: End-to-End Protocols
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
CSS432: End-to-End Protocols
8
Transport vs. Data Link Layer
CSS432: End-to-End Protocols
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
CSS432: End-to-End Protocols
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
CSS432: End-to-End Protocols
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.
CSS432: End-to-End Protocols
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
CSS432: End-to-End Protocols
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 + 1CLOSE_WAIT
LAST_ACK( close( ) )ACK x + 3
FIN seq = y + 1FIN_WAIT_2
TIME_WAITACK=y + 2
Est
ablis
hmen
tT
erm
inat
ion
Dat
aT
rans
fer
You may see this with tcpdump in assignment 3.CSS432: End-to-End Protocols
CSS432: Internetworking 15
CSS432: Internetworking 16
http://www.tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMachineF-2.htm
CSS432: Internetworking 17
http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm
CSS432: Internetworking 18
http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm
CSS432: Internetworking 19
http://www.tcpipguide.com/free/t_TCPConnectionTermination-4.htm
CSS432: Internetworking 20
http://www.tcpipguide.com/free/t_TCPConnectionTermination-4.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]
CSS432: End-to-End Protocols
CSS432: Internetworking 22
http://www.tcpipguide.com/free/t_TCPSlidingWindowAcknowledgmentSystemForDataTranspo-6.htm
23
Flow ControlSending application
LastByteWrittenTCP
LastByteSentLastByteAcked
Receiving application
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)
CSS432: End-to-End Protocols
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
Receiving application
LastByteReadTCP
LastByteRcvd =NextByteExpected - 1
LastByteRcvd – LastByteRead ≤ MaxRcvbuffer
0
y y
No more send, no more ack, thus it staysIn the same value
Read slow.
CSS432: End-to-End Protocols
LastByteSentLastByteAcked
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
CSS432: End-to-End Protocols
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 bandwidth
Bandwidth 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
CSS432: End-to-End Protocols
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
CSS432: End-to-End Protocols
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
CSS432: End-to-End Protocols
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: End-to-End Protocols
CSS432: Internetworking 32
http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow.htm
CSS432: Internetworking 33
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
CSS432: End-to-End Protocols
35
Timeouts
Why timeout?
CSS432: End-to-End Protocols
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)?
CSS432: End-to-End Protocols
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
CSS432: End-to-End Protocols
38
Original Algorithm Measure SampleRTT for each segment / ACK pair
CSS432: End-to-End Protocols
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
CSS432: End-to-End Protocols
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
CSS432: End-to-End Protocols
41
Karn / Partridge Algorithm (1987)
CSS432: End-to-End Protocols
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
CSS432: End-to-End Protocols
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
CSS432: End-to-End Protocols
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)
CSS432: End-to-End Protocols
Exercise 5
When closing a TCP connection, why is the two-segment lifetime timeout not necessary on the transition from LAST_ACK to CLOSED?
CSS432: Internetworking 45
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
CSS432: Internetworking 46
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?
CSS432: Internetworking 47
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?
CSS432: Internetworking 48
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.
CSS432: Internetworking 49
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.
CSS432: Internetworking 50
[not used]
CSS432: Internetworking 51
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?
CSS432: End-to-End Protocols
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
CSS432: End-to-End Protocols
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);
CSS432: End-to-End Protocols
top related