1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct...
-
date post
19-Dec-2015 -
Category
Documents
-
view
217 -
download
1
Transcript of 1 End to End Protocols. 2 End to End Protocols r Last week: m basic protocols m Stop & wait (Correct...
1
End to End Protocols
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
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:
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!
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
6
Go Back N (GBN)
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
8
GBN: sender extended FSM
/*for the packet at the new base*/
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
10
GBN inaction
windowsize = 4
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!
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
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
14
Selective Repeat
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
16
Selective repeat: sender, receiver windows
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
18
Selective repeat in action
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!
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?
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?
22
End to End Protocols:
Multiplexing &Demultiplexing
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
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:
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
26
UDP Protocol
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
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
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
30
TCP Protocol
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
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)
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
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
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)
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?
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
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
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
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
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
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
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
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
45
TCP Connection Management (cont)
TCP clientlifecycle
TCP serverlifecycle
46
TCPstatetransitiondiagram
47
Simultaneous open
SYNSeq=100
SYNSeq=330
SYN-ACKSeq=101Ack=330
ACK+Data
ACK+Data
SYN_SENT
SYN-ACKSeq=331Ack=100
SYN_RCVD
ESTABLISHED