TCP

Document Sample
TCP Powered By Docstoc
					                                                                       1

                 Transport Layer
Our goals:
• understand principles           • learn about transport layer
  behind transport                  protocols in the Internet:
  layer services:                         – UDP: connectionless
   – multiplexing/demulti                   transport
     plexing                              – TCP: connection-oriented
   – reliable data transfer                 transport
   – flow control                         – TCP congestion control
   – congestion control


                  Ref: slides by J. Kurose and K. Ross
                                Xin Liu
                                           2

                           Outline
•   Transport-layer services
•   Multiplexing and demultiplexing
•   Connectionless transport: UDP
•   Principles of reliable data transfer
•   Connection-oriented transport: TCP
    –   segment structure
    –   reliable data transfer
    –   flow control
    –   connection management
• Principles of congestion control
• TCP congestion control




                                 Xin Liu
                                                                                                    3


   Transport services and protocols
• provide logical communication         application
                                        transport
  between app processes running on       network
                                         data link                network
  different hosts                        physical                 data link
                                                      network     physical
• transport protocols run in end                      data link
                                                      physical
  systems                                                          network
                                                                   data link
    – send side: breaks app                                        physical          network
                                                                                     data link
      messages into segments,                                                        physical

                                                                         network
      passes to network layer                                            data link
                                                                         physical
    – rcv side: reassembles segments
      into messages, passes to app                                                    application
                                                                                      transport
      layer                                                                            network
                                                                                       data link
                                                                                       physical
• more than one transport protocol
  available to apps
    – Internet: TCP and UDP


                                  Xin Liu
                                                                        4

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

                              Xin Liu
                                                                                                       5

  Internet transport-layer protocols
• reliable, in-order delivery              application
                                           transport
                                            network
  (TCP)                                     data link                network
                                            physical                 data link
   – congestion control                                  network     physical
                                                         data link
   – flow control                                        physical
                                                                      network
                                                                      data link
   – connection setup                                                 physical          network
                                                                                        data link
• unreliable, unordered                                                                 physical

                                                                            network
  delivery: UDP                                                             data link
                                                                            physical
   – no-frills extension of “best-
                                                                                         application
     effort” IP                                                                          transport
                                                                                          network
• services not available:                                                                 data link
                                                                                          physical

   – delay guarantees
   – bandwidth guarantees


                                     Xin Liu
                                           6

                           Outline
•   Transport-layer services
•   Multiplexing and demultiplexing
•   Connectionless transport: UDP
•   Principles of reliable data transfer
•   Connection-oriented transport: TCP
    –   segment structure
    –   reliable data transfer
    –   flow control
    –   connection management
• Principles of congestion control
• TCP congestion control




                                 Xin Liu
                                                                                  7


         Multiplexing/demultiplexing
Demultiplexing at rcv host:                     Multiplexing at send host:
                                               gathering data from multiple
delivering received segments
                                               sockets, enveloping data with
to correct socket
                                               header (later used for
                                               demultiplexing)
        = socket        = process


                   P3    P1
                          P1                     P2          P4    application
 application                   application

 transport                      transport                           transport

 network                            network                          network

 link                                 link                                 link

 physical                           physical                         physical

                                    host 2                        host 3
        host 1

                                    Xin Liu
                                                                           8

           How demultiplexing works
• host receives IP datagrams
   – each datagram has source IP                       32 bits
      address, destination IP address
                                             source port #   dest port #
   – each datagram carries 1
      transport-layer segment
   – each segment has source,                   other header fields
      destination port number
      (recall: well-known port
      numbers for specific                          application
      applications)                                   data
• host uses IP addresses & port                     (message)
  numbers to direct segment to
  appropriate socket
                                              TCP/UDP segment format


                                   Xin Liu
                                                                    9

  Connectionless demultiplexing
• Create sockets :
                                         • When host receives UDP
sock=socket(PF_INET,SOCK_DGR
  AM, IPPROTO_UDP);            segment:
bind(sock,(struct sockaddr      – checks destination port number
  *)&addr,sizeof(addr));          in segment
sendto(sock,buffer,size,0);     – directs UDP segment to socket
                                  with that port number
recvfrom(sock,Buffer,buffers
  ize,0);                    • IP datagrams with different
                                           source IP addresses and/or
• UDP socket identified by                 source port numbers directed
   two-tuple:                              to same socket
(dest IP address, dest port number)



                               Xin Liu
                                                                    10

        Connection-oriented demux

• TCP socket identified        • Server host may support
  by 4-tuple:                    many simultaneous TCP
   –   source IP address         sockets:
   –   source port number             – each socket identified by
   –   dest IP address                  its own 4-tuple
   –   dest port number        • Web servers have
• recv host uses all four        different sockets for
  values to direct               each connecting client
  segment to appropriate              – non-persistent HTTP will
  socket                                have different socket for
                                        each request
                            Xin Liu
                                           11

                           Outline
•   Transport-layer services
•   Multiplexing and demultiplexing
•   Connectionless transport: UDP
•   Principles of reliable data transfer
•   Connection-oriented transport: TCP
    –   segment structure
    –   reliable data transfer
    –   flow control
    –   connection management
• Principles of congestion control
• TCP congestion control




                                 Xin Liu
                                                                          12


 UDP: User Datagram Protocol [RFC 768]
• “no frills,” “bare bones”
  Internet transport protocol          Why is there a UDP?
• “best effort” service, UDP           • no connection establishment
  segments may be:                       (which can add delay)
   – lost                              • simple: no connection state at
   – delivered out of order to           sender, receiver
      app                              • small segment header
• connectionless:                      • no congestion control: UDP can
   – no handshaking between              blast away as fast as desired
      UDP sender, receiver
   – each UDP segment handled
      independently of others




                                 Xin Liu
                                                                          13
DHCP client-server scenario
DHCP server: 223.1.2.5                                         arriving
                                DHCP discover
                                                                client
                                 src : 0.0.0.0, 68
                                 dest.: 255.255.255.255,67
                                 yiaddr: 0.0.0.0
                                 transaction ID: 654

                                  DHCP offer
                                   src: 223.1.2.5, 67
                                   dest: 255.255.255.255, 68
                                   yiaddrr: 223.1.2.4
                                   transaction ID: 654
                                   Lifetime: 3600 secs
            DHCP request
              src: 0.0.0.0, 68
              dest:: 255.255.255.255, 67
              yiaddrr: 223.1.2.4
              transaction ID: 655
    time      Lifetime: 3600 secs

                                 DHCP ACK
                                   src: 223.1.2.5, 67
                                   dest: 255.255.255.255, 68
                                   yiaddrr: 223.1.2.4
                                   transaction ID: 655
                                   Lifetime: 3600 secs



                                 Xin Liu
                                                             14

         Applications and protocols
application              App_layer prtcl   Transport prtcl
E-mail                   SMTP              TCP
Remote terminal access   Telnet            TCP
Web                      HTTP              TCP
File transfer            FTP               TCP
Streaming                proprietary       Typically UDP
IP-phone                 proprietary       Typically UDP
Routing                  RIP               Typically UDP
Name translation         DNS               Typically UDP
Dynamic IP               DHCP              Typically UDP
Network mng.             SNMP              Typically UDP
                               Xin Liu
                                                                          15


                         UDP: more
• often used for streaming                           32 bits
  multimedia apps
                            Length, in   source port #    dest port #
   – loss tolerant
                         bytes of UDP       length             checksum
   – rate sensitive          segment,
                             including
• reliable transfer over       header
  UDP: add reliability at
  application layer                             Application
   – application-specific                         data
                                                (message)
      error recovery!

                                            UDP segment format


                               Xin Liu
                                                  16

                Checksum
• Goal: detect “errors” (e.g., flipped bits) in
  transmitted segment
• UDP header and data, and part of IP header
• Pseudo header
  – Source/dest IP address
  – Protocol, length
• Same procedure for TCP



                      Xin Liu
                                                                   17

               UDP checksum

Sender:                            Receiver:
• treat segment contents as        • compute checksum of
  sequence of 16-bit                 received segment
  integers                         • check if computed
• checksum: addition (1’s            checksum equals checksum
  complement sum) of                 field value:
  segment contents                    – NO - error detected
• sender puts checksum                – YES - no error detected.
  value into UDP                         But maybe errors
  checksum field                         nonetheless?
                                      – may pass the damaged
                                         data
                              Xin Liu
                                           18

                           Outline
•   Transport-layer services
•   Multiplexing and demultiplexing
•   Connectionless transport: UDP
•   Principles of reliable data transfer
•   Connection-oriented transport: TCP
    –   segment structure
    –   reliable data transfer
    –   flow control
    –   connection management
• Principles of congestion control
• TCP congestion control




                                 Xin Liu
                                                          19

    Principles of Reliable data transfer
• important in app., transport, link layers
• top-10 list of important networking topics!




 • characteristics of unreliable channel will determine
   complexity of reliable data transfer protocol (rdt)
                              Xin Liu
                                                                                20

      Reliable data transfer: getting started

rdt_send(): called from above,                deliver_data(): called by
  (e.g., by app.). Passed data to             rdt to deliver data to upper
 deliver to receiver upper layer




      send                                                      receive
      side                                                        side




 udt_send(): called by rdt,                   rdt_rcv(): called when packet
   to transfer packet over                     arrives on rcv-side of channel
unreliable channel to receiver

                                    Xin Liu
                                                                              21

    Reliable data transfer: getting started
We’ll:
• incrementally develop sender, receiver sides of reliable
  data transfer protocol (rdt)
• consider only unidirectional data transfer
   – but control info will flow on both directions!
• use finite state machines (FSM) to specify sender,
  receiver
                                   event causing state transition
                                  actions taken on state transition
  state: when in this
   “state” next state     state                                       state
                            1                event
uniquely determined
                                             actions                    2
       by next event


                                   Xin Liu
                                                                                  22


   Rdt1.0: reliable transfer over a reliable channel
• underlying channel perfectly reliable
   – no bit errors
   – no loss of packets
• separate FSMs for sender, receiver:
   – sender sends data into underlying channel
   – receiver read data from underlying channel
  Wait for    rdt_send(data)                 Wait for     rdt_rcv(packet)
  call from                                  call from    extract (packet,data)
   above      packet = make_pkt(data)         below       deliver_data(data)
              udt_send(packet)


              sender                                     receiver

                                   Xin Liu
                                                                          23


     Rdt2.0: channel with bit errors
• underlying channel may flip bits in packet
   – recall: UDP checksum to detect bit errors
• the question: how to recover from errors:
   – acknowledgements (ACKs): receiver explicitly tells sender that pkt
     received OK
   – negative acknowledgements (NAKs): receiver explicitly tells sender
     that pkt had errors
   – sender retransmits pkt on receipt of NAK
   – human scenarios using ACKs, NAKs?
• new mechanisms in rdt2.0 (beyond rdt1.0):
   – error detection
   – receiver feedback: control msgs (ACK,NAK) rcvr->sender



                             Xin Liu
                                                                          24

            rdt2.0: FSM specification
    rdt_send(data)
   snkpkt = make_pkt(data, checksum)                    receiver
   udt_send(sndpkt)
                             rdt_rcv(rcvpkt) &&
                               isNAK(rcvpkt)
Wait for           Wait for                          rdt_rcv(rcvpkt) &&
call from          ACK or     udt_send(sndpkt)        corrupt(rcvpkt)
 above              NAK
                                                     udt_send(NAK)

   rdt_rcv(rcvpkt) && isACK(rcvpkt)
                                                       Wait for
        L
                                                       call from
 sender                                                 below


                                                  rdt_rcv(rcvpkt) &&
                                                    notcorrupt(rcvpkt)
                                                  extract(rcvpkt,data)
                                                  deliver_data(data)
                                                  udt_send(ACK)


                                      Xin Liu
                                                                          25

      rdt2.0: operation with no errors
    rdt_send(data)
   snkpkt = make_pkt(data, checksum)
   udt_send(sndpkt)
                             rdt_rcv(rcvpkt) &&
                               isNAK(rcvpkt)
Wait for           Wait for                          rdt_rcv(rcvpkt) &&
call from          ACK or     udt_send(sndpkt)        corrupt(rcvpkt)
 above              NAK
                                                     udt_send(NAK)

   rdt_rcv(rcvpkt) && isACK(rcvpkt)
                                                       Wait for
       L                                               call from
                                                        below


                                                  rdt_rcv(rcvpkt) &&
                                                    notcorrupt(rcvpkt)
                                                  extract(rcvpkt,data)
                                                  deliver_data(data)
                                                  udt_send(ACK)


                                      Xin Liu
                                                                          26

                 rdt2.0: error scenario
    rdt_send(data)
   snkpkt = make_pkt(data, checksum)
   udt_send(sndpkt)
                             rdt_rcv(rcvpkt) &&
                               isNAK(rcvpkt)
Wait for           Wait for                          rdt_rcv(rcvpkt) &&
call from          ACK or     udt_send(sndpkt)        corrupt(rcvpkt)
 above              NAK
                                                     udt_send(NAK)

   rdt_rcv(rcvpkt) && isACK(rcvpkt)
                                                       Wait for
       L                                               call from
                                                        below


                                                  rdt_rcv(rcvpkt) &&
                                                    notcorrupt(rcvpkt)
                                                  extract(rcvpkt,data)
                                                  deliver_data(data)
                                                  udt_send(ACK)


                                      Xin Liu
                                                                               27

            rdt2.0 has a fatal flaw!
What happens if ACK/NAK                  Handling duplicates:
 corrupted?                              • sender adds sequence number
• sender doesn’t know what                 to each pkt
  happened at receiver!                  • sender retransmits current pkt if
• can’t just retransmit: possible          ACK/NAK garbled
  duplicate                              • receiver discards (doesn’t
                                           deliver up) duplicate pkt
What to do?
• sender ACKs/NAKs receiver’s
  ACK/NAK? What if sender
  ACK/NAK lost?                               stop and wait
• retransmit, but this might cause            Sender sends one packet,
  retransmission of correctly                 then waits for receiver
  received pkt!                               response



                                    Xin Liu
                                                                                            28


rdt2.1: sender, handles garbled ACK/NAKs
                             rdt_send(data)
                             sndpkt = make_pkt(0, data, checksum)
                             udt_send(sndpkt)             rdt_rcv(rcvpkt) &&
                                                                     ( corrupt(rcvpkt) ||
                          Wait for                    Wait for
                                                      ACK or
                                                                     isNAK(rcvpkt) )
                         call 0 from
                                                      NAK 0           udt_send(sndpkt)
                           above
 rdt_rcv(rcvpkt)
 && notcorrupt(rcvpkt)                                           rdt_rcv(rcvpkt)
 && isACK(rcvpkt)                                                && notcorrupt(rcvpkt)
                                                                 && isACK(rcvpkt)
         L
                                                                         L
                         Wait for                       Wait for
                         ACK or                        call 1 from
 rdt_rcv(rcvpkt) &&      NAK 1                           above
 ( corrupt(rcvpkt) ||
 isNAK(rcvpkt) )                    rdt_send(data)

 udt_send(sndpkt)               sndpkt = make_pkt(1, data, checksum)
                                udt_send(sndpkt)



                                            Xin Liu
                                                                                                                29


    rdt2.1: receiver, handles garbled ACK/NAKs
                                        rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
                                         && has_seq0(rcvpkt)
                                        extract(rcvpkt,data)
                                        deliver_data(data)
                                        sndpkt = make_pkt(ACK, chksum)
                                        udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)                                             rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum)                                                  sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt)                                                                udt_send(sndpkt)
                                       Wait for                 Wait for
rdt_rcv(rcvpkt) &&                     0 from                   1 from          rdt_rcv(rcvpkt) &&
  not corrupt(rcvpkt) &&               below                    below             not corrupt(rcvpkt) &&
  has_seq1(rcvpkt)                                                                has_seq0(rcvpkt)
 sndpkt = make_pkt(ACK, chksum)                                                 sndpkt = make_pkt(ACK, chksum)
 udt_send(sndpkt)                                                               udt_send(sndpkt)
                                      rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
                                       && has_seq1(rcvpkt)

                                      extract(rcvpkt,data)
                                      deliver_data(data)
                                      sndpkt = make_pkt(ACK, chksum)
                                      udt_send(sndpkt)


                                                      Xin Liu
                                                               30

             rdt2.1: discussion
Sender:                       Receiver:
• seq # added to pkt          • must check if received
• two seq. #’s (0,1) will       packet is duplicate
  suffice. Why?                    – state indicates whether
                                     0 or 1 is expected pkt
• must check if received             seq #
  ACK/NAK corrupted
                              • note: receiver can not
• twice as many states          know if its last
   – state must “remember”      ACK/NAK received
     whether “current” pkt
                                OK at sender
     has 0 or 1 seq. #


                         Xin Liu
                                                                 31

         rdt2.2: a NAK-free protocol

• same functionality as rdt2.1, using NAKs only
• instead of NAK, receiver sends ACK for last pkt
  received OK
   – receiver must explicitly include seq # of pkt being ACKed
• duplicate ACK at sender results in same action as
  NAK: retransmit current pkt




                             Xin Liu
                                                                                         32


            rdt2.2: sender, receiver fragments
                               rdt_send(data)
                               sndpkt = make_pkt(0, data, checksum)
                               udt_send(sndpkt)
                                                                 rdt_rcv(rcvpkt) &&
                                                                 ( corrupt(rcvpkt) ||
                           Wait for                  Wait for
                                                       ACK         isACK(rcvpkt,1) )
                          call 0 from
                            above                       0          udt_send(sndpkt)
                                      sender FSM
                                       fragment                  rdt_rcv(rcvpkt)
                                                                 && notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) &&                                               && isACK(rcvpkt,0)
  (corrupt(rcvpkt) ||                                                    L
   has_seq1(rcvpkt))    Wait for   receiver FSM
                        0 from
udt_send(sndpkt)        below        fragment
                              rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
                               && has_seq1(rcvpkt)
                             extract(rcvpkt,data)
                             deliver_data(data)
                             sndpkt = make_pkt(ACK1, chksum)
                             udt_send(sndpkt)
                                            Xin Liu
                                                                             33

    rdt3.0: channels with errors and loss

New assumption: underlying           Approach: sender waits
  channel can also lose                “reasonable” amount of time
  packets (data or ACKs)               for ACK
   – checksum, seq. #, ACKs,         • retransmits if no ACK received in
     retransmissions will be of        this time
     help, but not enough            • if pkt (or ACK) just delayed (not
Q: how to deal with loss?              lost):
   – sender waits until certain          – retransmission will be
     data or ACK lost, then                 duplicate, but use of seq. #’s
     retransmits                            already handles this
   – yuck: drawbacks?                    – receiver must specify seq # of
                                            pkt being ACKed
                                     • requires countdown timer


                                  Xin Liu
                                                                                                    34

rdt3.0 sender
                                rdt_send(data)
                                                                             rdt_rcv(rcvpkt) &&
                                sndpkt = make_pkt(0, data, checksum)         ( corrupt(rcvpkt) ||
                                udt_send(sndpkt)                             isACK(rcvpkt,1) )
    rdt_rcv(rcvpkt)             start_timer                                           L
          L              Wait for                             Wait
                                                               for            timeout
                        call 0from
                                                              ACK0            udt_send(sndpkt)
                          above
                                                                              start_timer
   rdt_rcv(rcvpkt)
   && notcorrupt(rcvpkt)                                                rdt_rcv(rcvpkt)
   && isACK(rcvpkt,1)                                                   && notcorrupt(rcvpkt)
   stop_timer                                                           && isACK(rcvpkt,0)
                                                                        stop_timer
                              Wait                              Wait for
timeout                        for                             call 1 from
udt_send(sndpkt)              ACK1                               above
start_timer                                                                     rdt_rcv(rcvpkt)
                                     rdt_send(data)                                    L
       rdt_rcv(rcvpkt) &&
       ( corrupt(rcvpkt) ||          sndpkt = make_pkt(1, data, checksum)
       isACK(rcvpkt,0) )             udt_send(sndpkt)
                                     start_timer
                L


                                               Xin Liu
                   35

rdt3.0 in action




      Xin Liu
                   36

rdt3.0 in action




      Xin Liu
                                                    37

          Performance of rdt3.0

• rdt3.0 works, but performance stinks
• example: 1 Gbps link, 15 ms e-e prop. delay,
  1KB packet
• U sender: utilization – fraction of time sender
  busy sending
• Utilization?



                       Xin Liu
                                                                                           38

              rdt3.0: stop-and-wait operation
                                    sender             receiver
    first packet bit transmitted, t = 0
last packet bit transmitted, t = L / R


                                                             first packet bit arrives
                                   RTT                       last packet bit arrives, send ACK


             ACK arrives, send next
             packet, t = RTT + L / R




                                             Xin Liu
                                                                  39

                           Performance


Ttransmit =   L (packet length in bits)    8kb/pkt
                                         =             = 8 microsec
              R (transmission rate, bps)   10**9 b/sec

        U                  L/R              .008
                     =                 =            = 0.00027
            sender                         30.008
                         RTT + L / R                  microsec
                                                      onds


    – 1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps
      link
    – network protocol limits use of physical resources!

                                       Xin Liu
                                                        40

              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
                           Xin Liu
                                                                                                       41

               Pipelining: increased utilization
                                        sender              receiver
first packet bit transmitted, t = 0
      last bit transmitted, t = L / R


                                                                  first packet bit arrives
                                    RTT                           last packet bit arrives, send ACK
                                                                  last bit of 2nd packet arrives, send ACK
                                                                  last bit of 3rd packet arrives, send ACK
          ACK arrives, send next
          packet, t = RTT + L / R


                                                                             Increase utilization
                                                                              by a factor of 3!

                   U                    3*L/R              .024
                                =                  =                   = 0.0008
                       sender                          30.008
                                     RTT + L / R                           microsecon
                                                                           ds

                                                 Xin Liu
                                                                      42

                        Go-Back-N
Sender:
• k-bit seq # in pkt header
• “window” of up to N, consecutive unack’ed pkts allowed




• ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK”
    -- duplicate ACKs (see receiver)
• timer for each in-flight pkt
• timeout(n): retransmit pkt n and all higher seq # pkts in window

                                  Xin Liu
                                                                                   43

       GBN: sender extended FSM
                       rdt_send(data)
                       if (nextseqnum < base+N) {
                           sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)
                           udt_send(sndpkt[nextseqnum])
                           if (base == nextseqnum)
                              start_timer
                           nextseqnum++
                           }
   L                   else
                         refuse_data(data)
  base=1
  nextseqnum=1
                                          timeout
                                          start_timer
                            Wait
                                          udt_send(sndpkt[base])
rdt_rcv(rcvpkt)                           udt_send(sndpkt[base+1])
  && corrupt(rcvpkt)                      …
                                          udt_send(sndpkt[nextseqnum-1])
       L
                        rdt_rcv(rcvpkt) &&
                          notcorrupt(rcvpkt)
                        base = getacknum(rcvpkt)+1
                        If (base == nextseqnum)
                            stop_timer
                          else
                            start_timer
                                     Xin Liu
                                                                                       44

           GBN: receiver extended FSM
                    default
                   udt_send(sndpkt)     rdt_rcv(rcvpkt)
                                         && notcurrupt(rcvpkt)
L                                        && hasseqnum(rcvpkt,expectedseqnum)
expectedseqnum=1          Wait          extract(rcvpkt,data)
sndpkt =                                deliver_data(data)
 make_pkt(expectedseqnum,ACK,chksum)    sndpkt = make_pkt(expectedseqnum,ACK,chksum)
                                        udt_send(sndpkt)
                                        expectedseqnum++


 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!
     – Re-ACK pkt with highest in-order seq #

                                       Xin Liu
            45

GBN in
action




  Xin Liu
                                                               46

                 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

                             Xin Liu
                                             47


Selective repeat: sender, receiver windows




                   Xin Liu
                                                                                 48

                  Selective repeat
 sender                                       receiver
data from above :                            pkt n in [rcvbase, rcvbase+N-1]
• if next available seq # in                 • send ACK(n)
  window, send pkt                           • out-of-order: buffer
timeout(n):                                  • in-order: deliver (also deliver
                                               buffered, in-order pkts),
• resend pkt n, restart timer
                                               advance window to next not-
ACK(n) in [sendbase,sendbase+N]:               yet-received pkt
• mark pkt n as received                     pkt n in [rcvbase-N,rcvbase-1]
• if n smallest unACKed pkt,                 • ACK(n)
  advance window base to next
  unACKed seq #                              otherwise:
                                             • ignore



                                   Xin Liu
                             49

Selective repeat in action




             Xin Liu
                        Selective repeat:   50


                            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)

Q: what relationship between
   seq # size and window
   size?

                                Xin Liu
                                           51

                           Outline
•   Transport-layer services
•   Multiplexing and demultiplexing
•   Connectionless transport: UDP
•   Principles of reliable data transfer
•   Connection-oriented transport: TCP
    –   segment structure
    –   reliable data transfer
    –   flow control
    –   connection management
• Principles of congestion control
• TCP congestion control




                                 Xin Liu
                                                                                                   52


           TCP: Overview                                RFCs: 793, 1122, 1323, 2018, 2581


         • point-to-point:                                     • full duplex data:
             – one sender, one receiver                           – bi-directional data flow in
         • reliable, in-order byte                                  same connection
           steam:                                                 – MSS: maximum segment
                                                                    size
             – no “message boundaries”
                                                               • connection-oriented:
         • pipelined:
                                                                  – handshaking (exchange of
             – TCP congestion and flow                              control msgs) init’s sender,
               control set window size                              receiver state before data
         • send & receive buffers                                   exchange
                                                               • flow controlled:
            application              application
socket
            writes data              reads data
                                                         socket   – sender will not overwhelm
 door                                                     door
              TCP
           send buffer
                                        TCP
                                    receive buffer
                                                                    receiver
                          segment



                                                     Xin Liu
                TCP segment structure                                         53




                                      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
                                                                   # 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)



                                      Xin Liu
                               54

               TCP Options
•   MSS
•   Timestamp
•   Window scale
•   NOP (no operation)
•   Selective-ACK




                     Xin Liu
                                                                             55
          TCP Connection Management
Recall: TCP sender, receiver         Three way handshake:
  establish “connection” before
  exchanging data segments           Step 1: client host sends TCP SYN
• initialize TCP variables:             segment to server
   – seq. #s                             – specifies initial seq #
   – buffers, flow control info          – no data
       (e.g. RcvWindow)              Step 2: server host receives SYN,
• client: connection initiator          replies with SYNACK segment
    – connect();                         – server allocates buffers
• server: contacted by client            – specifies server initial seq. #
    – accept();                      Step 3: client receives SYNACK,
                                        replies with ACK segment, which
                                        may contain data




                                  Xin Liu
                                           56

            TCP connection
•   SYN, FIN consume one sequence number
•   ISN increase by one every 4ms.
•   9.5 hours reuse cycle.
•   MSS: maximum segment size




                    Xin Liu
                                                                              57



  TCP Connection Management (cont.)
Closing a connection:
                                                    client   server
client closes socket:             close
   close();

Step 1: client end system                                             close
  sends TCP FIN control
  segment to server

                                       timed wait
Step 2: server receives FIN,
  replies with ACK. Closes
  connection, sends FIN.
                               closed



                             Xin Liu
                                                                                   58



    TCP Connection Management (cont.)
Step 3: client receives FIN,
   replies with ACK.                                       client   server

    – Enters “timed wait” - will       closing
      respond with ACK to          FIN_WAIT_1
      received FINs
                                                                             closing
Step 4: server, receives ACK.
                                   FIN_WAIT_2
   Connection closed.
                                   TIME_WAIT
Note: with small modification,
                                              timed wait
   can handle simultaneous
                                                                             closed
   FINs.

                                     closed



                                    Xin Liu
                                       59

TCP Connection Management (cont)



                          TCP server
                          lifecycle


TCP client
lifecycle




               Xin Liu
                                                 60

  TCP Connection Management
• Allow half-close, i.e., one end to terminate
  its output, but still receiving data
• Allow simultaneous open
• Allow simultaneous close
• Crashes?




                      Xin Liu
                                                                                               61
[root@shannon liu]# tcpdump -S tcp port 22
tcpdump: listening on eth0
23:01:51.363983 shannon.cs.ucdavis.edu.60042 > weasel.cs.ucdavis.edu.ssh: S
3036713598:3036713598(0) win 5840 <mss 1460,sackOK,timestamp 13989220 0,nop,wscale 0> (DF)

23:01:51.364829 weasel.cs.ucdavis.edu.ssh > shannon.cs.ucdavis.edu.60042: S
2462279815:2462279815(0) ack 3036713599 win 24616 <nop,nop,timestamp 626257407
13989220,nop,wscale 0,nop,nop,sackOK,mss 1460> (DF)

23:01:51.364844 shannon.cs.ucdavis.edu.60042 > weasel.cs.ucdavis.edu.ssh: . ack 2462279816 win 5840
<nop,nop,timestamp 13989220 626257407> (DF)

23:01:51.375451 weasel.cs.ucdavis.edu.ssh > shannon.cs.ucdavis.edu.60042: P
2462279816:2462279865(49) ack 3036713599 win 24616 <nop,nop,timestamp 626257408 13989220>
(DF)

23:01:51.375478 shannon.cs.ucdavis.edu.60042 > weasel.cs.ucdavis.edu.ssh: . ack 2462279865 win 5840
<nop,nop,timestamp 13989221 626257408> (DF)

23:01:51.379319 shannon.cs.ucdavis.edu.60042 > weasel.cs.ucdavis.edu.ssh: P
3036713599:3036713621(22) ack 2462279865 win 5840 <nop,nop,timestamp 13989221 626257408>
(DF)

23:01:51.379570 weasel.cs.ucdavis.edu.ssh > shannon.cs.ucdavis.edu.60042: . ack 3036713621 win 24616
<nop,nop,timestamp 626257408 13989221>
(DF)                                          Xin Liu
                                                                                                  62


23:01:51.941616 shannon.cs.ucdavis.edu.60042 > weasel.cs.ucdavis.edu.ssh: P 3036714373:3036714437(64)
ack 2462281065 win 7680 <nop,nop,timestamp 13989277 626257462> (DF)

23:01:51.952442 weasel.cs.ucdavis.edu.ssh > shannon.cs.ucdavis.edu.60042: P
2462281065:2462282153(1088) ack 3036714437 win 24616 <nop,nop,timestamp 626257465 13989277>
(DF)

23:01:51.991682 shannon.cs.ucdavis.edu.60042 > weasel.cs.ucdavis.edu.ssh: . ack 2462282153 win 9792
<nop,nop,timestamp 13989283 626257465> (DF)

23:01:54.699597 shannon.cs.ucdavis.edu.60042 > weasel.cs.ucdavis.edu.ssh: F 3036714437:3036714437(0)
ack 2462282153 win 9792 <nop,nop,timestamp 13989553 626257465> (DF)

23:01:54.699880 weasel.cs.ucdavis.edu.ssh > shannon.cs.ucdavis.edu.60042: . ack 3036714438 win 24616
<nop,nop,timestamp 626257740 13989553>(DF)

23:01:54.701129 weasel.cs.ucdavis.edu.ssh > shannon.cs.ucdavis.edu.60042: F 2462282153:2462282153(0)
ack 3036714438 win 24616 <nop,nop,timestamp 626257740 13989553> (DF)

23:01:54.701143 shannon.cs.ucdavis.edu.60042 > weasel.cs.ucdavis.edu.ssh: . ack 2462282154 win 9792
<nop,nop,timestamp 13989553 626257740> (DF)

26 packets received by filter
0 packets dropped by kernel
                                                Xin Liu
                                           63

                           Outline
•   Transport-layer services
•   Multiplexing and demultiplexing
•   Connectionless transport: UDP
•   Principles of reliable data transfer
•   Connection-oriented transport: TCP
    –   segment structure
    –   reliable data transfer
    –   flow control
    –   connection management
• Principles of congestion control
• TCP congestion control




                                 Xin Liu
                                                                                 64

             TCP seq. #’s and ACKs
Seq. #’s:
                                            Host A           Host B
    – byte stream “number”
       of first byte in          User
                                 types
       segment’s data              „C‟
ACKs:                                                              host ACKs
                                                                   receipt of
    – seq # of next byte                                           „C‟, echoes
       expected from other                                           back „C‟
       side
    – cumulative ACK           host ACKs
                                receipt
Q: how receiver handles out-
                               of echoed
   of-order segments               „C‟
    – A: TCP spec doesn’t
       say, - up to
                                                                            time
       implementor
                                                simple telnet scenario


                                  Xin Liu
                                                                65

TCP Round Trip Time and Timeout
Q: how to set TCP           Q: how to estimate RTT?
  timeout value?            • SampleRTT: measured time
• longer than RTT             from segment transmission until
   – but RTT varies           ACK receipt
• too short: premature         – ignore retransmissions
  timeout                   • SampleRTT will vary, want
   – unnecessary              estimated RTT “smoother”
      retransmissions          – average several recent
• too long: slow reaction         measurements, not just
  to segment loss                 current SampleRTT



                            Xin Liu
                                                              66

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




                            Xin Liu
                                                                                                                             67

                                        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



                                                                         Xin Liu
                                                                68

 TCP Round Trip Time and Timeout
Setting the timeout
• EstimtedRTT plus “safety margin”
    – large variation in EstimatedRTT -> larger safety margin
• first estimate of how much SampleRTT deviates from
  EstimatedRTT:
   DevRTT = (1-)*DevRTT +
                *|SampleRTT-EstimatedRTT|

   (typically,  = 0.25)

Then set timeout interval:

TimeoutInterval = EstimatedRTT + 4*DevRTT


                                Xin Liu
                                             69

                  RTT
• Timestamp can be used to measure RTT for
  each segment
• Better RTT estimate
• NO Syn required




                   Xin Liu
                                           70

                           Outline
•   Transport-layer services
•   Multiplexing and demultiplexing
•   Connectionless transport: UDP
•   Principles of reliable data transfer
•   Connection-oriented transport: TCP
    –   segment structure
    –   reliable data transfer
    –   flow control
    –   connection management
• Principles of congestion control
• TCP congestion control




                                 Xin Liu
                                                               71

      TCP reliable data transfer
• TCP creates rdt               • Retransmissions are
  service on top of IP’s          triggered by:
  unreliable service                 – timeout events
• Pipelined segments                 – duplicate acks
• Cumulative acks               • Initially consider
• TCP uses single                 simplified TCP
  retransmission timer            sender:
                                     – ignore duplicate acks
                                     – ignore flow control,
                                       congestion control



                           Xin Liu
                                                                         72

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



                                Xin Liu
                                                                                  73

NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum                                              TCP
loop (forever) {
  switch(event)                                                      sender
  event: data received from application above
     create TCP segment with sequence number NextSeqNum             (simplified)
     if (timer currently not running)
           start timer
     pass segment to IP                                             Comment:
     NextSeqNum = NextSeqNum + length(data)
                                                                    • SendBase-1: last
   event: timer timeout                                             cumulatively
      retransmit not-yet-acknowledged segment with                  ack‟ed byte
            smallest sequence number                                Example:
                                                                    • SendBase-1 = 71;
      start timer

   event: ACK received, with ACK field value of y                   y= 73, so the rcvr
      if (y > SendBase) {                                           wants 73+ ;
            SendBase = y
                                                                    y > SendBase, so
           if (there are currently not-yet-acknowledged segments)
                  start timer                                       that new data is
           }                                                        acked
 } /* end of loop forever */


                                         Xin Liu
                                                                                             74

               TCP: retransmission 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
                                     Xin Liu
                                                     75


     TCP retransmission scenarios (more)
                     Host A       Host B
           timeout




                              X
                          loss

SendBase
  = 120




             time
                 Cumulative ACK scenario


                                           Xin Liu
  TCP ACK generation [RFC 1122, RFC                                              76


                                    2581]

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 startsat lower end of gap


                                    Xin Liu
                                                 77

            Nagel algorithm
• Small segments cannot be sent until the
  outstanding data is acked if a TCP
  connection has outstanding data that has not
  yet been acked.
• Self-clocking: the fast the ack comes back,
  the faster the data is sent
• May need to be disabled somtimes



                     Xin Liu
                                                                   78

               Fast Retransmit
• Time-out period often
  relatively long:         • If sender receives 3
   – long delay before       ACKs for the same
     resending lost packet   data, it supposes that
• Detect lost segments       segment after ACKed
  via duplicate ACKs.        data was lost:
   – Sender often sends                – fast retransmit: resend
     many segments back-                 segment before timer
     to-back                             expires
   – If segment is lost, there
     will likely be many
     duplicate ACKs.

                             Xin Liu
                                                                           79

            Fast retransmit algorithm:

   event: ACK received, with ACK field value of y
            if (y > SendBase) {
                  SendBase = y
                  if (there are currently not-yet-acknowledged segments)
                        start timer
                }
            else {
                    increment count of dup ACKs received for y
                    if (count of dup ACKs received for y = 3) {
                         resend segment with sequence number y
                     }


a duplicate ACK for             fast retransmit
already ACKed segment


                                      Xin Liu
                                           80

                           Outline
•   Transport-layer services
•   Multiplexing and demultiplexing
•   Connectionless transport: UDP
•   Principles of reliable data transfer
•   Connection-oriented transport: TCP
    –   segment structure
    –   reliable data transfer
    –   flow control
    –   connection management
• Principles of congestion control
• TCP congestion control




                                 Xin Liu
                                                             81

            TCP Flow Control
                                    flow control
 • receive side of TCP              sender won‟t overflow
   connection has a                  receiver‟s buffer by
   receive buffer:                  transmitting too much,
                                           too fast


                                   • speed-matching
                                     service: matching the
                                     send rate to the
                                     receiving app’s drain
• app process may be                 rate
  slow at reading from
  buffer
                         Xin Liu
                                                                82

 TCP Flow control: how it works
                                     • Rcvr advertises spare
                                       room by including
                                       value of RcvWindow
                                       in segments
                                     • Sender limits
(Suppose TCP receiver discards
                                       unACKed data to
  out-of-order segments)
                                       RcvWindow
• spare room in buffer
= RcvWindow                             – guarantees receive
= RcvBuffer-[LastByteRcvd -               buffer doesn’t overflow
  LastByteRead]



                           Xin Liu
                                              83

                   More
• Slow receiver
  – Ack new window
  – Persist timer

• Long fat pipeline: high speed link and/or
  long RTT

• Window scale option during handshaking



                     Xin Liu
                                        84

            Header
               32 bits

 source port #         dest port #
        sequence number
    acknowledgement number
head not
 len used
          UA P R S F   Receive window
    checksum           Urg data pnter

    Options (variable length)


              application
                 data
           (variable length)




                 Xin Liu
                                                                                               85
[root@shannon liu]# tcpdump -S tcp port 22
tcpdump: listening on eth0
23:01:51.363983 shannon.cs.ucdavis.edu.60042 > weasel.cs.ucdavis.edu.ssh: S
3036713598:3036713598(0) win 5840 <mss 1460,sackOK,timestamp 13989220 0,nop,wscale 0> (DF)

23:01:51.364829 weasel.cs.ucdavis.edu.ssh > shannon.cs.ucdavis.edu.60042: S
2462279815:2462279815(0) ack 3036713599 win 24616 <nop,nop,timestamp 626257407
13989220,nop,wscale 0,nop,nop,sackOK,mss 1460> (DF)

23:01:51.364844 shannon.cs.ucdavis.edu.60042 > weasel.cs.ucdavis.edu.ssh: . ack 2462279816 win 5840
<nop,nop,timestamp 13989220 626257407> (DF)

23:01:51.375451 weasel.cs.ucdavis.edu.ssh > shannon.cs.ucdavis.edu.60042: P
2462279816:2462279865(49) ack 3036713599 win 24616 <nop,nop,timestamp 626257408 13989220>
(DF)

23:01:51.375478 shannon.cs.ucdavis.edu.60042 > weasel.cs.ucdavis.edu.ssh: . ack 2462279865 win 5840
<nop,nop,timestamp 13989221 626257408> (DF)

23:01:51.379319 shannon.cs.ucdavis.edu.60042 > weasel.cs.ucdavis.edu.ssh: P
3036713599:3036713621(22) ack 2462279865 win 5840 <nop,nop,timestamp 13989221 626257408>
(DF)

23:01:51.379570 weasel.cs.ucdavis.edu.ssh > shannon.cs.ucdavis.edu.60042: . ack 3036713621 win 24616
<nop,nop,timestamp 626257408 13989221>
(DF)                                          Xin Liu
                                86

          Reading assignment
•   Chp. 19, p. 265-274
•   Chp. 21, p. 297-304
•   Chp. 22, p. 323-330
•   Chp. 24, p. 344-348




                      Xin Liu
                                           87

                           Outline
•   Transport-layer services
•   Multiplexing and demultiplexing
•   Connectionless transport: UDP
•   Principles of reliable data transfer
•   Connection-oriented transport: TCP
    –   segment structure
    –   reliable data transfer
    –   flow control
    –   connection management
• Principles of congestion control
• TCP congestion control




                                 Xin Liu
                                                   88

  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)
• a top-10 problem!



                       Xin Liu
                                                                                              89

    Causes/costs of congestion: scenario 1
                                  Host A
                                           lin : original data                         lout
• two senders, two
  receivers           Host B                                      unlimited shared
                                                                 output link buffers

• one router,
  infinite buffers
• no retransmission

                                                             • large delays when
                                                               congested
                                                             • maximum
                                                               achievable
                                                               throughput

                               Xin Liu
                                                              90

     Causes/costs of congestion: scenario 2
• one router, finite buffers
• sender retransmission of lost packet
                Host      lin : original               lout
                A         data
                       l'in : original data, plus
                             retransmitted data
       Host B                  finite shared output
                                        link buffers




• “costs” of congestion:
   • more work (retrans) for given “goodput”
   • unneeded retransmissions: link carries multiple copies
   of pkt
                                       Xin Liu
                                         91

Causes/costs of congestion: scenario 2




                 Xin Liu
                                                                         92

  Causes/costs of congestion: scenario 3
• four senders                          Q: what happens as lin
• multihop paths                          and linincrease ?
• timeout/retransmit
                       Host A                                     lout
                                lin : original data
                                l'in : original data, plus
                                      retransmitted data

                                          finite shared output
                                                   link buffers


     Host B




                                   Xin Liu
                                                    93

  Causes/costs of congestion: scenario 3
                                     H      l
                                     o
                                            o
                                     s
                                            u
                                     t
                                     A      t


                                 H
                                 o
                                 s
                                 t
                                 B




Another “cost” of congestion:
• when packet dropped, any “upstream transmission
  capacity used for that packet was wasted!

                       Xin Liu
                                                             94

  Approaches towards congestion control

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

                           Xin Liu
                                                                  95


Case study: ATM ABR congestion control
ABR: available bit rate:       RM (resource management)
• “elastic service”             cells:
• if sender’s path             • sent by sender, interspersed
  “underloaded”:                 with data cells
   – sender should use         • bits in RM cell set by
      available bandwidth        switches (“network-assisted”)
• if sender’s path                – NI bit: no increase in rate
  congested:                         (mild congestion)
   – sender throttled to          – CI bit: congestion
      minimum guaranteed             indication
      rate                     • RM cells returned to sender
                                 by receiver, with bits intact

                            Xin Liu
                                                                   96
     Case study: ATM ABR congestion
                  control




• two-byte ER (explicit rate) field in RM cell
   – congested switch may lower ER value in cell
   – sender’ send rate thus minimum supportable rate on path
• EFCI bit in data cells: set to 1 in congested switch
   – if data cell preceding RM cell has EFCI set, sender sets CI
     bit in returned RM cell
                             Xin Liu
                                           97

                           Outline
•   Transport-layer services
•   Multiplexing and demultiplexing
•   Connectionless transport: UDP
•   Principles of reliable data transfer
•   Connection-oriented transport: TCP
    –   segment structure
    –   reliable data transfer
    –   flow control
    –   connection management
• Principles of congestion control
• TCP congestion control




                                 Xin Liu
                                                                   98

              TCP Congestion Control

• end-end control (no network              How does sender
  assistance)                                perceive congestion?
• sender limits transmission:              • loss event = timeout or
  LastByteSent-LastByteAcked                 3 duplicate acks
                    cwnd
                                           • TCP sender reduces
• Roughly,                                   rate (cwnd) after loss
                cwnd                         event
     rate =             Bytes/sec
                RTT
                                           mechanisms:
• cwnd is dynamic, function of                – slow start
  perceived network congestion                – congestion avoidance
                                              – AIMD

                                 Xin Liu
                                                        99

                  TCP Slow Start

• When connection          • When connection
  begins, cwnd = 1 MSS       begins, increase rate
  – Example: MSS = 500
                             exponentially fast until
    bytes & RTT = 200 msec   first loss event
  – initial rate = 20 kbps
• available bandwidth
  may be >> MSS/RTT
  – desirable to quickly ramp
    up to respectable rate



                                Xin Liu
                                                                   100

        TCP Slow Start (more)
• When connection
  begins, increase rate                   Host A   Host B

  exponentially until




                                    RTT
  first loss event:
   – incrementing cwnd for
     every ACK received
   – double cwnd every
     RTT
• Summary: initial rate
  is slow but ramps up
  exponentially fast                                        time



                          Xin Liu
                                           101

      Congestion Avoidance
• ssthresh: when cwnd reaches ssthresh,
  congestion avoidance begins
• Congestion avoidance: increase cwnd by
  1/cwnd each time an ACK is received
• Congestion happens: ssthresh=max(2MSS,
  cwnd/2)




                   Xin Liu
                                                                        102

                        TCP AIMD
multiplicative decrease:                    additive increase:
 cut cwnd in half after                       increase cwnd by 1
 loss event                                   MSS every RTT in the
          congestion
                                              absence of loss events:
            window

    24 Kbytes
                                              probing

    16 Kbytes




     8 Kbytes




                                                           time




                       Long-lived TCP connection

                                  Xin Liu
                                                           103

                  Reno vs. Tahoe
                                        Philosophy:
• After 3 dup ACKs:
                                • 3 dup ACKs indicates
   – cwnd is cut in half
                                network capable of
   – window then grows linearly delivering some segments
• But after timeout event:      • timeout before 3 dup
   – cwnd instead set to 1 MSS; ACKs is “more alarming”
   – window then grows
     exponentially
   – to a sshthresh, then grows
     linearly




                              Xin Liu
                                                         104



   Summary: TCP Congestion Control
• When cwnd is below sshthresh, sender in slow-start
  phase, window grows exponentially.
• When cwnd is above sshthresh, sender is in
  congestion-avoidance phase, window grows linearly.
• When a triple duplicate ACK occurs, sshthresh set to
  cwnd/2 and cwnd set to sshthresh.

• When timeout occurs, sshthresh set to cwnd/2 and
  cwnd is set to 1 MSS.



                           Xin Liu
                                                             105

                         Trend
• Recent research proposes network-assisted
  congestion control: active queue management
• ECN: explicit congestion notification
   – 2 bits: 6 &7 in the IP TOS field
• RED: random early detection
   – Implicit
   – Can be adapted to explicit methods by marking instead
     of dropping




                            Xin Liu
                                106

                    Reading
• Chp. 21.1-21.8
• Chp. 20.6, 20.7




                      Xin Liu
                                                     107


                 TCP Fairness
Fairness goal: if K TCP sessions share same
  bottleneck link of bandwidth R, each should have
  average rate of R/K
           TCP connection 1




                       bottleneck
       TCP
                         router
       connection 2
                       capacity R




                              Xin Liu
                                                                            108

                 Why is TCP fair?
Two competing sessions:
• Additive increase gives slope of 1, as throughout increases
• multiplicative decrease decreases throughput proportionally
           R               equal bandwidth share




                               loss: decrease window by factor of 2
                               congestion avoidance: additive increase
                                    loss: decrease window by factor of 2
                                  congestion avoidance: additive increase




               Connection 1 throughput R

                               Xin Liu
                                                                       109

                Fairness (more)
Fairness and UDP             Fairness and parallel TCP
• Multimedia apps often        connections
  do not use TCP             • nothing prevents app from
   – do not want rate          opening parallel cnctions
     throttled by congestion   between 2 hosts.
     control                 • Web browsers do this
• Instead use UDP:           • Example: link of rate R
   – pump audio/video at       supporting 9 cnctions;
     constant rate, tolerate
                                         – new app asks for 1 TCP,
     packet loss
                                           gets rate R/10
• Research area: TCP                     – new app asks for 11 TCPs,
  friendly                                 gets R/2 !
                               Xin Liu
                                                                        110

                   Delay modeling
                                        Notation, assumptions:
Q: How long does it take to
                                        • Assume one link between
  receive an object from a                client and server of rate R
  Web server after sending              • S: MSS (bits)
  a request?                            • O: object size (bits)
Ignoring congestion, delay              • no retransmissions (no
  is influenced by:                       loss, no corruption)
• TCP connection establishment          Window size:
• data transmission delay               • First assume: fixed
• slow start                              congestion window, W
                                          segments
                                        • Then dynamic window,
                                          modeling slow start
                              Xin Liu
                                    111


  Fixed congestion window (1)

First case:
WS/R > RTT + S/R: ACK
 for first segment in
 window returns before
 window’s worth of data
 sent
 delay = 2RTT + O/R




                          Xin Liu
                                      112


   Fixed congestion window (2)

Second case:
• WS/R < RTT + S/R:
  wait for ACK after
  sending window’s worth
  of data sent
    delay = 2RTT + O/R
+ (K-1)[S/R + RTT - WS/R]




                            Xin Liu
                                                            113
         TCP Delay Modeling: Slow Start (1)
  Now suppose window grows according to slow start

  Will show that the delay for one object is:
                           O           S              S
       Latency  2 RTT       P  RTT    ( 2 P  1)
                           R           R              R

   where P is the number of times TCP idles at server:

               P  min{Q, K  1}

- where Q is the number of times the server idles
  if the object were of infinite size.

- and K is the number of windows that cover the object.




                                     Xin Liu
                                                                           114
           TCP Delay Modeling: Slow Start (2)
Delay components:         initiate TCP
                           connection
• 2 RTT for connection
estab and request           request

• O/R to transmit
                             object
                                                                 first window

object
                                                                     = S/R

• time server idles due            RTT
                                                                 second window
to slow start                                                        = 2S/R



Server idles:                                                third window
                                                                = 4S/R
P = min{K-1,Q} times

Example:                                                         fourth window
                                                                    = 8S/R
• O/S = 15 segments
• K = 4 windows
•Q=2
• P = min{K-1,Q} = 2       object
                                                                   complete
                                                                 transmission
                          delivered

Server idles P=2 times                   time at
                                                       time at
                                                       server
                                          client


                                             Xin Liu
                                                                                          115
                             TCP Delay Modeling (3)
 S
    RTT  time from when server starts to send segment
 R
           until server receives acknowledgement
                                                   initiate TCP
                                                    connection
         S
 2k 1      time to transmit the kth window         request
         R                                            object
                                                                                      first window
                                                                                          = S/R
                     
S              S                                          RTT

R  RTT  2k 1   idle time after thekth window                                    second window
                                                                                          = 2S/R
               R
                                                                                  third window
                                                                                     = 4S/R



                   P
       O
delay   2 RTT   idleTimep                                                         fourth window
                                                                                         = 8S/R
       R          p 1
                       P
           O               S             S
            2 RTT   [  RTT  2 k 1 ]
           R          k 1 R             R          object
                                                                                        complete
                                                                                      transmission
                                                   delivered
           O                  S              S
            2 RTT  P[ RTT  ]  (2 P  1)                                time at
           R                  R              R                    time at
                                                                   client
                                                                            server



                                                 Xin Liu
                                                              116

        TCP Delay Modeling (4)
 Recall K = number of windows that cover object

 How do we calculate K ?

            K  min{k : 20 S  21 S    2 k 1 S  O}
                min{k : 20  21    2 k 1  O / S }
                                   O
                min{k : 2  1  }
                           k

                                   S
                                    O
                min{k : k  log 2 (  1)}
                                    S
                        O    
                log 2 (  1)
                        S    
Calculation of Q, number of idles for infinite-size object,
is similar.

                                    Xin Liu
                                                            117

                                Delay
  • We show:
                           O           S              S
       Latency  2 RTT       P  RTT    ( 2 P  1)
                           R           R              R

   where P is the number of times TCP idles at server:

               P  min{Q, K  1}

- where Q is the number of times the server idles
  if the object were of infinite size.

- and K is the number of windows that cover the object.




                                   Xin Liu
                                         118

       Congestion Avoidance
• R: rate at the bottleneck router
• thresh=R*RTT ( unit is byte)
  – Maximum window size before packets
    dropping
• cwnd ( unit is byte)
  – 0.5 * thresh--- 1 * thresh
• Average Throughput
  – 0.75*thresh/RTT =0.75 R



                         Xin Liu
                                                 119

                 Summary
• What if the sender’s link is the bottleneck?
  – What happens to cwnd?
• A bottleneck in the middle of the network
• The receiver is the bottleneck?

• Summary:
  – Minimum of all three



                      Xin Liu
                                                                             120

                          HTTP
• Assume Web page consists of:
  – 1 base HTML page (of size O bits)
  – M images (each of size O bits)
• Persist HTTP
  – Multiple objects can be sent over single TCP connection between client
    and server.
  – HTTP/1.1 uses persistent connections in default mode

• Non-persist HTTP
  – At most one object is sent over a TCP connection.
  – HTTP/1.0 uses nonpersistent HTTP




                                 Xin Liu
                                                                    121

                HTTP Modeling
• Non-persistent HTTP:
   – M+1 TCP connections in series
   – Response time = (M+1)O/R + (M+1)2RTT + sum of idle times
• Persistent HTTP:
   – 2 RTT to request and receive base HTML file
   – 1 RTT to request and receive M images
   – Response time = (M+1)O/R + 3RTT + sum of idle times
• Non-persistent HTTP with X parallel connections
   – Suppose M/X integer.
   – 1 TCP connection for base file
   – M/X sets of parallel connections for images.
   – Response time = (M+1)O/R + (M/X + 1)2RTT + sum of idle times




                              Xin Liu
                                                          122

         HTTP response time
• Small RTT?
  – low bandwidth, connection & response time dominated
    by transmission time.
  – Persistent connections only give minor improvement
    over parallel connections.
• Large RTT?
  – For larger RTT, response time dominated by TCP
    establishment & slow start delays. Persistent
    connections now give important
  – improvement: particularly in high delaybandwidth
    networks.



                         Xin Liu
                                                           123

                     Reading
• Chp. 24.8 (performance)
• D. Chiu and R. Jain, “Analysis of the increase and
  decrease algorithms for the congestion avoidance in
  computer networks”, Computer Networks and ISDN
  systems, vol. 17, no. 1, pp. 1-14. (fairness and
  performance)
• T. Lakshman, U. Madhow, “the performance of TCP/IP for
  networks with high-bandwidth-delay products and random
  losses,” IEEE/ACM Trans. On Networking, vol. 5, no. 3,
  pp. 336-350.




                         Xin Liu
                                                           124

                         SCTP
• SCTP: stream control transmission protocol
• Motivation
   – Many applications need reliable message delivery –
     they do so by delineating a TCP stream
   – TCP provides both strict-ordering and reliability –
     many applications may not need both
   – Many applications require better fault tolerance




                            Xin Liu
                                                               125

           Motivation (contd)
• HTTP is one such application
  – While transferring multiple embedded files we
    only want
     • Reliable file transfer for each file
     • Partial ordering for the packets of each file but not
       total ordering amongst all the packets
  – TCP provides more than this (but overhead?)
  – SCTP may help (how? – later)




                           Xin Liu
                                                  126

             What is SCTP?
• Originally designed to support PSTN
  signaling messages over IP Networks
• It is a reliable transport protocol operating
  on top of a connectionless packet network
  such as IP (same level as TCP)




                      Xin Liu
                                                      127

   Major Differences from TCP
• Connection Setup
• SCTP is message oriented as opposed to being
  byte stream oriented
   – Boundary conservation
• SCTP has the concept of an association instead of
  a connection
   – Each association can have multiple streams
• SCTP separates reliable transfer of datagrams
  from the delivery mechanism
   – No-head-of line blocking
• SCTP supports multihoming

                           Xin Liu
                                                      128

            Similarities to TCP
• Similar Flow Control and Congestion
  Control Strategies employed
  –   Slow Start and Congestion Avoidance phases
  –   Selective Acknowledgement
  –   Fast Retransmit
  –   Slight differences for supporting multihoming
• Will allow co-existence of TCP and SCTP
  [JST 2000]



                         Xin Liu
                                                        129

               Connection Setup
                                          server

                                             Generate
                                              cookie




• No action at server after send cookie
• Cookie verification
   – Effective to SYN attacks




                                Xin Liu
                130
Packet Format




     Xin Liu
                                                   131

        HTTP Server Architecture
Single File Transfer ( Both TCP and SCTP are similar)


                  Request file
                                       Server


     Client                                Fork child

                   Send file           Child
                                      process


                        Xin Liu
                                                132

    HTTP Server Architecture
Multiple File Transfer (Embedded files) - TCP


              Request file 0
                                    Server


  Client                                Fork child
              Send file 0
             Request file 1..N      Child
                                   process
             Send file 1,2,…N
                     Xin Liu
                     133

SCTP Packet Format




           streams
       Xin Liu
                                                   134

         HTTP Server Architecture
 Multiple Files Transfer (Embedded Files) - SCTP


                Request file 0          Server


Client                                  Fork child
             Send file 0 – stream 0
              Request files 1..N         Child
                                        process
             Send file 1 – stream 1
            Send file N – stream N
                       Xin Liu
                                                                    135

                     Hypothesis

             Server                     Client




1



    3    2       1    3    2        1   3    2       1

        File 3            File 2            File 1

                                                          TCP
                                                 Receive buffer in kernel


                          Xin Liu
                                                                    136

                     Hypothesis

             Server                     Client




1



    3    2       1    3    2        1   3    2       1

        File 3            File 2            File 1

                                                         SCTP
                                                 Receive buffer in kernel


                          Xin Liu
                                                         137

                 Multihome
• designed to offer network resilience to
  failed interfaces on the host and faster
  recovery during network failures
  – Less effective if a single point of failure exists
  – Today’s IP subject to a routing reconvergence
    time




                        Xin Liu
                                                                               138

                             Reading
• RFC 2960
• SCTP for Beginners
http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb/sctp_intro.html




                                    Xin Liu
                                                 139

               Wireless TCP
• Motivation
  – Wireless channels are unreliable and time-
    varying
  – Cause TCP timeout/Duplicate acks
• Approaches




                       Xin Liu
                                               140

         Channel Conditions
• Decides transmission performance

• Determined by
  – Strength of desired signal
  – Noise level
     • Interference from other transmissions
     • Background noise
  – Time-varying and location-dependent.



                          Xin Liu
                                               141

Interference and Noise

                  Noise


   Interference                 Interference




                      Desired
                      Signal




Interference




                  Xin Liu
                                                   142

     Propagation Environment



              Weak

                                Shadowing
Strong




         Path Loss




                               Multi-path Fading
                     Xin Liu
        Time-varying Channel                         143



             Conditions
• Due to users’ mobility and variability in the
  propagation environment, both desired signal and
  interference are time-varying and location-
  dependent


• A measure of channel quality:
  SINR (Signal to Interference plus Noise Ratio)




                       Xin Liu
                                                                              144

Illustration of Channel Conditions




   Based on Lee’s path loss model, log-normal shadowing, and Raleigh fading
                                Xin Liu
                                                  145

             Random Errors
• If number of errors is small, they may be
  corrected by an error correcting code
• Excessive bit errors result in a packet being
  discarded, possibly before it reaches the
  transport layer




                      Xin Liu
                                              146
 Random Errors May Cause Fast Retransmit

• Fast retransmit results in
  – retransmission of lost packet
  – reduction in congestion window
• Reducing congestion window in response to
  errors is unnecessary
• Reduction in congestion window reduces
  the throughput



                      Xin Liu
  Sometimes Congestion Response May                                       147


  be Appropriate in Response to Errors
• On a CDMA channel, errors occur due to interference from
  other user, and due to noise [Karn99pilc]
   – Interference due to other users is an indication of congestion. If
     such interference causes transmission errors, it is appropriate to
     reduce congestion window
   – If noise causes errors, it is not appropriate to reduce window

• When a channel is in a bad state for a long duration, it
  might be better to let TCP backoff, so that it does not
  unnecessarily attempt retransmissions while the channel
  remains in the bad state [Padmanabhan99pilc]




                                 Xin Liu
                                                      148

  Burst Errors May Cause Timeouts
• If wireless link remains unavailable for extended
  duration, a window worth of data may be lost
   – driving through a tunnel
   – passing a truck
• Timeout results in slow start
• Slow start reduces congestion window to 1 MSS,
  reducing throughput
• Reduction in window in response to errors
  unnecessary


                           Xin Liu
                                           149
  Random Errors May Also Cause Timeout


• Multiple packet losses in a window can
  result in timeout when using TCP-Reno




                    Xin Liu
                                              150

  Impact of Transmission Errors
• TCP cannot distinguish between packet
  losses due to congestion and transmission
  errors
• Unnecessarily reduces congestion window
• Throughput suffers




                    Xin Liu
                                                 151

           Various Schemes
• Link level mechanisms
• Split connection approach
• TCP-Aware link layer
• TCP-Unaware approximation of TCP-aware link
  layer
• Explicit notification
• Receiver-based discrimination
• Sender-based discrimination


                Ref: tutorials by Nitin Vaidya
                         Xin Liu
                            152




Split Connection Approach




           Xin Liu
                                                       153

   Split Connection Approach

• End-to-end TCP connection is broken into
  one connection on the wired part of route
  and one over wireless part of the route

• A single TCP connection split into two TCP
  connections
  – if wireless link is not last on route, then more
    than two TCP connections may be needed

                        Xin Liu
                                                154

    Split Connection Approach

• Connection between wireless host MH and
  fixed host FH goes through base station BS

• FH-MH = FH-BS + BS-MH



        FH         BS              MH

  Fixed Host   Base Station       Mobile Host
                        Xin Liu
                                                                    155

  Split Connection Approach

                                         Per-TCP connection state

       TCP connection            TCP connection


application             application              application
                                         rxmt
transport               transport                transport
network                 network                  network
link                    link                     link
physical                physical                 physical




                                      wireless
                           Xin Liu
                                              156
 Split Connection Approach : Classification


• Hides transmission errors from sender
• Primary responsibility at base station
• If specialized transport protocol used on
  wireless, then wireless host also needs
  modification




                     Xin Liu
                                                                      157

Split Connection Approach : Advantages
• BS-MH connection can be optimized independent of FH-
  BS connection
   – Different flow / error control on the two connections


• Local recovery of errors
   – Faster recovery due to relatively shorter RTT on wireless link


• Good performance achievable using appropriate BS-MH
  protocol




                                Xin Liu
                                                                             158
  Split Connection Approach : Disadvantages

• End-to-end semantics violated
• BS retains hard state
    – BS failure can result in loss of data (unreliability)
   – Hand-off latency increases due to state transfer
   – Buffer space needed at BS for each TCP connection
• Extra copying of data at BS
    – copying from FH-BS socket buffer to BS-MH socket buffer
    – increases end-to-end latency
• May not be useful if data and acks traverse different paths (both do not
  go through the base station)
    – Example: data on a satellite wireless hop, acks on a dial-up channel




                                     Xin Liu
                                           159

         Various Schemes
• Link layer mechanisms
• Split connection approach
• TCP-Aware link layer
• TCP-Unaware approximation of TCP-aware
  link layer
• Explicit notification
• Receiver-based discrimination
• Sender-based discrimination

                  Xin Liu
                       160




TCP-Aware Link Layer




        Xin Liu
           Snoop Protocol                               161



         [Balakrishnan95acm]

• Retains local recovery of Split Connection
  approach and link level retransmission
  schemes

• Improves on split connection
  – end-to-end semantics retained
  – soft state at base station, instead of hard state


                         Xin Liu
                                                             162

              Snoop Protocol

                                  Per TCP-connection state

                 TCP connection

application       application              application
transport         transport                transport
network           network                  network
                                    rxmt
link              link                     link
physical          physical                 physical



       FH                BS                       MH
                                wireless
                     Xin Liu
                                                   163

             Snoop Protocol
• Buffers data packets at the base station BS
  – to allow link layer retransmission
• When dupacks received by BS from MH,
  retransmit on wireless link, if packet present
  in buffer
• Prevents fast retransmit at TCP sender FH
  by dropping the dupacks at BS

       FH          BS             MH



                        Xin Liu
                                                                        164

                Snoop : Example
                                    35        TCP state
                                             maintained at
                                    36
                                              link layer
                                    37

                                    38

           40            39                   38         37
FH                                   BS                            MH
                              34                              36




     Example assumes delayed ack - every other packet ack’d


                                   Xin Liu
                                        165

     Snoop : Example
                35       39

                36

                37

                38

41        40             39        38

     34                       36




               Xin Liu
                                                     166

           Snoop : Example
                             37       40

                             38

                             39

      42          41                  40   39

                       36                       36

                                            dupack


Duplicate acks are not delayed


                            Xin Liu
                                               167

     Snoop : Example
                37        40

                38        41

                39

43        42               41        40

     36                         36        36

                         Duplicate acks




               Xin Liu
                                                                       168

               Snoop : Example
                                   37     40

                                   38     41

                                   39     42

         44            43                     37        41
FH                                 BS                             MH
                                                   36        36
                                    Discard
                                    dupack

 Dupack triggers retransmission 36
  of packet 37 from base station

  BS needs to be TCP-aware to
be able to interpret TCP headers
                              Xin Liu
                                            169

     Snoop : Example
              37       40        43

              38       41

              39       42

45      44             42         37

                            36         36




                36


                36


             Xin Liu
                                                           170

                 Snoop : Example
                            37        40        43

                            38        41        44

                            39        42

            46        45              43         42

                                           36         41


TCP sender does not
  fast retransmit             36 36


                              36


                           Xin Liu
                                                      171

                 Snoop : Example
                            37        40        43

                            38        41        44

                            39        42        45

            47        46              44         43

                                           41


TCP sender does not
  fast retransmit             36 36


                              36 36


                           Xin Liu
                                                          172

          Snoop : Example
                  42             45

                  43             46

                  44


     48      47                       45   44
FH                       BS                          MH
                  41                            43




                          36 36


                          36 36


                       Xin Liu
                                                                               173

Snoop [Balakrishnan95acm]

             2000000
             1600000
  bits/sec

             1200000                                                base TCP
              800000                                                Snoop

              400000
                   0




                                                         no error
                       16K
                             32K
                                   64K
                                         128K
                                                  256K
                       1/error rate             (in bytes)




                       2 Mbps Wireless link

                                   Xin Liu
                                                                            174
         Snoop Protocol When Beneficial?


• Snoop prevents fast retransmit from sender despite
  transmission errors, and out-of-order delivery on the
  wireless link

• delivery causes fast retransmit only if it results in at least 3
  dupacks

• If wireless link level delay-bandwidth product is less than
  4 packets, a simple (TCP-unaware) link level
  retransmission scheme can suffice
    – Since delay-bandwidth product is small, the retransmission scheme
      can deliver the lost packet without resulting in 3 dupacks from the
      TCP receiver

                                 Xin Liu
                                               175

 Snoop Protocol : Classification

• Hides wireless losses from the sender

• Requires modification to only BS (network-
  centric approach)




                     Xin Liu
                                                                       176

         Snoop Protocol : Advantages
• High throughput can be achieved
   – performance further improved using selective acks


• Local recovery from wireless losses

• Fast retransmit not triggered at sender despite out-of-order
  link layer delivery

• End-to-end semantics retained

• Soft state at base station
   – loss of the soft state affects performance, but not correctness

                                 Xin Liu
                                                     177

   Snoop Protocol : Disadvantages

• Link layer at base station needs to be TCP-aware

• Not useful if TCP headers are encrypted (IPsec)

• Cannot be used if TCP data and TCP acks traverse
  different paths (both do not go through the base
  station)



                        Xin Liu
                                                178

   WTCP Protocol [Ratnam98]
• Snoop hides wireless losses from the sender
• But sender’s RTT estimates may be larger
  in presence of errors
• Larger RTO results in slower response for
  congestion losses



      FH         BS             MH



                      Xin Liu
                                                             179

                  WTCP Protocol
• WTCP performs local recovery, similar to Snoop

• In addition, WTCP uses the timestamp option to estimate
  RTT
• The base station adds base station residence time to the
  timestamp when processing an ack received from the
  wireless host
• Sender’s RTT estimate not affected by retransmissions on
  wireless link

         FH           BS             MH




                           Xin Liu
                                                     180

          WTCP Example



                3                       3
   FH                         BS                MH
                    4                       3




Numbers in this figure are timestamps

Base station residence time is 1 unit


                         Xin Liu
                                                                         181

               WTCP : Disadvantages
• Requires use of the timestamp option
• May be useful only if retransmission times are large
   – link stays in bad state for a long time
   – link frequently enters a bad state
   – link delay large


• WTCP does not account for congestion on wireless hop
   – assumes that all delay at base station is due to queuing and
     retransmissions
   – will not work for shared wireless LAN, where delays also incurred
     due to contention with other transmitters




                                  Xin Liu
                                                         182

             Optional Reading
• S. Dawkins, et. al, “performance implications of
  link-layer characteristics: links and errors,” tech.
  rep. IETF, June, 1999.
• G. Montenegro, et al, “Long thin networks”, tech.
  rep. IETF, May, 1999.
• Nitin Vaidya,
  http://www.crhc.uiuc.edu/wireless/tutorials.html




                         Xin Liu

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:51
posted:6/21/2011
language:English
pages:182