PowerPoint - DePaul University

Document Sample
PowerPoint - DePaul University Powered By Docstoc
					  Internetworking Technologies




      Transmission Control Protocol (TCP)




TDC365 Spring 2001   John Kristoff - DePaul University   1
                           IP review

•   IP provides just enough 'connectedness'
    •   Global addressing
    •   Hop-by-hop routing
•   IP over everything
    •   Ethernet, ATM, X.25, SONET, etc.
•   Lack of state in the network
•   Unreliable packet (datagram) switching

    TDC365 Spring 2001   John Kristoff - DePaul University   2
                         TCP key features

•   Sequencing
•   Byte-stream delivery
•   Connection-oriented
•   Reliability




    TDC365 Spring 2001     John Kristoff - DePaul University   3
            TCP feature summary


    Provides a completely reliable (no data
    duplication or loss), connection-oriented,
     full-duplex stream transport service that
    allows two application programs to form a
     connection, send data in either direction
        and then terminate the connection.


TDC365 Spring 2001   John Kristoff - DePaul University   4
              Apparent contradiction

•   IP offers best-effort (unreliable) delivery
•   TCP uses IP
•   TCP provides completely reliable transfer
•   How is this possible?




    TDC365 Spring 2001   John Kristoff - DePaul University   5
                   Achieving reliability

•   Reliable connection startup
•   Reliable data transfer
    •   Sender starts a timer
    •   Receiver sends ACK when data arrives
    •   Sender retransmits if timer expires before
        ACK is returned
•   Reliable connection shutdown

    TDC365 Spring 2001   John Kristoff - DePaul University   6
              Reliability illustrated




TDC365 Spring 2001   John Kristoff - DePaul University   7
              How long to wait before
                 retransmitting?
•   Time for ACK to return depends on:
    •   Distance between sender/receiver
    •   Network traffic conditions
    •   End system conditions
•   Packets can be lost, damaged or fragmented
•   Traffic conditions can change rapidly



    TDC365 Spring 2001   John Kristoff - DePaul University   8
         Solving the retransmission
                  problem
•   Keep running average of round trip time
    (RTT) for each TCP connection
•   Current average (estimate) determines
    retransmission timer
•   How does each RTT affect the average?
•   This is known as adaptive retransmission
•   Key to TCP's success


    TDC365 Spring 2001   John Kristoff - DePaul University   9
Adaptive retranmission illustrated




 TDC365 Spring 2001   John Kristoff - DePaul University   10
                         Flow control

"   Match sending rate to receiver rate
•   TCP uses a sliding window
    •   Receiver advertises available buffer space
    •   Also known as the window
    •   Sender can transmit a full window size before
        receiving an ACK




    TDC365 Spring 2001   John Kristoff - DePaul University   11
               Window advertisement

"   Each ACK carries the current window size
    –   Called the window advertisement
    –   Can be zero (a closed window)
"   Interpretation of window advertisement:
    –   Receiver: I can accept X octets or less unless I
        tell you otherwise




    TDC365 Spring 2001   John Kristoff - DePaul University   12
Window advertisement illustrated




TDC365 Spring 2001   John Kristoff - DePaul University   13
Another view: the sliding window




TDC365 Spring 2001   John Kristoff - DePaul University   14
             Byte stream sequencing

•   Each segment contains a sequence number
•   Sequencing helps ensure in-order delivery
•   TCP sequence numbers are fixed at 32 bits
•   Is the byte stream of limited size (232 bytes)?
•   Initial sequence numbers (ISN) are
    exchanged at connection startup
•   ACKs acknowledgement cumulative bytes

    TDC365 Spring 2001   John Kristoff - DePaul University   15
              TCP segment format




TDC365 Spring 2001   John Kristoff - DePaul University   16
             Application multiplexing

•   Separation of functionality from IP
    •   In the beginning TCP and IP were one
    •   No unused bits to encode application process
•   Cannot use OS dependent quality
    •   Process ID
    •   Task number
    •   Job name
•   Semantics must work on all end systems
    TDC365 Spring 2001   John Kristoff - DePaul University   17
                         Port numbers

•   Separation of functionality from IP
    •   In the beginning TCP and IP were one
    •   No unused bits to encode application process
•   Cannot use OS dependent quality
    •   Process ID
    •   Task number
    •   Job name
•   Semantics must work on all end systems
    TDC365 Spring 2001    John Kristoff - DePaul University   18
                          TCP ports

•   Each application assigned a unique integer
•   Server
    •   Follows a standard (e.g. Well know ports)
    •   Uses a well known port number
    •   Usually uses lower port numbers
•   Client
    •   Obtains unused port from protocol software
    •   Usually uses high numbered ports
    TDC365 Spring 2001   John Kristoff - DePaul University   19
              TCP connection startup
• Uses a three message exchange
    • AKA 3-way handshake

•   Necessary and sufficient for unambiguous
    and reliable startup
•   Sequence number exchange is primary goal
•   Can also exchange other parameters
    •   e.g. maximum segment size


    TDC365 Spring 2001   John Kristoff - DePaul University   20
    3-way handshake illustrated




TDC365 Spring 2001   John Kristoff - DePaul University   21
      TCP connection shutdown




TDC365 Spring 2001   John Kristoff - DePaul University   22
                         Congestion

•   Flow control
•   Congestion control
•   Avoidance




    TDC365 Spring 2001   John Kristoff - DePaul University   23
     Useful terms before proceding

•   Maximum segment size (MSS)
•   Window
•   Retransmission
•   Timer
•   Delayed ACK
•   Duplicate ACK


    TDC365 Spring 2001   John Kristoff - DePaul University   24
                   Congestion window

•   Sender based flow control
    •   Rather than by a window advertisement
•   Sender uses min(cwnd, advertised window)
    •   This is the transmission window
•   Infer network conditions and adjust
•   Use timers, ACKs and network feedback


    TDC365 Spring 2001   John Kristoff - DePaul University   25
        TCP segment retransmission

•   TCP starts timer after sending a segment
•   If ACK returns, reset timer
•   If not, retransmit and set (timer = timer x 2)
    •   This is backoff
•   Can't retransmit forever, error may occur
•   Timer is the estimate of round trip time (RTT)
    •   Current, running average of RTT

    TDC365 Spring 2001   John Kristoff - DePaul University   26
                Round trip time (RTT)

•   TCP measures RTT
•   TCP uses estimated RTT to calculate timers
•   If ACKs return quickly, timers are short
    •   If loss occurs, recovery is quicker
•   The converse is also true
•   RTT too high = throughput suffers
•   RTT too low = unnecessary retransmits

    TDC365 Spring 2001   John Kristoff - DePaul University   27
                         TCP slow start

•   Initialize cwnd to 1 MSS
•   Increase cwnd by 1
    MSS for every ACK
•   Not really that slow




    TDC365 Spring 2001    John Kristoff - DePaul University   28
          TCP congestion avoidance

•   When timer expires (loss?), slow down!
    •   Set ssthresh = (transmission window x ½)
    •   Set cwnd = 1
    •   Transmit min(cwnd, transmission window)
    •   Slow start until transmission window = sshtresh
    •   Thereafter, increase cwnd by 1/cwnd per ACK




    TDC365 Spring 2001   John Kristoff - DePaul University   29
Congestion avoidance illustrated




TDC365 Spring 2001   John Kristoff - DePaul University   30
                   TCP fast retransmit

•   If 3 or more duplicate ACKs are received
    before timer has expired
•   Sender assumes loss
    •   Assumes out of order packets had enough time
        to be reassembled
•   Retransmit without waiting for timer to expire
•   Enter TCP fast recovery


    TDC365 Spring 2001   John Kristoff - DePaul University   31
                     TCP fast recovery

•   Sender assumes data is still flowing
    •   Due to the reception of duplicate ACKs
•   Loss was probably a temporary event
•   Go into congestion avoidance, not slow start
    •   Just cut cwnd in half
    •   Resume additive increase (1/cwnd) per ACK




    TDC365 Spring 2001   John Kristoff - DePaul University   32
                     Other mechanisms

•   Selective acknowledgements (SACK)
•   Traffic shaping
•   ACK pacing
•   AQM (FIFO and RED and variants)
•   ECN, ICMP source quench, back pressure
•   Fair queueing
•   Class/uality of service (CoS/QoS)

     TDC365 Spring 2001   John Kristoff - DePaul University   33
                   Congestion collapse

•   When network load increases and less actual work
    gets done due to packet drops
•   Fragmented packets are especially bad
•   As retransmissions increase, goodput drops




     TDC365 Spring 2001   John Kristoff - DePaul University   34

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:5/19/2013
language:Unknown
pages:34