Network Protocols: Design and Analysis-The Internet Architecture

Network Protocols:

Design and Analysis

Polly Huang EE NTU

http://cc.ee.ntu.edu.tw/~phuang [email protected]

The Internet Design Philosophy

[Clark88a]

[Deering98a]

The Internet Architecture

[Clark88a]

Key Ideas

• Defines (after-the-fact) the internet architect

ure

• Architecture on following slides, but:

– Datagrams

– Multiple link layers

The Dream Internet

• How it should be like

– The starting point -- IP

– The expansion ground -- around IP

– The attitude -- desired property

The IP

• Connectionless datagrams (IP) at lowest lev

el

– Packet switching as opposed to circuit switchin

g

• Routers and routing protocols

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

Desired Properties

• Availability

• Reliability

• Survivability

The Goals

The Internet Architecture

• Inter-connecting heterogeneous networks

• Multiplexing via packet switching

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

Not Original Goals

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

Back in the Old Days...

1920s telephony: circuits---a physical wire

from one end to the other

the wire

the “router” (Aunt Mable)

Then Came TDM...

mux demux

Time Division Multiplexing

… but keeps the idea of a fixed pipe (circuit) the right

And FDM and CDM...

Frequency Division Multiplexing

Code Division Multiplexing

a a a a a a a a a a a 

Logical Network View

fixed size pipe from her to him  perfect for voice

 reliable conversations (QoS)  provisioning, good engineering dumb end points, smart network

 evolved for 100 years (analog to digital)

Packet Switching (Internet)

differences:

 packets as low-level component  multiple kinds of traffic

 smart edges, dumb network

but:

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

Robust to Failures

• Application should not see transient failures

• Failures

– Node/link failure (find an alternate path)

– Packet lost due to congestion (queue overflow),

Thus, Rule #1

• All states at endpoints

– States set by datagrams

– Retransmit if packets lost

• The philosophy

– Fate-sharing

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

Multiple Types of Service

• Originally just NCP, but split to {TCP,UDP}/IP

• Why?

– Varying needs in speed, latency, reliability

– Not just bi-directional reliable data "virtual circuit"

• IP: best effort datagram

 Bad if link layer wants to do

too much

 PILC working group in IETF today

• TCP

• UDP

RT possible for voice – Reliability is biggest

Non-TCP/UDP protocols

• RDP: Reliable Delivery Protocol – Message-based

– Allows out-of-order delivery – RFC-908

• SCTP: Stream Control Transmission Protocol

– Intended for telephony signaling over IP

– Multiplexes multiple “streams” per connection

– In-sequence per stream, out-of-sequence between streams

– Reliable

• DCCP: Datagram Congestion Control Protocol

– Add congestion control to UDP – In progress

• XCP: Explicit Control Protocol

– High-speed streaming with explicit router rate feedback

Multiple Applications

• Classes of applications

– Web

– File transfer (Napster, etc.) – Remote login – Streaming audio – Interactive audio – Streaming/interactive video – Computer appliances – Others? • Requirements: – Loss resilience – Delay/jitter sensitivity – Bursty/smooth – Point-to-point vs. n-way – Numbers of sources and sin

Multiple kinds of networks

• IP over X

• Compare to integrated

stacks:

– Fibre channel, Apple D esktop Bus, USB

• But a counter example:

• Requirements of X:

– Reasonable size packets

• But fragmentation and rea ssembly

– Reasonable reliability

• But workarounds

– Addressing

• Non-requirements of X:

Other goals

• Distributed management

– Some work, and today policy routing exists

– But limitations (ex. address space portability)

• Cost effective

– Today quite cheap

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

Architecture and Implementation

• Realization: an instance of the Internet class

– Today: the Internet can’t do X because it is Y

• ex. can’t do System Area Networks over IP because it’s too slo w, 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?

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

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

Other Components of IP Success

• A good, free implementation

– Compare to OSI where implementations were late

• A good API

– BSD socket API

– Not perfect, but good

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

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

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

Why add to or change IP?

• More features are cooler

• 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 solve

d (via work-arounds)

Other questions/observations?

• Active network: idea that end-users (or admins) sh

ould 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 servi

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

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

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

Other examples in paper

• Encrypted data transfer

• Duplicate message suppression

• Guaranteed FIFO message delivery

• Transactions in a DB

Other examples?

• Instant messaging uses UDP, the applicatio

n provides reliability

• Congestion control

• Microkernels: minimal operating system fu

nctionality

• RPC systems: remote procedure call (and re

liability)

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

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

Why is End-to-End Important to

Network Design?

smart vs.

dumb?

Telephone

Internet

Network

xxx

xxx

Terminal

xxx

xxx

On Naming

[Saltzer82a]

Context

• 1982: fairly early on in the net

– Ethernet only a few years old

– basic networking terminology still evolving

Key ideas

• Defining the terms (objects) for naming

• Binding: mapping names to address

• Give characteristics of

• Names

Terminology

• Name: what you want

• Address: where it is

• Route/path: how to get there

• Binding: process of mapping name to an

address

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

Characteristics of Names

• Uniqueness: globally unique, unique in some context (loca lly 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

Nodes vs. Interfaces

• What does an IP address identify?

• Why?

– To control where packets go

– So firewall rules can tell “outside” from “inside”

• Problems?

– Sometimes you want to get to the node and

my router the Internet 8.1.1.1 8.1.1.2 ISP router dsl link internal LAN my home PC my laptop 10.0.0.1 10.0.0.2 10.0.0.3