School of Computing Science - PowerPoint PPT Presentation

Loading...

PPT – School of Computing Science PowerPoint presentation | free to download - id: d21e2-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

School of Computing Science

Description:

Step 1: client end system sends TCP FIN segment to server ... Closes connection, sends FIN. Step 3: client receives FIN, replies with ACK ... – PowerPoint PPT presentation

Number of Views:25
Avg rating:3.0/5.0
Slides: 46
Provided by: Mohamed4
Learn more at: http://www.cs.sfu.ca
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: School of Computing Science


1
  • School of Computing Science
  • Simon Fraser University
  • CMPT 771/471 Internet Architecture and Protocols
  • Transport Layer
  • Instructor Dr. Mohamed Hefeeda

2
Review of Basic Networking Concepts
  • Internet structure
  • Protocol layering and encapsulation
  • Internet services and socket programming
  • Network Layer
  • Network types Circuit switching, Packet
    switching
  • Addressing, Forwarding, Routing
  • Transport layer
  • Reliability, congestion and flow control
  • TCP, UDP
  • Link Layer
  • Multiple Access Protocols
  • Ethernet

3
Transport services and protocols
  • provide logical communication between app
    processes running on different hosts
  • transport protocols run in end systems
  • send side breaks app messages into segments,
    passes to network layer
  • rcv side reassembles segments into messages,
    passes to app layer
  • more than one transport protocol available to
    apps
  • Internet TCP and UDP

4
Transport vs. network layer
  • network layer logical communication between
    hosts
  • transport layer logical communication between
    processes
  • relies on, enhances, network layer services
  • Household analogy
  • 12 kids sending letters to 12 kids
  • processes kids
  • app messages letters in envelopes
  • hosts houses
  • transport protocol Ann and Bill
  • network-layer protocol postal service

5
Multiplexing/demultiplexing
delivering received segments to correct socket
gathering data from multiple sockets, enveloping
data with header (later used for demultiplexing)
process
socket
application
P4
application
application
P1
P2
P3
P1
transport
transport
transport
network
network
network
link
link
link
physical
physical
physical
host 3
host 1
host 2
6
Connectionless demux
client IP A
Client IPB
server IP C
  • UDP socket identified by (dst IP, dst Port) ?
  • datagrams with different src IPs and/or src ports
    are directed to same socket

7
Connection-oriented demux (cont)
S-IP B
D-IPC
SP 9157
Client IPB
DP 80
server IP C
S-IP A
S-IP B
D-IPC
D-IPC
  • TCP socket identified by 4-tuple (src IP, src
    Port, dst IP, dst Port)

8
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 app
  • 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

9
UDP
  • often used for streaming multimedia apps
  • loss tolerant
  • rate sensitive
  • other UDP uses
  • DNS
  • SNMP
  • reliable transfer over UDP add reliability at
    application layer
  • application-specific error recovery!

32 bits
source port
dest port
Length, in bytes of UDP segment, including header
checksum
length
Application data (message)
UDP segment format
10
Reliable data transfer
  • important in application, transport, and link
    layers
  • top-10 list of important networking topics!
  • characteristics of unreliable channel will
    determine complexity of reliable data transfer
    protocol (rdt)

11
Pipelined (Sliding Window) 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

12
Go-Back-N
  • Sender
  • k-bit seq in pkt header
  • window of up to N, consecutive unacked pkts
    allowed
  • ACK(n) ACKs all pkts up to, including seq n --
    cumulative ACK
  • may receive duplicate ACKs (see receiver)
  • timer for each in-flight pkt
  • timeout(n) retransmit pkt n and all higher seq
    pkts in window
  • i.e., go back to n

13
GBN inaction
Go back to 2
Window size, N 4
14
Go-Back-N
  • Do you see potential problems with GBN?
  • Consider high-speed links with long delays
  • (called large bandwidth-delay product pipes)
  • GBN can fill that pipe by having large N ?
  • many unACKed pkts could be in the pipe
  • A single lost pkt could cause a re-transmission
    of a huge number (up to N) of pkts ? waste of
    bandwidth
  • Solutions??

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

16
Selective repeat sender, receiver windows
17
TCP Overview RFCs 793, 1122, 1323, 2018, 2581
  • point-to-point
  • one sender, one receiver
  • reliable, in-order byte stream
  • no message boundaries
  • pipelined
  • TCP congestion and flow control set window size
  • send receive buffers
  • full duplex data
  • bi-directional data flow in same connection
  • MSS maximum segment size
  • connection-oriented
  • handshaking (exchange of control msgs) inits
    sender, receiver state before data exchange
  • flow controlled
  • sender will not overwhelm receiver

18
TCP segment structure
URG urgent data (generally not used)
counting by bytes of data (not segments!)
ACK ACK valid
PSH push data now (generally not used)
bytes rcvr willing to accept
RST, SYN, FIN connection estab (setup,
teardown commands)
Internet checksum (as in UDP)
19
TCP reliable data transfer
  • TCP creates rdt service on top of IPs unreliable
    service
  • Pipelined segments
  • Cumulative acks
  • TCP uses single retransmission timer
  • Retransmissions are triggered by
  • timeout events
  • duplicate acks
  • Initially consider simplified TCP sender
  • ignore duplicate acks
  • ignore flow control, congestion control

20
TCP sender events
  • timeout
  • retransmit segment that caused timeout
  • restart timer
  • Ack rcvd
  • If acknowledges previously unacked segments
  • update what is known to be acked
  • start timer if there are outstanding segments
  • data rcvd from app
  • Create segment with seq
  • seq is byte-stream number of first data byte in
    segment
  • start timer if not already running (think of
    timer as for oldest unacked segment)
  • expiration interval TimeOutInterval

21
TCP sender(simplified)
NextSeqNum InitialSeqNum
SendBase InitialSeqNum loop (forever)
switch(event) event
data received from application above
create TCP segment with sequence number
NextSeqNum if (timer currently
not running) start timer
pass segment to IP
NextSeqNum NextSeqNum length(data)
event timer timeout
retransmit not-yet-acknowledged segment with
smallest sequence number
start timer event ACK
received, with ACK field value of y
if (y gt SendBase)
SendBase y if (there are
currently not-yet-acknowledged segments)
start timer
/ end of loop forever /
22
TCP retransmission scenarios
Host A
Host B
Seq92, 8 bytes data
Seq100, 20 bytes data
ACK100
ACK120
Seq92, 8 bytes data
Sendbase 100
SendBase 120
ACK120
Seq92 timeout
SendBase 100
SendBase 120
premature timeout
23
TCP retransmission scenarios (more)
SendBase 120
24
TCP Round Trip Time and Timeout
  • If TCP timeout is
  • too short premature timeout ? unnecessary
    retransmissions
  • too long slow reaction to segment loss
  • Q how to set TCP timeout value?
  • Based on Round Trip Time (RTT), but RTT itself
    varies with time!
  • We need to estimate current RTT
  • RTT Estimation
  • SampleRTT measured time from segment
    transmission until ACK receipt
  • ignore retransmissions
  • SampleRTT will vary, want estimated RTT
    smoother
  • average several recent measurements, not just
    current SampleRTT

25
TCP Round Trip Time and Timeout
EstimatedRTT (1- ?)EstimatedRTT ?SampleRTT
  • Exponential weighted moving average
  • influence of past sample decreases exponentially
    fast
  • typical value ? 0.125

26
Example RTT estimation
27
TCP Round Trip Time and Timeout
  • Setting the timeout
  • EstimtedRTT plus safety margin
  • large variation in EstimatedRTT -gt larger safety
    margin
  • first estimate how much SampleRTT deviates from
    EstimatedRTT

DevRTT (1-?)DevRTT ?SampleRTT
- EstimatedRTT (typically, ? 0.25)
Then set timeout interval
TimeoutInterval EstimatedRTT 4DevRTT
28
Fast Retransmit
  • Time-out period often relatively long
  • long delay before resending lost packet
  • Detect lost segments via duplicate ACKs.
  • Sender often sends many segments back-to-back
  • If segment is lost, there will likely be many
    duplicate ACKs.
  • If sender receives 3 ACKs for the same data, it
    supposes that segment after ACKed data was lost
  • fast retransmit resend segment before timer
    expires

29
TCP Connection Management opening
  • TCP 3-way handshake
  • Step 1 client host sends TCP SYN segment to
    server
  • specifies initial seq
  • no data
  • Step 2 server host receives SYN, replies with
    SYNACK segment
  • server allocates buffers
  • specifies server initial seq.
  • Step 3 client receives SYNACK, replies with ACK
    segment, which may contain data

A. SYN Flood DoS attack
Q. How would a hacker exploit TCP 3-way handshake
to bring a server down?
30
TCP Connection Management closing
  • Step 1 client end system sends TCP FIN segment
    to server
  • Step 2 server receives FIN, replies with ACK.
    Closes connection, sends FIN
  • Step 3 client receives FIN, replies with ACK
  • Enters timed wait may need to re-send ACK to
    received FINs
  • Step 4 server, receives ACK Connection closed

31
TCP Connection Management
TCP server lifecycle
TCP client lifecycle
32
TCP Flow Control
  • receive side of TCP connection has a receive
    buffer
  • speed-matching service matching the send rate to
    the receiving apps drain rate
  • app process may be slow at reading from buffer

33
TCP Flow control how it works
  • Rcvr advertises spare room by including value of
    RcvWindow in segments
  • Sender limits unACKed data to RcvWindow
  • guarantees receive buffer doesnt overflow
  • (Suppose TCP receiver discards out-of-order
    segments)
  • spare room in buffer
  • RcvWindow
  • RcvBuffer-LastByteRcvd - LastByteRead

34
Congestion Control
  • Congestion sources send too much data for
    network to handle
  • different from flow control, which is e2e
  • Congestion results in
  • lost packets (buffer overflow at routers)
  • more work (retransmissions) for given goodput
  • long delays (queueing in router buffers)
  • Premature (unneeded) retransmissions
  • Waste of upstream links capacity
  • Pkt traversed several links, then dropped at
    congested router

35
Approaches towards congestion control
Two broad approaches towards congestion control
  • Network-assisted congestion control
  • routers provide feedback to end systems
  • single bit indicating congestion (SNA, DECbit,
    TCP/IP ECN, ATM)
  • explicit rate sender should send at
  • End-end congestion control
  • no explicit feedback from network
  • congestion inferred from end-system observed
    loss, delay
  • approach taken by TCP

36
TCP congestion control Approach
  • Approach probe for usable bandwidth in network
  • increase transmission rate until loss occurs then
    decrease
  • Additive increase, multiplicative decrease (AIMD)

Saw tooth behavior probing for bandwidth
Rate (CongWin)
time
37
TCP Congestion Control
  • Sender keeps a new variable, Congestion Window
    (CongWin), and limits unacked bytes to
  • LastByteSent - LastByteAcked ? min CongWin,
    RcvWin
  • For our discussion assume RcvWin is large enough
  • Roughly, what is the sending rate as a function
    of CongWin?
  • Ignore loss and transmission delay
  • Rate CongWin/RTT (bytes/sec)
  • So, rate and CongWin are somewhat synonymous

38
TCP Congestion Control
  • Congestion occurs at routers (inside the network)
  • Routers do not provide any feedback to TCP
  • How can TCP infer congestion?
  • From its symptoms timeout or duplicate acks
  • Define loss event timeout or 3 duplicate acks
  • TCP decreases its CongWin (rate) after a loss
    event
  • TCP Congestion Control Algorithm three
    components
  • AIMD additive increase, multiplicative decrease
  • slow start
  • Reaction to timeout events

39
AIMD
  • additive increase (congestion avoidance phase)
  • increase CongWin by 1 MSS every RTT until loss
    detected
  • TCP increases CongWin by MSS x (MSS/CongWin) for
    every ACK received
  • Ex. MSS 1,460 bytes and CongWin 14,600 bytes
  • With every ACK, CongWin is increased by 146 bytes
  • multiplicative decrease
  • cut CongWin in half after loss

40
TCP Slow Start
  • When connection begins, CongWin 1 MSS
  • Example MSS 500 bytes RTT 200 msec
  • initial rate CongWin/RTT 20 kbps
  • available bandwidth may be gtgt MSS/RTT
  • desirable to quickly ramp up to respectable rate
  • Slow start
  • When connection begins, increase rate
    exponentially fast until first loss event. How
    can we do that?
  • double CongWin every RTT. How?
  • Increment CongWin by 1 MSS for every ACK received

41
TCP Slow Start (contd)
  • Increment CongWin by 1 MSS for every ACK
  • Summary initial rate is slow but ramps up
    exponentially fast

Host A
Host B
one segment
RTT
two segments
four segments
42
Reaction to a Loss event
  • TCP Tahoe (Old)
  • Threshold CongWin / 2
  • Set CongWin 1
  • Slow start till threshold
  • Then Additive Increase // congestion
    avoidance
  • TCP Reno (most current TCP implementations)
  • If 3 dup acks // fast
    retransmit
  • Threshold CongWin / 2
  • Set CongWin Threshold // fast recovery
  • Additive Increase
  • Else //
    timeout
  • Same as TCP Tahoe

43
Reaction to a Loss event (contd)
3 dup acks
  • Why differentiate between 3 dup acks and timeout?
  • 3 dup ACKs indicate network capable of
    delivering some segments
  • timeout indicates a more alarming congestion
    scenario

44
TCP Congestion Control Summary
  • Initially
  • Threshold is set to large value (65 Kbytes), has
    no effect
  • CongWin 1 MSS
  • Slow Start (SS) CongWin grows exponentially
  • till a loss event occurs (timeout or 3 dup ack)
    or reaches Threshold
  • Congestion Avoidance (CA) CongWin grows
    linearly
  • 3 duplicate ACK occurs
  • Threshold CongWin/2 CongWin Threshold CA
  • Timeout occurs
  • Threshold CongWin/2 CongWin 1 MSS SS till
    Threshold

45
TCP throughput
  • Whats the average throughout of TCP as a
    function of window size and RTT?
  • Ignore slow start
  • Let W be the window size when loss occurs
  • When window is W, throughput is W/RTT
  • Just after loss, window drops to W/2, throughput
    to W/2RTT
  • Average throughout 0.75 W/RTT
About PowerShow.com