TCP and Congestion Control by hli12090

VIEWS: 192 PAGES: 36

									     TCP and Congestion Control

                      October 7-9, 2003




10/7/2003-10/9/2003
                      Assignments
• Finish chapter 3
• Finish up your project!




10/7/2003-10/9/2003
                      TCP: Overview
• Point-to-Point
     – one sender, one receiver
• Connection-oriented
     – handshaking (exchange of control msgs)
•   Reliable, in order data delivery
•   Pipelined
•   Full duplex data
•   Flow controlled
     – sender will not overwhelm receiver



10/7/2003-10/9/2003
                           TCP Example
                           application              application
                           writes data              reads data
                  socket                                            socket
                   door                                              door
                              TCP                      TCP
                           send buffer             receive buffer
                                         segment




• Application data placed in send buffer
• Data taken from send buffer and placed in
  segment (data + header)
     – Max amount of data is MSS
• Data placed in receive buffer
• App reads from receiver buffer
• Applet
10/7/2003-10/9/2003
              TCP Segment Structure
                                       32 bits
  URG: urgent data                                              counting
(generally not used)     source port #         dest port #
                                                                by bytes
                                sequence number                 of data
       ACK: ACK #
             valid          acknowledgement number              (not segments!)
                        head not
PSH: push data now       len used
                                  UA P R S F   Receive window
(generally not used)                                              # bytes
                            checksum           Urg data pnter
                                                                  rcvr willing
    RST, SYN, FIN:                                                to accept
                            Options (variable length)
   connection estab
   (setup, teardown
         commands)
                                      application
           Internet                      data
          checksum                 (variable length)
        (as in UDP)


  10/7/2003-10/9/2003
                      Seq #’s and ACKs
                                          Host A           Host B
• Seq #’s
                                User
     – Byte stream “number”     types
       of first byte in           ‘C’
       segment’s data                                            host ACKs
                                                                 receipt of
     – First is randomly                                         ‘C’, echoes
       chosen                                                      back ‘C’

• ACKs
                              host ACKs
     – Seq # of next byte      receipt
       expected from other    of echoed
       side                       ‘C’
     – Cumulative ACK
     – Piggybacking                                                       time
                                              simple telnet scenario
10/7/2003-10/9/2003
   Round Trip Time and Timeout
• TCP uses timeout mechanism
• How can we determine the timeout value?
     – Must be longer than RTT
     – Too short?
     – Too long?
• Take SampleRTT – but RTT varies



10/7/2003-10/9/2003
   Round Trip Time and Timeout
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT

        • Exponential weighted moving average
        • Influence of past sample decreases
          exponentially fast
        • Typical value:  = 0.125




10/7/2003-10/9/2003
                                Example RTT Estimation
                                                   RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

                      350




                      300




                      250
 RTT (milliseconds)




                      200




                      150




                      100
                            1   8   15   22   29     36      43      50       57        64     71   78   85   92   99   106
                                                                      time (seconnds)

                                                               SampleRTT           Estimated RTT

10/7/2003-10/9/2003
   Round Trip Time and Timeout

         TimeoutInterval = EstimatedRTT + 4*DevRTT



• Timeout also takes into account how much the
  EstimatedRTT deviates from the SampleRTT




10/7/2003-10/9/2003
      TCP Reliable Data Transfer
• TCP creates rdt service on top of IP’s unreliable
  service
     – Reliable, in order delivery
• Pipelined segments
• Cumulative acks
• TCP uses single retransmission timer
     – Retransmit triggered by timeout and duplicate ACK


• Consider simplified design
     – No duplicate ACKs, flow control, or congestion control
10/7/2003-10/9/2003
                  TCP Sender Events
• Data received 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
• 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


10/7/2003-10/9/2003
                   Retransmit Scenarios
                Host A       Host B                                 Host A      Host B




                                                  Seq=92 timeout
      timeout




                         X
                     loss

                                      Sendbase
                                        = 100




                                                   Seq=92 timeout
                                       SendBase
                                         = 120


SendBase
  = 100                               SendBase
                                        = 120                            premature timeout
        time                                      time
                  lost ACK scenario
  10/7/2003-10/9/2003
                      Retransmit Scenarios
                     Host A       Host B
           timeout




                              X
                          loss

SendBase
  = 120




             time
                 Cumulative ACK scenario

  10/7/2003-10/9/2003
                  TCP ACK Generation
   Event at Receiver                   TCP Receiver action
   Arrival of in-order segment with    Delayed ACK. Wait up to 500ms
   expected seq #. All data up to      for next segment. If no next segment,
   expected seq # already ACKed        send ACK

   Arrival of in-order segment with    Immediately send single cumulative
   expected seq #. One other           ACK, ACKing both in-order segments
   segment has ACK pending

   Arrival of out-of-order segment     Immediately send duplicate ACK,
   higher-than-expect seq. # .         indicating seq. # of next expected byte
   Gap detected

   Arrival of segment that             Immediate send ACK, provided that
   partially or completely fills gap   segment starts at lower end of gap
10/7/2003-10/9/2003
                      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
10/7/2003-10/9/2003
                      TCP Flow Control




• Need to keep sender from sending too fast for
  receiver

• Match sending rate with receiver “drain” rate

10/7/2003-10/9/2003
                         Operation



RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead]
• Rcvr advertises spare room by including value of
  RcvWindow in segments
• Sender limits unACKed data to RcvWindow
     – guarantees receive buffer doesn’t overflow
• Sender actually continues to send 1-byte pkts after
  receiver window is full – WHY?

10/7/2003-10/9/2003
   TCP Connection Management
• Sender and receiver establish “connection”
  before exchanging data segments
• Initialize TCP variables
     – seq. #s
     – buffers, flow control info (e.g. RcvWindow)
• Client initiates connection
     – Socket clientSocket = new Socket("hostname","port
       number");
• Server accepts connection
     – Socket connectionSocket = welcomeSocket.accept();

10/7/2003-10/9/2003
   TCP Connection Management
• Three 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


10/7/2003-10/9/2003
               Three-way Handshake

                                   client   server

                      Connection
                       Request
                                                     Connection
                                                      Granted


                          ACK




10/7/2003-10/9/2003
   TCP Connection Management
• 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.
     – 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.

10/7/2003-10/9/2003
                                       Teardown
                                       client   server

                        close



                                                         close
                          timed wait




                      closed


10/7/2003-10/9/2003
Principles of Congestion Control
• Congestion
     – informally: “too many sources sending too
       much data too fast for network to handle”
     – different from flow control!
• Manifestations
     – lost packets (buffer overflow at routers)
     – long delays (queueing in router buffers)


10/7/2003-10/9/2003
        Scenario 1: Queuing Delays
                                  Host A
                                           lin : original data                         lout
• two senders, two
  receivers
                         Host B                                   unlimited shared
• one router, infinite                                           output link buffers


  buffers
• no retransmission


                                                                   • large delays
                                                                     when congested
                                                                   • maximum
                                                                     achievable
                                                                     throughput
  10/7/2003-10/9/2003
               Scenario 2: Retransmits
• One router, finite buffers
• Sender retransmission of lost packet
   – Original packet dropped
   – Original packet delayed
                               Host A   lin : original                   lout
                                        data
                                        l'in : original data, plus
                                              retransmitted data

                      Host B                     finite shared output
                                                          link buffers




10/7/2003-10/9/2003
        Scenario 3: Congestion Near
                 Receiver
• four senders
• multihop paths
                           Host A                                     lout
                                    lin : original data
• timeout/retransmit
                                    l'in : original data, plus
                                          retransmitted data

                                              finite shared output
                                                       link buffers


                  Host B




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


10/7/2003-10/9/2003
           TCP Congestion Control
• End-end control (no network assistance)

• Sender limits transmission
LastByteSent-LastByteAcked  CongWin

• CongWin is dynamic, function of perceived
  network congestion
• Different than the RcvWindow
10/7/2003-10/9/2003
           TCP Congestion Control
• How does sender perceive congestion?
     – loss event = timeout or 3 duplicate acks
     – Is this always a good measure?
     – TCP sender reduces rate (CongWin) after
       loss event
• Three components of CC algorithm
     – AIMD
     – slow start
     – conservative after timeout events
10/7/2003-10/9/2003
TCP AIMD – Congestion Avoidance
 • Additive Increase                                  • Multiplicative
      – increase CongWin                                Decrease
        by 1 MSS every RTT                                – cut CongWin in half
        in the absence of                                   after loss event
        loss events: probing
                            congestion
                              window

                   24 Kbytes




                   16 Kbytes




                       8 Kbytes




                                                                         time
 10/7/2003-10/9/2003
                                    Long-lived TCP connection
                      TCP Slow Start
• When connection begins, CongWin = 1 MSS
     – Example: MSS = 500 bytes & RTT = 200 msec
     – initial rate = 20 kbps
• Available bandwidth may be >> MSS/RTT
     – desirable to quickly ramp up to respectable rate
• When connection begins, increase rate
  exponentially fast until first loss event
     – Double CongWin every RTT until a loss
     – After loss – reduce CongWin by ½ and increase
       linerarly
10/7/2003-10/9/2003
                  Slow Start Example
                                    Host A   Host B




                              RTT
• Double CongWin
  every RTT
     – done by incrementing
       CongWin for every
       ACK received


                                                      time

10/7/2003-10/9/2003
                      Timeout Events
• After 3 dup ACKs
     – CongWin is cut in half
     – window then grows linearly
• But, after timeout event
     – CongWin instead set to 1 MSS
     – window then grows exponentially to a threshold (1/2
       previous CongWin size), then grows linearly
• Idea – 3 dup ACKs indicates network capable of
  delivering some segments
   – timeout before 3 dup ACKs is “more alarming”
10/7/2003-10/9/2003
                      Threshold

• Threshold
   – Starts at 65K                                14




                         congestion window size
                                                  12
   – Set to ½ CongWin                             10




                               (segments)
     when loss event                              8

     occurs                                       6
                                                  4
• TCP Tahoe vs TCP                                2

  Reno                                            0
                                                       1   2 3   4 5   6 7       8 9 10 11 12 13 14 15
                                                                   Transmission round

                                                                       Series1       Series2




10/7/2003-10/9/2003
Summary: TCP Congestion Control
• When CongWin is below Threshold, sender in
  slow-start phase, window grows exponentially
• When CongWin is above Threshold, sender is in
  congestion-avoidance phase, window grows
  linearly
• When a triple duplicate ACK occurs, Threshold
  set to CongWin/2 and CongWin set to Threshold
• When timeout occurs, Threshold set to
  CongWin/2 and CongWin is set to 1 MSS

10/7/2003-10/9/2003

								
To top