Docstoc

net-protocol-philosophy

Document Sample
net-protocol-philosophy Powered By Docstoc
					Network Protocols:
Design and Analysis
             Polly Huang
               EE NTU
  http://cc.ee.ntu.edu.tw/~phuang
     phuang@cc.ee.ntu.edu.tw
The Internet Design Philosophy

             [Clark88a]
           [Deering98a]
            [Saltzer81a]
            [Saltzer82a]
The Internet Architecture
       [Clark88a]
                      Key Ideas
• Defines (after-the-fact) the internet
  architecture
• Architecture on following slides, but:
     – Datagrams
     – Multiple link layers
     – Multiple applications and application classes



Polly Huang, NTU EE                                    4
                  The Dream Internet
• How it should be like
     – The starting point -- IP
     – The expansion ground -- around IP
     – The attitude -- desired property




Polly Huang, NTU EE                        5
                       The IP
• Connectionless datagrams (IP) at lowest
  level
     – Packet switching as opposed to circuit
       switching
• Routers and routing protocols
     – The packet switching infrastructure



Polly Huang, NTU EE                             6
                      Around IP
• Multiple protocols on top of that
     – TCP, UDP, etc.
• Multiple applications on top of that
     – Web, e-mail, etc.
• Multiple link layers underneath IP:
     – LANs: Ethernet
     – last-mile: PPP, ISDN, cable modems, DSL
     – “backbone”: Sonet, ATM, others
Polly Huang, NTU EE                              7
                      Desired Properties
•   Availability
•   Reliability
•   Survivability
•   Scalability (hopefully)




Polly Huang, NTU EE                        8
   The Goals

Making them concrete
           The Internet Architecture
• Inter-connecting heterogeneous networks
• Multiplexing via packet switching




Polly Huang, NTU EE                         10
                      Sub-goals
•   Robust to network/gateway failure
•   Multiple kinds of traffic
•   Multiple kinds of networks
•   Distributed management
•   Inexpensive
•   Low effort to add host
•   Resource accounting
Polly Huang, NTU EE                     11
                      Not Original Goals
• Quality of Service




Polly Huang, NTU EE                        12
                      Main Goals
• Heterogeneous networks
     – Why?
     – Allow independent evolution of link-layers
     – multiple LANs, last-mile, and POP-to-POP
       technologies
• Multiplexing
     – Packet switching fundamentally different from
       circuit switching
Polly Huang, NTU EE                                    13
             Back in the Old Days...
                                   the “router”
                                   (Aunt Mable)




                        the wire

         1920s telephony: circuits---a physical wire
         from one end to the other


Polly Huang, NTU EE                                    14
                  Then Came TDM...
                      Time Division Multiplexing

                  mux                              demux




                      … but keeps the idea of a
                      fixed pipe (circuit) the right
                      size for a telephone conversation


Polly Huang, NTU EE                                        15
              And FDM and CDM...
                Frequency Division Multiplexing




                      a a a a a a a a a a a
                       a a a a a a a a a a a

                      Code Division Multiplexing


Polly Huang, NTU EE                                16
              Logical Network View




                fixed size pipe from her to him
                 perfect for voice
                 reliable conversations (QoS) Quality of Service
                 provisioning, good engineering
                dumb end points, smart network
                 evolved for 100 years (analog to digital)
Polly Huang, NTU EE                                                 17
        Packet Switching (Internet)
                differences:
                 packets as low-level component
                 multiple kinds of traffic
                 smart edges, dumb network




                      but:
                       QoS is much harder
                       end-points are more expensive
                       fast routers could be harder (but
                      also probably less complex)
Polly Huang, NTU EE                                         18
       Statistical Multiplexing Gain
Assumptions:
      1 Mb/s link
      user: 0.1Mb/s when transmitting, but 10% duty
        cycle
• Circuit switching: can support 10 users,
  100% reliable
• Packet switching: with 35 users, probability
  that >=10 are transmitting at the same time
                              = 0.0004


Polly Huang, NTU EE                                   19
                      Robust to Failures
• Application should not see transient failures
• Failures
     – Node/link failure (find an alternate path)
     – Packet lost due to congestion (queue overflow),
     – Packet lost due to transmission errors (node failures)




Polly Huang, NTU EE                                             20
                      Thus, Rule #1
• All states at endpoints
     – States set by datagrams
     – Retransmit if packets lost
• The philosophy
     – Fate-sharing
     – If end crashes, it doesn’t care


Polly Huang, NTU EE                      21
                      And, Rule #2
• Some states are only appropriate to be kept in the
  network
     • States set by control messages
     • Periodic refresh in case of un-sync states
• The philosophy
     – Soft-state
     – Periodically repeat the state
     – To allow recovery from lost info, without specific
       action per failure
Polly Huang, NTU EE                                         22
            Multiple Types of Service
• Originally just NCP, but split        • TCP
  to {TCP,UDP}/IP                         – Interactive, low-
• Why?                                      latency
   – Varying needs in speed, latency,     – Bulk delivery
     reliability
   – Not just bi-directional reliable   • UDP
     data "virtual circuit"               – Lightweight
• IP: best effort datagram                – Out-of-order to user
    Bad if link layer wants to do
     too much                             – Low-latency & jitter,
    PILC working group in IETF             RT possible for voice
     today                                – Reliability is biggest
                                            source of jitter

   Polly Huang, NTU EE                                               23
              Non-TCP/UDP protocols
•   RDP: Reliable Delivery Protocol       • DCCP: Datagram Congestion
     – Message-based                        Control Protocol
     – Allows out-of-order delivery           – Add congestion control to UDP
     – RFC-908                                – In progress
•   SCTP: Stream Control Transmission     • XCP: Explicit Control Protocol
    Protocol                                  – High-speed streaming with explicit
     – Intended for telephony signaling         router rate feedback
        over IP                               – Presented at SIGCOMM
     – Multiplexes multiple “streams”
        per connection
     – In-sequence per stream, out-of-
        sequence between streams
     – Reliable
     – RFC-3286



    Polly Huang, NTU EE                                                     24
               Multiple Applications
• Classes of applications                • Requirements:
     –   Web                                –   Loss resilience
     –   File transfer (Napster, etc.)      –   Delay/jitter sensitivity
     –   Remote login                       –   Bursty/smooth
     –   Streaming audio                    –   Point-to-point vs. n-way
     –   Interactive audio                  –   Numbers of sources and
     –   Streaming/interactive video            sinks
     –   Computer appliances
     –   Others?



Polly Huang, NTU EE                                                        25
        Multiple kinds of networks
• IP over X                   • Requirements of X:
• Compare to integrated          – Reasonable size packets
                                     • But fragmentation and
  stacks:                              reassembly
     – ISO                       – Reasonable reliability
     – ATM                           • But workarounds
     – Fibre channel, Apple      – Addressing
       Desktop Bus, USB       • Non-requirements of X:
                                 – Reliable, in-order, broadcast,
• But a counter example:           QoS, etc.
  SCSI and now SCSI
  over IP
Polly Huang, NTU EE                                                 26
                      Other goals
• Distributed management
     – Some work, and today policy routing exists
     – But limitations (ex. address space portability)
• Cost effective
     – Today quite cheap
     – But for small devices? for keyboard?


Polly Huang, NTU EE                                      27
                      Other other goals
• Effort to deploy end host
     – For him in ’88: cost of implementing stack
     – Today: cost of administering machine
          • Much lower today (DHCP, etc.)
          • But still lots of manual configuration “futzing”
• Accountability
     – Basically nothing then
          • Today: PPPoE created just for authentication
Polly Huang, NTU EE                                            28
 Architecture and Implementation
• Realization: an instance of the Internet class
     – Him: 1200b/s modem vs. 1Mb/s LAN
     – Today: the Internet can’t do X because it is Y
          • ex. can’t do System Area Networks over IP because it’s too
            slow, so we need Fibre Channel
          • alternative: build a fast Internet realization
     – Corollary: not every realization is appropriate for every
       application
     – Also: custom stack will get last 5% of performance, but
       is it worth it?
Polly Huang, NTU EE                                                      29
                      TCP Features
• Features:
     – Connection establishment, connectionless
       communication,
     – Congestion avoidance, flow control,
     – Duplicate packet detection, loss recovery,
     – Ordered data delivery to the application, out-of-order
       data delivery to the application,
     – Differentiated services, quality-of-service, urgent data
       indication
     – Message or record boundaries,

Polly Huang, NTU EE                                               30
           TCP Alternative Choices
•   Byte stream vs. message stream
•   Flow control
•   Congestion control came later
•   PSH flag
     – A weak record boundary
     – But the reason the Plan-9 people didn’t use
       TCP

Polly Huang, NTU EE                                  31
 Other Components of IP Success
• A good, free implementation
     – BSD Unix in the mid-80’s
     – Compare to OSI where implementations were late
• A good API
     – BSD socket API
     – Not perfect, but good
     – Compare to OS’s where Unix and Windows have very
       different APIs to open/rename/etc. files


Polly Huang, NTU EE                                       32
Questions?
Watching the Waist of IP
     [Deering98a]
                      Key Idea
• The importance of a single, narrow layer
  for interoperability
• In the Internet, it’s IP
     – Many link layers and hardware below
     – many protocols and applications above
     – One network layer to rule them all, one network
       layer to bind them…

Polly Huang, NTU EE                                 35
                      IP




Polly Huang, NTU EE        36
   Why a single, narrow protocol?
• Why single:
     – Maximize interoperability
     – Minimize amount of work needed to support
       new protocols
• Why narrow:
     – Minimize requirements from lower layers
     – End-to-end argument: don’t want to weigh
       down IP with a bunch of things that are
       unnecessary by many of its users
Polly Huang, NTU EE                                37
   What are the key IP properties?
• Small and simple
     – Connectionless datagram
• Global addressing
     – Maximize connectivity
     – Much harder to provide global addressability at higher
       layer
     – Enable applications (ex. peer-to-peer file sharing)
     – But addressability make security harder => NAT boxes,
       firewalls



Polly Huang, NTU EE                                        38
          Why add to or change IP?
• More features are cooler
     – QoS, multicast, …
• More features make more money
• Replacing it makes lots of money
     – And could do new things if everyone buys in
     – Ex. ATM
• Have short-term (?) problems that have to be
  solved (via work-arounds)
     – Address space size: NAT

Polly Huang, NTU EE                                  39
    Other questions/observations?
• Active network: idea that end-users (or admins)
  should be able reprogram the network
• Size of IP headers: 40B is this a problem
     – Interactions w/ATM or other link-layers w/short MTUs
     – Could be problem (high overhead) for telnet
• QoS and multicast
     – Why not depoyed? increase assumptions lower layers,
       we need to change all routers, not everyone needs
       services, difficult to transition research into company,
       maybe can do these things above IP…

Polly Huang, NTU EE                                               40
Questions?
The End-to-End Argument:
      [Saltzer81a]
                      Key Idea
• The end-to-end argument
     – Don’t duplicate functionality in multiple levels
       if you have to do it at the top anyway




Polly Huang, NTU EE                                   43
                      Key ideas
• Where should services (encryption, reliability,
  ordering, duplicate suppression) be placed: at the
  end points or in the network?

• Since these can be done at higher layers, and
  expensive to to do these at the lower layers, maybe
  just do them at the ends
     – Especially if the ends MUST do it
     – But maybe performance motivates putting it also at
       lower layers


Polly Huang, NTU EE                                         44
                 Example: Reliability
• Consider copying a file
     – Want an end-to-end checksum
• Steps:
     – A reads from disk to mem; sends to network
     – Network moves data from A to B
     – B gets data from network; writes to disk
• Possible faults:
     – Disk IO errors, buffer overruns in NIC, memory errors,
       network corruption or congestion, computer crashes
Polly Huang, NTU EE                                         45
            Other examples in paper
•   Encrypted data transfer
•   Duplicate message suppression
•   Guaranteed FIFO message delivery
•   Transactions in a DB




Polly Huang, NTU EE                    46
                      Other examples?
• Instant messaging uses UDP, the
  application provides reliability
• Congestion control
• Microkernels: minimal operating system
  functionality
• RPC systems: remote procedure call (and
  reliability)

Polly Huang, NTU EE                         47
                 Caveat: performance
• Consider file copy again
• Reliability at physical, link, network,
  transport, application layers
     – Ex. in wireless, might want hop-by-hop
       reliability because the loss/corruption rate is
       much higher than wired networks
• Multiple levels may be needed for
  performance
Polly Huang, NTU EE                                      48
    Challenge: Defining the “End”
• Ex. security: what is the protocol and end for each app?
     – Ordering over web at Amazon.com? ends customers web browser
       and Amazon’s transaction server
     – Connecting over the Internet to USC with a VPN? network side
       your computer, (end server on) USC network [my PC to USC’s
       network]
     – Using a wireless base-station with WEP? my computer to the
       access point/wireless LAN
     – Entering my PIN at a bank ATM? human to bank (?)




Polly Huang, NTU EE                                               49
 Why is End-to-End Important to
        Network Design?
      smart vs.       Telephone   Internet
      dumb?
      Network         xxx         xxx

      Terminal        xxx         xxx




Polly Huang, NTU EE                          50
Questions?
On Naming
[Saltzer82a]
                      Context
• 1982: fairly early on in the net
     – Ethernet only a few years old
     – basic networking terminology still evolving
• Background for routing (next class)




Polly Huang, NTU EE                                  53
                      Key ideas
•   Defining the terms (objects) for naming
•   Binding: mapping names to address
•   Give characteristics of
•   Names




Polly Huang, NTU EE                           54
                      Terminology
• Name: what you want
• Address: where it is
• Route/path: how to get there
• Binding: process of mapping name to an
  address
• [Context]: the state needed to do binding

Polly Huang, NTU EE                           55
                 Naming and Change
• Naming only matters because things change
     – If no change, things can be hard-coded
     – Ex. users/services/machines move, processes
       start and stop, etc.
     – Mobile hosts, web services, both for content
       and virtual hosts (multiple web sites on single
       computer), load balance


Polly Huang, NTU EE                                      56
           Characteristics of Names
• Uniqueness: globally unique, unique in some context
  (locally unique), probabilistically unique, not unique
• Length
• User friendless: human-readable
     –   Alphabetics vs. binary
     –   Moderate length vs. long
     –   Memorable vs. not memorable
     –   Easily transcribable vs. more difficult
• Hierarchical vs. flat
• Assigned from a central authority vs. distributed



Polly Huang, NTU EE                                        57
                                                              the
                 Nodes vs. Interfaces                      Internet
                                                         ISP
                                                        router
                                                            8.1.1.2
                                                     dsl
• What does an IP address identify?                  link 8.1.1.1
                                                          my
     – Interface, not a node
                                                        router
• Why?                                             internal
                                                            10.0.0.1
     – To control where packets go                 LAN my home
     – So firewall rules can tell “outside” from      10.0.0.2 PC
       “inside”                                       10.0.0.3 my
• Problems?                                                   laptop

     – Sometimes you want to get to the node and an
       interface is too specific (ex. if it’s down)


Polly Huang, NTU EE                                             58
Questions?

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