1 end to end protocols. 2 end to end protocols r last week: m basic protocols m stop & wait...
Post on 19-Dec-2015
215 views
TRANSCRIPT
![Page 1: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/1.jpg)
1
End to End Protocols
![Page 2: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/2.jpg)
2
End to End Protocols
Last week: basic protocols Stop & wait (Correct but low performance)
Today: Window based protocol.
• Go Back N• Selective Repeat
TCP protocol. UDP protocol.
Next week: Flow control & congestion control
![Page 3: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/3.jpg)
3
rdt3.0: Stop-and-Wait Operation
first packet bit transmitted, t = 0
sender receiver
RTT
last packet bit transmitted, t = L / R
first packet bit arrives
last packet bit arrives, send ACK
ACK arrives, send next packet, t = RTT + L / R
U sender
= .008
30.016 = 0.027%
%microseconds
L / R
RTT + 2L/ R =
rdt3.0 works, but performance stinks example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:
![Page 4: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/4.jpg)
4
Last week: Performance of rdt3.0 rdt3.0 works, but performance stinks example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:
Ttransmit=8kb/pkt
10**9 b/sec= 8 microsec
Utilization = U = =8 microsec
30.016 msecfraction of time
sender busy sending = 0.00027
1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link
transport protocol limits use of physical resources!
![Page 5: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/5.jpg)
5
Pipelined protocols
Pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pkts range of sequence numbers must be increased buffering at sender and/or receiver
Two generic forms of pipelined protocols: go-Back-N, selective repeat
![Page 6: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/6.jpg)
6
Go Back N (GBN)
![Page 7: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/7.jpg)
7
Go-Back-NSender: k-bit seq # in pkt header
Unbounded seq. num. “window” of up to N, consecutive unack’ed pkts allowed
ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” may deceive duplicate ACKs (see receiver)
timer for the packet at base timeout(n): retransmit pkt n and all higher seq # pkts in
window
![Page 8: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/8.jpg)
8
GBN: sender extended FSM
/*for the packet at the new base*/
![Page 9: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/9.jpg)
9
GBN: receiver extended FSM
receiver simple: ACK-only: always send ACK for correctly-received
pkt with highest in-order seq # may generate duplicate ACKs need only remember expectedseqnum
out-of-order pkt: discard (don’t buffer) -> no receiver buffering! ACK pkt with highest in-order seq #
expectedseqnum=expectedseqnum+1
![Page 10: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/10.jpg)
10
GBN inaction
windowsize = 4
![Page 11: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/11.jpg)
11
GBN: Correctness
Claim I (safety): The receiver outputs the data in the correct order Proof: unbounded seq. num. QED
Claim I (seqnum): In the receiver:
• Value of expectedseqnum only increases In the sender:
• The received ACK seqnum only increases. This is why the sender does not need to test getacknum(rcvpkt) when updating variable base!
![Page 12: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/12.jpg)
12
GBN: correctness - liveness
Let: base=k; expecetdseqnum=m;
nextseqnum=n; Observation: k ≤ m ≤ n Claim (Liveness):
If k<m then eventually base ≥ m If (k=m and m<n) then eventually:
• receiver outputs data item m• Expectedseqnum ≥ m+1
![Page 13: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/13.jpg)
13
GBN - Bounding seq. num.
Clearing a FIFO channel:
Data k
Ack k
impossible
Data i<k-N
Ack i<k
impossible
Claim: After receiving Data k no Data i<k-N is received. After receiving ACK k no ACK i<k is received.
Corollary: Sufficient to use N+1 seq. num.
Data i<k-NNot in window with k
Ack i<kSeq num only increases
![Page 14: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/14.jpg)
14
Selective Repeat
![Page 15: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/15.jpg)
15
Selective Repeat
receiver individually acknowledges all correctly received pkts buffers pkts, as needed, for eventual in-order
delivery to upper layer
sender only resends pkts for which ACK not received sender timer for each unACKed pkt
sender window N consecutive seq #’s again limits seq #s of sent, unACKed pkts sender timer for each unACKed pkt
![Page 16: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/16.jpg)
16
Selective repeat: sender, receiver windows
![Page 17: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/17.jpg)
17
Selective repeat
data from above : if next available seq # in
window, send pkt
timeout(n): resend pkt n, restart
timer
ACK(n) in [sendbase,sendbase+N]:
mark pkt n as received if n smallest unACKed
pkt, advance window base to next unACKed seq #
senderpkt n in [rcvbase, rcvbase+N-
1]
send ACK(n) out-of-order: buffer in-order: deliver (also
deliver buffered, in-order pkts), advance window to next not-yet-received pkt
pkt n in [rcvbase-N,rcvbase-1]
ACK(n)
otherwise: ignore
receiver
![Page 18: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/18.jpg)
18
Selective repeat in action
![Page 19: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/19.jpg)
19
Selective Repeat - Correctness Infinite seq. Num.
Safety: immediate from the seq. Num. Liveness: Eventually data and ACKs get
through. Finite Seq. Num.
Idea: Re-use seq. Num. Use less bits to encode them.
Number of seq. Num.: At least N. Needs more!
![Page 20: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/20.jpg)
20
Selective repeat: dilemma
Example: seq #’s: 0, 1, 2, 3 window size=3
receiver sees no difference in two scenarios!
Incorrectly Passes duplicate data
as new in (a) or Discards in (b)
Q: what relationship between seq # size and window size?
![Page 21: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/21.jpg)
21
Choosing the window size
Small window size: idle link (under-utilization).
Large window size: Buffer space Delay after loss
Ideal window size (assuming very low loss) RTT =Round trip time C = link capacity window size = RTT * C
What happens with no loss?
![Page 22: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/22.jpg)
22
End to End Protocols:
Multiplexing &Demultiplexing
![Page 23: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/23.jpg)
23
applicationtransportnetwork
MP2
applicationtransportnetwork
Multiplexing/demultiplexing
Recall: segment - unit of data exchanged between transport layer entities aka TPDU: transport
protocol data unitreceiver
HtHn
Demultiplexing: delivering received segments to correct app layer processes
segment
segment Mapplicationtransportnetwork
P1M
M MP3 P4
segmentheader
application-layerdata
![Page 24: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/24.jpg)
24
Multiplexing/demultiplexing
multiplexing/demultiplexing:
based on sender, receiver port numbers, IP addresses source, dest port #s
in each segment recall: well-known
port numbers for specific applications
Using IP addresses – layer violation.
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
Multiplexing:
![Page 25: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/25.jpg)
25
Multiplexing/demultiplexing: examples
host A server Bsource port: xdest. port: 23
source port:23dest. port: x
port use: simple telnet app
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
port use: Web server
Source IP: ADest IP: B
source port: x
dest. port: 80
![Page 26: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/26.jpg)
26
UDP Protocol
![Page 27: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/27.jpg)
27
UDP: User Datagram Protocol [RFC 768]
“no frills,” “bare bones” Internet transport protocol
“best effort” service, UDP segments may be: lost delivered out of order
to application connectionless:
no handshaking between UDP sender, receiver
each UDP segment handled independently of others
Why is there a UDP? no connection
establishment (which can add delay)
simple: no connection state at sender, receiver
small segment header no congestion control:
UDP can blast away as fast as desired
![Page 28: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/28.jpg)
28
UDP: more
often used for streaming multimedia apps loss tolerant rate sensitive
other UDP uses (why?): 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 29: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/29.jpg)
29
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.
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
![Page 30: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/30.jpg)
30
TCP Protocol
![Page 31: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/31.jpg)
31
TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581
full duplex data: bi-directional data flow
in same connection MSS: maximum
segment size
connection-oriented: handshaking (exchange
of control msgs) init’s sender, receiver state before data exchange
flow controlled: sender will not
overwhelm receiver
point-to-point: one sender, one
receiver
reliable, in-order byte steam: no “message
boundaries”
pipelined: TCP congestion and flow
control set window size
send & receive bufferssocketdoor
T C Psend buffer
T C Preceive buffer
socketdoor
segm ent
applicationwrites data
applicationreads data
![Page 32: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/32.jpg)
32
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)
URG: urgent data (generally not used)
ACK: ACK #valid
PSH: push data now(generally not used)
RST, SYN, FIN:connection estab(setup, teardown
commands)
# bytes rcvr willingto accept
countingby bytes of data(not segments!)
Internetchecksum
(as in UDP)
![Page 33: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/33.jpg)
33 33
Connection Management: Objective
Agree on initial sequence numbers a sender will not reuse a seq# before it is
sure that all packets with the seq# are purged from the network
• the network guarantees that a packet too old will be purged from the network: network bounds the life time of each packet
To avoid waiting for the seq# to start a session, use a larger seq# space
• needs connection setup so that the sender tells the receiver initial seq#
Agree on other initial parameters
![Page 34: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/34.jpg)
34
TCP seq. #’s and ACKsSeq. #’s:
byte stream “number” of first byte in segment’s data
ACKs: seq # of next byte
expected from other side
cumulative ACKQ: how receiver handles
out-of-order segments A: TCP spec doesn’t
say - up to implementor
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’, echoesback ‘C’
timesimple telnet scenario
![Page 35: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/35.jpg)
35 35
Three Way Handshake (TWH) [Tomlinson 1975]
To ensure that the other side does want to send a request
Host A
SYN(seq=x)
Host B
ACK(seq=x), SYN(seq=y)
ACK(seq=y)
DATA(seq=x+1)
Host A Host B
ACK(seq=x), SYN(seq=y)
REJECT(seq=y)
SYN(seq=x)
accept?
no suchrequest
reject
ACK(seq=z)
![Page 36: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/36.jpg)
36 36
Connection Close
Objective of closure handshake: each side can release
resource and remove state about the connection
client
I am done. Are you done too?
server
I am done too. Goodbye!
init. close
close
close
release resource?
release resource?
release resource?
![Page 37: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/37.jpg)
37
TCP: reliable data transfer
simplified sender, assuming
waitfor
event
waitfor
event
event: data received from application above
event: timer timeout for segment with seq # y
event: ACK received,with ACK # y
create, send segment
retransmit segment
ACK processing
•one way data transfer•no flow, congestion control
![Page 38: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/38.jpg)
38
TCP: reliable data transfer
00 sendbase = initial_sequence number 01 nextseqnum = initial_sequence number 0203 loop (forever) { 04 switch(event) 05 event: data received from application above 06 create TCP segment with sequence number nextseqnum 07 start timer for segment nextseqnum 08 pass segment to IP 09 nextseqnum = nextseqnum + length(data) 10 event: timer timeout for segment with sequence number y 11 retransmit segment with sequence number y 12 compue new timeout interval for segment y 13 restart timer for sequence number y 14 event: ACK received, with ACK field value of y 15 if (y > sendbase) { /* cumulative ACK of all data up to y */ 16 cancel all timers for segments with sequence numbers < y 17 sendbase = y 18 } 19 else { /* a 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 */
SimplifiedTCPsender
![Page 39: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/39.jpg)
39
TCP 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
immediately send singlecumulative ACK
send duplicate ACK, indicating seq. #of next expected byte
immediate ACK if segment startsat lower end of gap
![Page 40: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/40.jpg)
40
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
time 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 41: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/41.jpg)
41
TCP Connection Management
Recall: TCP sender, receiver establish “connection” before exchanging data segments
initialize TCP variables: seq. #s buffers, flow control
info (e.g. RcvWindow) client: connection
initiator server: contacted by
client
![Page 42: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/42.jpg)
42
TCP Connection Management (cont.)
Three way handshake:
Step 1: client end system sends TCP SYN control segment to server specifies initial seq #
Step 2: server end system receives SYN, replies with SYN-ACK control segment ACKs received SYN allocates buffers specifies server-> receiver
initial seq. #
Step 3: client receives SYN-ACK and replies with ACK (possibly with data).
client
Syn seq=100
server
SYN-ACK seq=330 ack=100
ACK
SYN_sent
SYN_rcvd
ESTABLISHED
ESTABLISHED
![Page 43: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/43.jpg)
43
TCP Connection Management (cont.)
Closing a connection:
client closes socket: clientSocket.close();
Step 1: client end system sends TCP FIN control segment to server
Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN.
client
FIN
server
ACK
ACK
FIN
close
close
closed
tim
ed w
ait
![Page 44: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/44.jpg)
44
TCP Connection Management (cont.)
Step 3: client receives FIN, replies with ACK.
Enters “timed wait” - will respond with ACK to received 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
![Page 45: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/45.jpg)
45
TCP Connection Management (cont)
TCP clientlifecycle
TCP serverlifecycle
![Page 46: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/46.jpg)
46
TCPstatetransitiondiagram
![Page 47: 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct but low performance) r Today: m Window based protocol](https://reader035.vdocument.in/reader035/viewer/2022062515/56649d2b5503460f94a00a72/html5/thumbnails/47.jpg)
47
Simultaneous open
SYNSeq=100
SYNSeq=330
SYN-ACKSeq=101Ack=330
ACK+Data
ACK+Data
SYN_SENT
SYN-ACKSeq=331Ack=100
SYN_RCVD
ESTABLISHED