Docstoc

ppt

Document Sample
ppt Powered By Docstoc
					    Midterm Review

In class, 9:30-11 am, Tu. 2/10
         Close Book
One 8.5” by 11” sheet of paper
   permitted (single side)
                 Lecture 1
• Internet Architecture
• Network Protocols
• Network Edge
• A taxonomy of communication networks
A Taxonomy of Communication Networks
• The fundamental question: how is data
  transferred through net (including edge & core)?
• Communication networks can be classified based
  on how the nodes exchange information:
                                           Communication
                                             Networks


                  Switched                                            Broadcast
                Communication                                       Communication
                  Network                                             Network



     Circuit-Switched           Packet-Switched
     Communication              Communication
         Network                   Network


   TDM             FDM     Datagram       Virtual Circuit Network
                           Network
Packet Switching: Statistical Multiplexing
         10 Mbs
A        Ethernet     statistical multiplexing   C

                           1.5 Mbs
    B
           queue of packets
           waiting for output
                  link


                           D                     E

    Sequence of A & B packets does not have fixed
      pattern  statistical multiplexing.
    In TDM each host gets same slot in revolving TDM
      frame.
 Packet Switching versus Circuit Switching
• Packet Switching
   – Network resources (e.g., bandwidth) divided into
     “pieces” for allocation
   – Resource piece idle if not used by owning call (no
     sharing)
   – Dividing link bandwidth into “pieces”
   – Great for bursty data
   – NOT efficient !
• Circuit Switching:
   – Excessive congestion: packet delay and loss
   – protocols needed for reliable data transfer,
     congestion control
    Datagram Packet Switching
• Each packet is independently switched
  – Each packet header contains destination address
    which determines next hop
  – Routes may change during session
• No resources are pre-allocated (reserved) in
  advance
• Example: IP networks
 Virtual-Circuit Packet Switching
• Hybrid of circuit switching and packet
  switching
  – All packets from one packet stream are sent along a
    pre-established path (= virtual circuit)
  – Each packet carries tag (virtual circuit ID), tag
    determines next hop
• Guarantees in-sequence delivery of packets
• However, packets from different virtual
  circuits may be interleaved
• Example: ATM (Asynchronous Transfer Mode)
  networks
              Lecture 2
• Network access and physical media
• Internet structure and ISPs
• Delay & loss in packet-switched
  networks
• Protocol layers, service models
   Internet structure: network of networks
 • “Tier-3” ISPs and local ISPs
     – last hop (“access”) network (closest to end systems)
     – Tier-3: Turkish Telecom, Minnesota Regional Network

                  local
                           Tier 3                   local
                  ISP                    local              local
                            ISP                     ISP
                                         ISP               ISP
Local and tier-
                           Tier-2 ISP            Tier-2 ISP
3 ISPs are
customers of                        Tier 1 ISP
higher tier                                           NAP
ISPs
connecting
them to rest
                          Tier 1 ISP             Tier 1 ISP
of Internet                                                         Tier-2 ISP
                                                                          local
                    Tier-2 ISP           Tier-2 ISP
              local         local          local                          ISP
               ISP           ISP            ISP
  Four sources of packet delay
• 1. processing:                   • 2. queueing
     – check bit errors                – time waiting at output
                                         link for transmission
     – determine output link
                                       – depends on congestion
                                         level of router

             transmission
 A                             propagation


     B
              processing
                            queueing
Delay in packet-switched networks
3. Transmission delay:          4. Propagation delay:
• R=link bandwidth (bps)        • d = length of physical link
• L=packet length (bits)        • s = propagation speed in
                                  medium (~2x108 m/sec)
• time to send bits into
  link = L/R                    • propagation delay = d/s
                                Note: s and R are very
                                  different quantities!
          transmission
A                          propagation


    B
           processing
                         queueing
            Internet protocol stack
• application: supporting network applications
   – FTP, SMTP, STTP
                                                 application
• transport: host-host data transfer
   – TCP, UDP                                    transport
• network: routing of datagrams from source       network
  to destination
   – IP, routing protocols                          link
• link: data transfer between neighboring
                                                  physical
  network elements
   – PPP, Ethernet

• physical: bits “on the wire”
            Application Layer
• Principles of app layer protocols
• Web and HTTP
• FTP
• Electronic Mail: SMTP, POP3, IMAP
• DNS
• Socket Programming
• Web Caching
            HTTP connections
Nonpersistent HTTP        Persistent HTTP
• At most one object is   • Multiple objects can be
  sent over a TCP           sent over single TCP
  connection.               connection between
                            client and server.
• HTTP/1.0 uses
  nonpersistent HTTP      • HTTP/1.1 uses
                            persistent connections
                            in default mode


• HTTP Message, Format, Response, Methods
• HTTP cookies
            Response Time of HTTP
Nonpersistent HTTP issues:      Persistent without pipelining:

• requires 2 RTTs per object    • client issues new request
                                  only when previous
• OS must work and allocate       response has been received
  host resources for each TCP
  connection                    • one RTT for each
                                  referenced object
• but browsers often open
  parallel TCP connections to   Persistent with pipelining:
  fetch referenced objects
                                • default in HTTP/1.1
Persistent HTTP
                                • client sends requests as
• server leaves connection        soon as it encounters a
  open after sending response     referenced object

• subsequent HTTP messages      • as little as one RTT for all
  between same client/server      the referenced objects
  are sent over connection
  FTP: separate control, data connections
• FTP client contacts FTP server             TCP control connection
                                                    port 21
  at port 21, specifying TCP as
  transport protocol
                                             TCP data connection
• Client obtains authorization over FTP                             FTP
                                                   port 20
  control connection                client                         server
• Client browses remote directory
                                   • Server opens a second TCP
  by sending commands over
                                     data connection to transfer
  control connection.
                                     another file.
• When server receives a
                                   • Control connection: “out of
  command for a file transfer, the
                                     band”
  server opens a TCP data
  connection to client             • FTP server maintains “state”:
                                     current directory, earlier
• After transferring one file,
                                     authentication
  server closes connection.
     Electronic Mail: SMTP [RFC 2821]
• uses TCP to reliably transfer email message from client to server,
  port 25
• direct transfer: sending server to receiving server
• three phases of transfer
   – handshaking (greeting)
   – transfer of messages
   – closure
• command/response interaction
   – commands: ASCII text
   – response: status code and phrase

• messages must be in 7-bit ASCII
                 DNS name servers
                        • no server has all name-to-IP
Why not centralize DNS?   address mappings
• single point of failure   local name servers:
• traffic volume               – each ISP, company has local
                                 (default) name server
• distant centralized
  database                     – host DNS query first goes to
                                 local name server
• maintenance
                            authoritative name server:
                               – for a host: stores that host’s
doesn’t scale!                   IP address, name
                               – can perform name/address
                                 translation for that host’s
                                 name
     DNS example                        root name server



Root name server:                                          6
                                    2
• may not know                             7       3
  authoritative name
  server
• may know                                     intermediate name server
                       local name server
  intermediate name                                  dns.nwu.edu
                       dns.eurecom.fr
  server: who to                                       4       5
  contact to find              1    8
  authoritative name
  server                                       authoritative name server
                                                   dns.cs.nwu.edu
                       requesting host
                       surf.eurecom.fr

                                                   www.cs.nwu.edu
DNS: iterated queries                     root name server


recursive query:                                        iterated query
                                      2
• puts burden of name                        3
  resolution on                                  4
  contacted name
  server                                          7

                         local name server       intermediate name server
• heavy load?                                         dns.umass.edu
                         dns.eurecom.fr

iterated query:
                                                         5    6
                                 1    8

• contacted server                               authoritative name server
  replies with name of                             dns.cs.umass.edu
  server to contact      requesting host
                         surf.eurecom.fr
• “I don’t know this
                                                      gaia.cs.umass.edu
  name, but ask this
  server”
          Web caches (proxy server)
Goal: satisfy client request without involving origin server

• user sets browser: Web                                origin
  accesses via cache                                    server

                                           Proxy
• browser sends all HTTP                   server
  requests to cache              client

  – object in cache: cache
    returns object
  – else cache requests object
    from origin server, then
    returns object to client      client
                                                        origin
                                                        server
• Why web caching?
                  Caching example (3)
Install cache
                                                                        origin
• suppose hit rate is .4                                              servers
Consequence                                       public
                                                 Internet
• 40% requests will be satisfied
  almost immediately
• 60% requests satisfied by origin                      1.5 Mbps
  server                                                access link

• utilization of access link reduced   institutional
                                         network
  to 60%, resulting in negligible                           10 Mbps LAN
  delays (say 10 msec)
• total delay = Internet delay +
  access delay + LAN delay                                   institutional
                                                                cache
 = .6*2 sec + .6*.01 secs +
  milliseconds < 1.3 secs
             Transport Layer
• Transport-layer services
• Multiplexing and demultiplexing
• Connectionless transport: UDP
• Principles of reliable data transfer
• TCP
  – Segment structures
  – Flow control
  – Congestion control
               Demultiplexing
• UDP socket identified    • TCP socket identified by
  by two-tuple:              4-tuple:
  (dest IP address, dest      – source IP address
  port number)
                              – source port number
• When host receives
  UDP segment:                – dest IP address

   – checks destination       – dest port number
     port number in        • recv host uses all four
     segment
                             values to direct segment
   – directs UDP segment     to appropriate socket
     to socket with that
     port number
UDP: User Datagram Protocol [RFC 768]

             32 bits              Why is there a UDP?
 source port #    dest port #
                                  • no connection
    length             checksum     establishment (which can
                                    add delay)
                                  • simple: no connection state
                                    at sender, receiver
        Application
          data                    • small segment header
        (message)
                                  • no congestion control: UDP
                                    can blast away as fast as
                                    desired
    UDP segment format
                       UDP checksum
  Goal: detect “errors” (e.g., flipped bits) in transmitted
    segment
                                 Receiver:
Sender:
                                 • addition of all segment
• treat segment contents as
                                   contents + checksum
  sequence of 16-bit integers
                                 • check if all bits are 1:
• checksum: addition (1’s
  complement sum) of segment         – NO - error detected
  contents
                                     – YES - no error detected.
• sender puts checksum value            But maybe errors
  into UDP checksum field               nonetheless? More later
                                        ….
                       0110                            0110
                       0101                            0101
           Addition:   1011     1’s complement sum:    0100
1’s complement sum:    0100                Addition:   1111
   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
         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

• new mechanisms in rdt2.0 (beyond rdt1.0):
   – error detection
   – receiver feedback: control msgs (ACK,NAK) rcvr->sender
          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)
           rdt2.0 has a fatal flaw!
What happens if ACK/NAK
 corrupted?                    Handling duplicates:
                               • sender adds sequence
• sender doesn’t know what
                                 number to each pkt
  happened at receiver!
                               • sender retransmits current
• can’t just retransmit:
                                 pkt if ACK/NAK garbled
  possible duplicate
                               • receiver discards (doesn’t
What to do?                      deliver up) duplicate pkt
• sender ACKs/NAKs               stop and wait
  receiver’s ACK/NAK? What       Sender sends one packet,
  if sender ACK/NAK lost?        then waits for receiver
                                 response
• retransmit, but this might
  cause retransmission of
  correctly received pkt!
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)
       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
    rdt3.0: channels with errors and loss

New assumption:                   Approach: sender waits
  underlying channel can            “reasonable” amount of
  also lose packets (data           time for ACK
  or ACKs)                        • retransmits if no ACK
   – checksum, seq. #, ACKs,        received in this time
     retransmissions will be of
                                  • if pkt (or ACK) just delayed
     help, but not enough
                                    (not lost):
Q: how to deal with loss?            – retransmission will be
   – sender waits until it is          duplicate, but use of seq.
     certain that data or ACK          #’s already handles this
     lost, then retransmits          – receiver must specify seq
   – yuck: drawbacks?                  # of pkt being ACKed
                                  • requires countdown timer
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
                       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”
   – may deceive duplicate ACKs (see receiver)
• Single timer for all in-flight pkts
• timeout(n): retransmit pkt n and all higher seq # pkts in window
                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
Selective repeat: sender, receiver windows
                 TCP segment structure
                                      32 bits
  URG: urgent data                                             counting
(generally not used)    source port #         dest port #
                                                               by bytes
                               sequence number                 of data
       ACK: ACK #
             valid         acknowledgement number              (not segments!)
                       head not
PSH: push data now      len used
                                 UA P R S F   Receive window
(generally not used)                                             # bytes
                           checksum           Urg data pnter
                                                                 rcvr willing
    RST, SYN, FIN:                                               to accept
                           Options (variable length)
   connection estab
   (setup, teardown
         commands)
                                     application
           Internet                     data
          checksum                (variable length)
        (as in UDP)
 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
               Fast Retransmit
• Time-out period often         • If sender receives 3
  relatively long:                ACKs for the same
  – long delay before
                                  data, it supposes that
    resending lost packet         segment after ACKed
                                  data was lost:
• Detect lost segments
  via duplicate ACKs.              – fast retransmit: resend
                                     segment before timer
  – Sender often sends many          expires
    segments back-to-back
  – If segment is lost, there
    will likely be many
    duplicate ACKs.
  TCP Flow control: how it works
                              • Rcvr advertises spare
                                room by including value
                                of RcvWindow in
                                segments

(Suppose TCP receiver         • Sender limits unACKed
  discards out-of-order         data to RcvWindow
  segments)                      – guarantees receive
                                   buffer doesn’t overflow
• spare room in buffer
= RcvWindow
= RcvBuffer-[LastByteRcvd -
  LastByteRead]
              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

                      CongWin      • TCP sender reduces
                                      rate (CongWin) after
• Roughly,                            loss event
                CongWin
     rate =             Bytes/sec   three mechanisms:
                 RTT
• CongWin is dynamic, function         – AIMD
  of perceived network
                                       – slow start
  congestion
                                       – conservative after
                                         timeout events
                   TCP Slow Start
• When connection begins, • When connection begins,
  CongWin = 1 MSS           increase rate
                            exponentially fast until
   – Example: MSS = 500     first loss event
     bytes & RTT = 200 msec
   – initial rate = 20 kbps

• available bandwidth may
  be >> MSS/RTT
   – desirable to quickly ramp
     up to respectable rate
                      Refinement
                                  Philosophy:
• After 3 dup ACKs:
                                  • 3 dup ACKs indicates
   – CongWin is cut in half       network capable of
   – window then grows linearly   delivering some segments
                                  • timeout before 3 dup
• But after timeout event:        ACKs is “more alarming”
   – Enter “slow start”
   – CongWin instead set to 1
     MSS;
   – window then grows
     exponentially
   – to a threshold, then grows
     linearly
               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
                     Delay modeling

                                 Notation, assumptions:
Q: How long does it take to
  receive an object from a       • Assume one link between
                                   client and server of rate R
  Web server after sending
  a request?                     • S: MSS (bits)

Ignoring congestion, delay is    • O: object size (bits)
  influenced by:                 • no retransmissions (no loss,
                                   no corruption)
• TCP connection establishment
• data transmission delay
                                 Window size:

• slow start                     • First assume: fixed
                                   congestion window, W
                                   segments
   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
  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]
                       HTTP Modeling
•   Assume Web page consists of:
     – 1 base HTML page (of size O bits)
     – M images (each of size O bits)
•   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
HTTP Response time (in seconds)
    RTT = 100 msec, O = 5 Kbytes, M=10 and X=5
            20
            18
            16
            14
                                                   non-persistent
            12
            10
                                                   persistent
             8
             6
                                                   parallel non-
             4
                                                   persistent
             2
             0
                   28   100     1     10
                Kbps Kbps Mbps Mbps
For low bandwidth, connection & response time dominated by
transmission time.
Persistent connections only give minor improvement over parallel
connections for small RTT.
HTTP Response time (in seconds)
        RTT =1 sec, O = 5 Kbytes, M=10 and X=5
              70
              60
              50
                                                    non-persistent
              40
              30                                    persistent

              20
                                                    parallel non-
              10                                    persistent
               0
                    28     100  1    10
                   Kbps   Kbps Mbps Mbps
For larger RTT, response time dominated by TCP establishment
& slow start delays. Persistent connections now give important
improvement: particularly in high delaybandwidth networks.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:1/2/2013
language:English
pages:51