TCOM 512 Course plan

1
TCOM 512 Course plan

• Fall 2003

2
Questions for first class?

• What is a protocol?
• What is an API (application programming
  interface) ?
• Why the concept of layering?
• End-to-end argument

3
Why is communication important?

• Resource sharing
• unique resources
• location specific
• Load sharing
• performance
• economy of scale
• reliability
• Information sharing
• Communication

4
What are protocols ?

• Human protocol vs Computer network protocol
• A series of functions performed at different
  locations.

Hi
TCP connection req.
Get lost??
Hi
5
Protocols and protocol implementations

• Building blocks of a network architecture
• Each protocol object has two different interfaces
• service interface defines operations on this
  protocol
• peer-to-peer interface defines messages
  exchanged with peer

Li1
Li1
service interface
Li
Li
peer interface
6
What is Layering?

• A technique to organize a system into a
  succession of logically distinct entities, such
  that the service provided by one entity is solely
  based on the service provided by the previous
  (lower level) entity
• Decomposition of a complex system into an ordered
  series of distinct abstractions
• Layering
• Service what a layer does (e.g. message
  delivery)
• Interface how to use the service
• Protocol how the service is implemented
• Protocol stack collection of protocols
  implementing a series of layers

7
Divide and conquerAnalogy Organization of air
travel

• Protocols a series of functions performed at
  different locations

8
Organization of air travel a different view
interface

• Layers each layer implements a service
• via its own internal-layer actions
• relying on services provided by layer below

9
Layered air travel services
Counter-to-counter delivery of personbags baggag
e-claim-to-baggage-claim delivery people
transfer loading gate to arrival
gate runway-to-runway delivery of plane
airplane routing from source to destination
Similarly, we organize computer systems into a
bunch of layers! Each layer has a protocol to
talk to its peer
10
Distributed implementation of layers
ticket (purchase) baggage (check) gates
(load) runway takeoff airplane routing
ticket (complain) baggage (claim) gates
(unload) runway landing airplane routing
arriving airport
Departing airport
intermediate air traffic sites
11
Encapsulation

• A layer can use only the service provided by the
  layer immediate below it
• Each layer may change and add a header to data
  packet

data
data
data
data
data
data
data
data
data
data
data
data
data
data
12
Protocol layering and data

• Each layer takes data from above
• adds header information to create new data unit
  (encapsulation)
• passes new data unit to layer below

source
destination
message
segment
datagram
frame
13
ISO OSI Reference Model

• Seven layers
• Lower three layers are peer-to-peer
• Next four layers are end-to-end

Application
Application
Presentation
Presentation
Session
Session
Transport
Transport
Network
Network
Network
Datalink
Datalink
Datalink
Physical
Physical
Physical
Physical medium
14
Layering logical communication

• E.g. transport
• take data from app
• add addressing, reliability check info to form
  datagram
• send datagram to peer
• wait for peer to ack receipt
• analogy post office

transport
transport
(Source Kurose Ross)
15
Example Transport Protocol(Physical
Communication)
(Source Kurose Ross)
16
Why Layering?
(FTP File Transfer Protocol, NFS Network File
Transfer, HTTP World Wide Web protocol)
FTP
NFS
Telnet
Application
Coaxial cable
Fiber optic
Transmission Media

• No layering each new application has to be
  re-implemented for every network technology!

17
Why Layering?

• Solution introduce an intermediate layer that
  provides a unique abstraction for various network
  technologies

FTP
NFS
Telnet
Application
Intermediate layer
Coaxial cable
Fiber optic
Transmission Media
18
Layering

• Advantages
• Modularity protocols easier to manage and
  maintain
• Abstract functionality lower layers can be
  changed without affecting the upper layers
• Reuse upper layers can reuse the functionality
  provided by lower layers
• Encapsulation functionality in a layer is
  self-contained
• Disadvantages
• Information hiding inefficient implementations
• Introduces overhead can lead to intentional
  layer violations

19
Layered Protocol Architecture

• Protocol rules and conventions for
  communication between peers including syntax,
  semantics, and timing
• Service Interface rules and conventions for
  communication between clients and service
  including syntax and timing
• Service Model semantics of interface operations
  offered by service to clients, and underlying
  channel characteristics (performance,
  reliability, etc.)
• Recursive service interface and model
  implemented internally by protocol

20
Protocols vs. APIs

• Protocols
• Needed for interoperability between platforms
  (possibly built by different vendors)
• A vertical partitioning between communicating
  entities
• Protocols as communicating finite state machines
  
• Protocol Finite State Machine Message Set
• Specify not only what must be done but how it is
  done

21
Protocols vs. APIs

• APIs
• Needed for portability of software across
  platforms (from different vendors)
• A horizontal partitioning of software on a
  platform
• Specify only what must be done, not how the
  implementation does it
• Bottom-up view
• Coalesce related states of the protocol into
  objects with appropriate methods
• Top-down view
• Define objects that are logical units for the
  user of the API (i.e., the application or
  programmer)
• API can be defined without regard to protocols

22
Architectural context for the API
Application
Local or Remote Access Mechanism (e.g., RMI,
CORBA)
API
Gateways
23
APIs

• Application layer
• JAIN JCC/JCAT, PARLAY, OSA, JTAPI
• Web services WSDL, UDDI, SOAP
• Middleware
• CORBA, MOM, RPC, RMI
• Transport
• Sockets, SIP API, JAIN SIP

24
Interface Design

• Driven by three factors
• Functionality what features the customer wants,
  and is placed at a level due to e2e principle etc
• Technology whats possible. Building blocks and
  techniques
• Performance How fast etc User, Designer,
  Operator views of performance ..
• Interface design crucial because interface
  outlives the technology used to implement the
  interface.

25
Layered Protocol Architecture
TELNET
TELNET
Interfaces
Host 1
TCP
TCP
Host 2
Protocols
IP
IP
LAN/MAC
LAN/MAC
Local Area Network
26
Layered Protocol ArchitectureService view
TELNET
TELNET
Interfaces
Host 1
TCP
TCP
Host 2
Protocols
IP
IP
LAN/MAC
LAN/MAC
Local Area Network
27
Layered Protocol Architecture Implementation

• Layered protocols, from the service
  point-of-view, are useful for building more
  complex systems out of simpler building blocks
• but does not imply that implementations should
  be strictly layered.

28
How do we architect a network?

• Layered model
• Lots of different problems to solve complex
• Solved it once --- why solve it again?
• Three distinct aspects
• Layers of encapsulation
• Layers of services
• Layers of software
• Cultural wars
• Computer Systems versus telecommunications
• Least Common Denominator, Best characterization
  for optimal efficiency
• packets vs. circuits, best-effort vs.
  reservations,

29
Functionality placement

• Which functions belong at which layers?
• The end-to-end argument
• Application layer framing (ALF)

30
End to end argument
31
Key questions

• How to decompose the complex system functionality
  into protocol layers?
• What functions to be placed at which levels?
• Can a function be placed at multiple levels ?

32
Common View of the Telco Network
Brick
33
Common View of the IP Network
34
End-to-End Argument

• functions placed at the lower levels may be
  redundant or of little value when compared to the
  cost of providing them at the lower level
• sometimes an incomplete version of the function
  provided by the communication system (lower
  levels) may be useful as a performance
  enhancement
• This leads to a philosophy diametrically opposite
  to the telephone world which sports dumb
  end-systems (the telephone) and intelligent
  networks.

35
E2E Argument Interpretations

• One interpretation (limited possibly )
• A function can only be completely and correctly
  implemented with the knowledge and help of the
  applications standing at the communication
  endpoints
• Another (more precise)
• a system (or subsystem level) should consider
  only functions that can be completely and
  correctly implemented within it.
• Alternative interpretation (also correct )
• Think twice before implementing a functionality
  that you believe that is useful to an application
  at a lower layer
• If the application can implement a functionality
  correctly, implement it a lower layer only as a
  performance enhancement

36
Example Reliable File Transfer
Host A
Host B
Appl.
Appl.
OS
OS

• Solution 1 make each step reliable, and then
  concatenate them
• Solution 2 end-to-end check and retry

37
Discussion

• Solution 1 not complete
• What happens if the sender or/and receiver
  misbehave?
• The receiver has to do the check anyway!
• Thus, full functionality can be entirely
  implemented at application layer no need for
  reliability from lower layers
• Is there any need to implement reliability at
  lower layers?
• Yes, but only to improve performance
• Example
• assume a high error rate on communication network
• then, a reliable communication service at
  datalink layer might help

38
Trade-offs

• Application has more information about the data
  and the semantic of the service it requires
  (e.g., can check only at the end of each data
  unit)
• A lower layer has more information about
  constraints in data transmission (e.g., packet
  size, error rate)
• Note these trade-offs are a direct result of
  layering!

39
End-to-End Argument Critical Issues

• The end-to-end principle emphasizes
• function placement
• completeness and
• overall system costs.
• Philosophy if application can do it, dont do it
  at a lower layer -- application best knows what
  it needs
• add functionality in lower layers iff (1) used by
  and improves performances of many applications,
  (2) does not hurt other applications
• If implementation of function in higher levels is
  not possible due to technological/economic
  reasons (eg telephone network in early 1900s),
  then it may be placed at lower levels
• allows cost-performance tradeoff

40
Performance Impact

• Consider reliability. Let p be the probability of
  losing a packet on a link
• A n-hop path will result in (1-p)n prob of
  successful delivery and prob of loss is 1-(1-p)n
• Assume a path with n15
• Let p1e-5. Then prob(loss) 1.5e-5
• Let p0.01. Prob(loss) 0.14

41
Internet End-to-End Argument

• At network layer provides one simple service
  best effort datagram (packet) delivery
• Only one higher level service implemented at
  transport layer reliable data delivery (TCP)
• performance enhancement used by a large variety
  of applications (Telnet, FTP, HTTP) which could
  provide their own error control
• does not impact other applications (can use UDP)
• Everything else implemented at application level

42
Internet End-to-End Argument

• Discussion congestion control, flow control why
  at transport, rather than link or application
  layers?
• claim common functions should migrate down the
  stack
• Everyone shares same implementation no need to
  redo it (reduces bugs, less work, etc)
• Knowing everyone is doing the same thing, can
  help
• congestion control too important to leave up to
  application/user true but hard to police
• Tcp is outside the network compliance is
  optional
• We do this for fairness (but realize that people
  could cheat)
• Why flow control in tcp, not (just) in app
• shared tcp buffers at receiver mean want to
  control flow at tcp level (otherwise unfairness)
• Shared resources is an important reason to push
  controlling functionality to point at which
  resources are shared
• Corollary do active queue management (e.g., RED)
  in network

43
Key Advantages

• The IP service can be implemented on top of a
  large variety of network technologies
• Does not require routers to maintain any fined
  grained state about traffic. Thus, network
  architecture is
• Robust
• Scalable

44
End-to-End Argument Discussion

• end-end argument emphasizes correctness
  completeness, not
• complexity is complexity at edges result in a
  simpler architecture?
• evolvability, ease of introduction of new
  functionality ability to evolve because
  easier/cheaper to add new edge applications than
  change routers?
• Technology penetration simple network layer
  makes it easier for IP to spread everywhere

45
Summary End-to-End Arguments

• If the application can do it, dont do it at a
  lower layer -- anyway the application knows the
  best what it needs
• add functionality in lower layers iff it is (1)
  used and improves performances of a large number
  of applications, and (2) does not hurt other
  applications
• Success story Internet

46
Application layer framing
47
Application Layer Framing (ALF)

• Several processing bottlenecks may lie at the
  presentation layer which does not really exist
  in the TCP/IP stack
• These functions are absorbed partially in the
  transport layer and partly in the application
  layer.
• Principle the application-layer should have
  control of the syntax and semantics of the
  presentation conversions
• Transport should provide only common functions
• Generalization of ALF look for elegant ways to
  allow application visibility/participation in
  lower-level activities
• Eg QoS carry application intelligence to the
  point of QoS enforcement

48
ALF

• A concept challenging traditional layering
• Application needs may not be easily communicated
  across layers
• Idea Allow application to decide the frame size
  most convenient to it
• Application breaks up data into suitable
  aggregates
• The application data units (ADUs) may be
  processed by the application in any order
• Lower layers preserve ADU boundaries
• Application takes active role in the
  encapsulation of its data
• Can optimize for loss recovery via intelligent
  framing and fragmentation

49
Architecture vs Implementation ALF Principle

• Architecture decomposition into functional
  modules, semantics of modules and syntax used
• There should be no a priori requirement that the
  engineering design of a given system correspond
  to the architectural decomposition
• Eg layering may not be most effective modularity
  for implementation
• Summary
• Flexible decomposition
• Defer engineering decisions to implementor.
• Avoid gratuitous implementation constraints
• Maximize engineering options for
  customization/optimization

50
ILP Integrated Layer Processing

• Modular functionality that is specified in
  layered form should not be implemented as such
• Architecture must minimize gratuitous precedence
  or ordering constraints
• Integrated processing loop
• Loop over bytes in packet
• Touch each byte at most once
• Avoid multiple copies within memory
• Massive integrated loop w/ all steps in-line

51
System Design Rules of Thumb

• Design a system to tradeoff cheaper resources
  against expensive ones (for a gain)
• When resources are cheap and abundant, waste
  them. Design focuses on cutting out any expensive
  resource that comes in the way! (eg parallelism)
• Apply principles like E2E and ALF to decide on
  right placement of functionalities in different
  system levels
• Interfaces must outlive several generations of
  change in the components being interfaced.
• Three factors drive interface design
• functionality demanded,
• available technology,
• performance tradeoff.

52
System Design Rules of Thumb

• Functionality requirements can be understood by
  taking different views of the system (eg
  designer, implementor, operator).
• Reduced functionality can result in cheaper,
  scalable, quickly engineered system
• Placement of functionality is critical in system
  design
• No paradigm is going to work or functionality can
  be met if the available technology to implement
  it does not exist.
• Performance is either relative or absolute and is
  usually modeled at the high level as a function
  from system parameters (input) to system metrics
  (output).
• Metrics must be design to reflect design
  tradeoffs.
• Only sensitive parameters matter.
• Optimize the common case
• Solve 90 of the problem that matters, throw away
  the remaining 10 of the problem requirements!

53
Internet design philosophy
54
Internet Design Philosophy (Clark88)
In order of importance

• Connect existing networks
• initially ARPANET and ARPA packet radio network
• Survivability
• ensure communication service even with network
  and router failures
• Support multiple types of services
• Must accommodate a variety of networks
• Allow distributed management
• Allow host attachment with a low level of effort
• Be cost effective
• Allow resource accountability

Different ordering of priorities would make a
different architecture!
55
1. Survivability

• Continue to operate even in the presence of
  network failures (e.g., link and router failures)
• as long as network is not partitioned, two
  endpoints should be able to communicate
• any other failure (excepting network partition)
  should be transparent to endpoints
• Decision maintain e-e transport state only at
  end-points
• eliminate the problem of handling state
  inconsistency and performing state restoration
  when router fails
• Internet stateless network architecture
• No notion of a session/call at network layer
• Grade A- because convergence times are
  relatively slow
• BGP takes minutes to coverge
• IS-IS OSPF take 10 seconds

56
2. Types of Services

• Need to support multiple types of services
• All combinations of delay, bandwidth, loss
• add UDP to TCP to better support other apps
• e.g., real-time applications
• arguably main reason for separating TCP, IP
• datagram abstraction lower common denominator on
  which other services can be built
• service differentiation was considered (remember
  ToS?), but this has never happened on the large
  scale (Why?)
• A- proven to allows many applications to be
  invented and flourish

57
3. Variety of Networks

• Very successful (why?)
• because the minimalist service it requires from
  underlying network only to deliver a packet with
  a reasonable probability of success
• does not require
• reliability
• in-order delivery
• The mantra IP over everything
• Then ARPANET, X.25, DARPA satellite network..
• Now ATM, SONET, WDM
• A cant name a link layer technology that IP
  doesnt run over (carrier pigeon RFC)

58
Other Goals

• Allow distributed management
• Administrative autonomy IP interconnects
  networks
• each network can be managed by a different
  organization
• different organizations need to interact only at
  the boundaries
• but this model complicates routing
• A for implementation, B for concept
  (disagreement)
• Cost effective
• sources of inefficiency
• header overhead
• retransmissions
• but optimal performance never been top
  priority
• A

59
Other Goals (Cont)

• Low cost of attaching a new host
• not a strong point ? higher than other
  architecture because the intelligence is in hosts
  (e.g., telephone vs. computer)
• bad implementations or malicious users can
  produce considerably harm (remember
  fate-sharing?)
• C but things are improving with dhcp,
  autocofigurations. Looks like a higher grade in
  future
• Accountability
• Internet gets an F

60
Internet protocol stack

• application supporting network applications
• ftp, smtp, http
• transport host-host data transfer
• tcp, udp
• network routing of datagrams from source to
  destination
• ip, routing protocols
• link data transfer between neighboring network
  elements
• ppp, ethernet
• physical bits on the wire

61
Reference Models for Layering
TCP/IP Model
OSI Ref Model
TCP/IP Protocols
Application
FTP
Telnet
HTTP
Transport
TCP
UDP
Internetwork
IP
Host to Network
Ethernet
PacketRadio
Point-to-Point
62
Internet (IP) Architecture

• Hourglass
• Not strict layering

63
Internet applications

• Variations on three themes
• distinguish protocol vs. application behavior
• Messaging
• datagram model ? no direct confirmation of final
  receipt
• email (optional confirmation now) and IM
• emphasis on interoperation (SMS, pagers, )
• delays measured in minutes
• Retrieval query (request/response)
• client-server
• ftp, HTTP
• RPC (Sun RPC, DCE, DCOM, Corba, XML-RPC, SOAP)
• emphasis on fast reliable transmission
• delays measured in seconds

64
Internet applications, contd

• Continuous media
• generation rate delivery rate rendering rate
• audio, video, measurements, control
• Internet telephony
• Multimedia conferencing
• related streaming media ?slightly longer
  timescales for rate matching
• video-on-demand
• emphasis is on timely and low-loss delivery ?
  real-time
• delays measured in milliseconds

65
Internet protocols

• Protocols support these applications
• data delivery
• HTTP, ftp data part, SMTP, IMAP, POP, NFS, SMB,
  RTP
• identifier mapping (id ? id, id ? data)
• ARP, DNS, LDAP
• configuration ( specialized version of
  identifier ? data)
• DHCP, ACAP, SLP, NETCONF, SNMP
• control and setup
• RTSP, SIP, ftp control, RSVP, SNMP, BGP and
  routing protocols
• May be integrated into one protocol or general
  service function (middleware?)

66
History of networking

• History of networking non-network applications
  migrate
• postal intracompany mail, fax ? email, IM
• broadcast TV, radio
• interactive voice/video communication ? VoIP
• information access ? web, P2P
• disk access ? iSCSI, Fiberchannel-over-IP

67
Network evolution

• Only three modes, now thoroughly explored
• packet/cell-based
• message-based (application data units)
• session-based (circuits)
• Replace specialized networks
• left to do embedded systems
• need cost(CPU network) lt 10
• cars
• industrial (manufacturing) control
• commercial buildings (lighting, HVAC, security
  now LONworks)
• remote controls, light switches
• keys replaced by biometrics

68
New applications

• New bandwidth-intensive applications
• Reality-based networking
• (security) cameras
• Distributed games often require only
  low-bandwidth control information
• current game traffic VoIP
• Computation vs. storage vs. communications
• communications cost has decreased less rapidly
  than storage costs

69
Transition of networking

• Maturity ? cost dominates
• can get any number of bits anywhere, but at
  considerable cost and complexity
• casually usable bit density still very low
• Specialized ? commodity
• installed and run by 'amateurs'
• need low complexity, high reliability

70
Security challenges

• DOS, security attacks ? permissions-based
  communications
• only allow modest rates without asking
• effectively, back to circuit-switched
• Higher-level security services ? more
  application-layer access via gateways, proxies,
• User identity
• problem is not availability, but rather
  over-abundance

71
Scaling

• Scaling is only backbone problem
• Depends on network evolution
• continuing addition of AS to flat space ? deep
  trouble
• additional hierarchy

72
Quality of Service (QoS)

• QoS is meaningless to users
• care about service availability ? reliability
• as more and more value depends on network
  services, can't afford random downtimes

73
Textbook Internet vs. real Internet
74
Textbook Internet vs. real Internet
75
Internet architecture documents (readings-hw)

• http//www.ietf.org/rfc/rfcXXXX.txt
• RFC 1287
• RFC 2101
• RFC 2775
• RFC 3234

76
The Internet Protocol Hourglass(Deering)
77
Why the hourglass architecture?

• Why an internet layer?
• make a bigger network
• global addressing
• virtualize network to isolate end-to-endprotocols
  from network details/changes
• Why a single internet protocol?
• maximize interoperability
• minimize number of service interfaces
• Why a narrow internet protocol?
• assumes least common network functionalityto
  maximize number of usable networks

Deering, 1998
78
Putting on Weight
email WWW phone... SMTP HTTP RTP... TCP
UDP IP mcast QoS ... ethernet PPP CSMA
async sonet... copper fiber radio...

• requires more functionality from underlying
  networks

79
Mid-Life Crisis
email WWW phone... SMTP HTTP RTP... TCP
UDP IP4 IP6 ethernet PPP CSMA
async sonet... copper fiber radio...

• doubles number of service interfaces
• requires changes above below
• major interoper-ability issues

80
Layer splitting

• Traditionally, L2 (link), L3 (network IP), L4
  (transport TCP), L7 (applications)
• Layer 2 Ethernet ? PPPoE (DSL)
• Layer 2.5 MPLS, L2TP
• Layer 3 tunneling (e.g., GPRS)
• Layer 4 UDP RTP
• Layer 7 HTTP real application

81
Layer violations

• Layers offer abstraction ? avoid Internet closed
  for renovation
• Cost of information hiding
• Cost of duplication of information when nothing
  changes
• fundamental design choice of Internet
  difference between circuit and datagram-oriented
  networks
• Assumption packets are large and getting larger
• wrong for games and audio
• Cost prohibitive on wireless networks
• will see 10 bytes of payloads, 40 bytes of
  packet header
• header compression ? compress into state index on
  one link

82
Internet acquires presentation layer

• All learn about OSI 7-layer model
• OSI ASN.1 as common rendering of application
  data structures
• used in LDAP and SNMP (and H.323)
• Internet never really had presentation layer
• approximations common encoding (TLV, RFC 822
  styles)
• Now, XML as the design choice by default

83
Internet acquires session layer

• Originally, meant for data sessions
• Example (not explicit) ftp control connection
• Now, separate data delivery from session setup
• address and application configuration
• deal with mobility
• will see as RTSP, SIP and H.323

84

• But that was yesterday
• . what about tomorrow?

85
What About the Future?

• Datagram not the best abstraction for
• resource management,accountability, QoS
• new abstraction flow (see IPv6)
• but no one knows what a flow is
• routers require to maintain per-flow state
• state management recovering lost state is hard
• here we see the first proposal of soft state!
• soft-state end-hosts responsible to maintain the
  state

86
Rethinking Internet Design

• Whats changed?
• operation in untrustworthy world
• endpoints can be malicious
• If endpoint not trustworthy, but want trustworthy
  network -gt more mechanism in network core
• more demanding applications
• end-end best effort service not enough
• new service models in network (Intserv,
  diffserv)?
• new application-level service architecture built
  on top of network core (e.g., CDN, p2p)?

87
Rethinking Internet Design

• Whats changed?
• ISP service differentiation
• ISP doing more (than other ISPs) in core is
  competitive advantage
• Rise of third party involvement
• interposed between endpoints (even against will)
• e.g., Chinese govt, US recording industry
• less sophisticated users

All five changes motivate shift away from end-end!
88
Technical response to changes

• Trust emerging distinction between what is in
  network (us, trusted) and what is not (them,
  untrusted).
• ingress filtering
• emergence of Internet UNI (user network
  interface, as in ATM)?
• Modify endpoints
• Harden endpoints against attack
• Endpoints do content filtering Net-nanny
• CDN, ASPs rise of structured, distributed
  applications in response to inability to send
  content (e.g., multimedia, high bw) at high
  quality

89
Technical response to changes

• Add functions to the network core
• filtering firewalls
• application-level firewalls
• NAT boxes
• active networking
• All operate within network, making use of
  application-level information
• which addresses can do what at application level?
• If addresses have meaning to applications, NAT
  must understand that meaning

90
Summary Internet Architecture

• packet-switched datagram network
• IP is the glue (network layer overlay)
• IP hourglass architecture
• all hosts and routers run IP
• stateless architecture
• no per flow state inside network

TCP
UDP
IP
Satellite
ATM
Ethernet
IP hourglass
91
Summary Minimalist Approach

• Dumb network
• IP provide minimal functionalities to support
  connectivity
• addressing, forwarding, routing
• Smart end system
• transport layer or application performs more
  sophisticated functionalities
• flow control, error control, congestion control
• Advantages
• accommodate heterogeneous technologies (Ethernet,
  modem, satellite, wireless)
• support diverse applications (telnet, ftp, Web, X
  windows)
• decentralized network administration

92

• Two ways of constructing a software design
• make it so simple that there are obviously no
  deficiencies, and
• make it so complicated that there are no obvious
  deficiencies
• --- CAR Hoare

93
Readings

• Reading Saltzer, Reed, Clark "End-to-End
  arguments in System Design"
• Reading Clark "The Design Philosophy of the
  DARPA Internet Protocols"

94
Standardization

• Henning Schulzrinne
• Dept. of Computer Science
• Columbia University
• Fall 2003

95
Standards

• Mandatory vs. voluntary
• Allowed to use vs. likely to sell
• Example health safety standards ?UL listing
  for electrical appliances, fire codes
• Telecommunications and networking always focus of
  standardization
• 1865 International Telegraph Union (ITU)
• 1956 International Telephone and Telegraph
  Consultative Committee (CCITT)
• Five major organizations
• ITU for lower layers, multimedia collaboration
• IEEE for LAN standards (802.x)
• IETF for network, transport some applications
• W3C for web-related technology (XML, SOAP)
• ISO for media content (MPEG)

96
Who makes the rules? - ITU

• ITU ITU-T (telecom standardization) ITU-R
  (radio) development
• http//www.itu.int
• 14 study groups
• produce Recommendations
• E overall network operation, telephone service
  (E.164)
• G transmission system and media, digital systems
  and networks (G.711)
• H audiovisual and multimedia systems (H.323)
• I integrated services digital network (I.210)
  includes ATM
• V data communications over the telephone network
  (V.24)
• X Data networks and open system communications
• Y Global information infrastructure and internet
  protocol aspects

97
ITU

• Initially, national delegations
• Members state, sector, associate
• Membership fees
• Now, mostly industry groups doing work
• Initially, mostly (international) telephone
  services
• Now, transition from circuit-switched to
  packet-switched universe lower network layers
  (optical)
• Documents cost SFr, but can get three freebies
  for each email address

98
IETF

• IETF (Internet Engineering Task Force)
• see RFC 3233 (Defining the IETF)
• Formed 1986, but earlier predecessor
  organizations (1979-)
• RFCs date back to 1969
• Initially, largely research organizations and
  universities, now mostly RD labs of equipment
  vendors and ISPs
• International, but 2/3 United States
• meetings every four months
• about 300 companies participating in meetings
• but Cisco, Ericsson, Lucent, Nokia, etc. send
  large delegations

99
IETF

• Supposed to be engineering, i.e., translation of
  well-understood technology ? standards
• make choices, ensure interoperability
• reality often not so well defined
• Most development work gets done in working groups
  (WGs)
• specific task, then dissolved (but may last 10
  years)
• typically, small clusters of authors, with large
  peanut gallery
• open mailing list discussion for specific
  problems
• interim meetings (1-2 days) and IETF meetings
  (few hours)
• published as Internet Drafts (I-Ds)
• anybody can publish draft-somebody-my-new-protocol
  
• also official working group documents
  (draft-ietf-wg-)
• versioned (e.g., draft-ietf-avt-rtp-10.txt)
• automatically disappear (expire) after 6 months

100
IETF process

• WG develops ? WG last call ? IETF last call ?
  approval (or not) by IESG ? publication as RFC
• IESG (Internet Engineering Steering Group)
  consists of area directors they vote on
  proposals
• areas applications, general, Internet,
  operations and management, routing, security,
  sub-IP, transport
• Also, Internet Architecture Board (IAB)
• provides architectural guidance
• approves new working groups
• process appeals

101
RFCs

• Originally, Request for Comment
• now, mostly standards documents that are well
  settled
• published RFCs never change
• always ASCII (plain text), sometimes PostScript
• anybody can submit RFC, but may be delayed by
  review (end run avoidance)
• see April 1 RFCs (RFC 1149, 3251, 3252)
• accessible at http//www.ietf.org/rfc/ and
  http//www.rfc-editor.org/

102
IETF process issues

• Can take several years to publish a standard
• see draft-ietf-problem-issue-statement
• Relies on authors and editors to keep moving
• often, busy people with day jobs ? spurts three
  times a year
• Lots of opportunities for small groups to delay
  things
• Original idea of RFC standards-track progression
• Proposed Standard (PS) kind of works
• Draft Standard (DS) solid, interoperability
  tested (2 interoperable implementations for each
  feature), but not necessarily widely used
• Standard (S) well tested, widely deployed

103
IETF process issues

• Reality very few protocols progress beyond PS
• and some widely-used protocols are only I-Ds
• In addition Informational, Best Current Practice
  (BCP), Experimental, Historic
• Early IETF simple protocols, stand-alone
• TCP, HTTP, DNS, BGP,
• Now systems of protocols, with security,
  management, configuration and scaling
• lots of dependencies ? wait for others to do
  their job

104
Other Internet standards organizations

• ISOC (Internet Society)
• legal umbrella for IETF, development work
• IANA (Internet Assigned Numbers Authority)
• assigns protocol constants
• NANOG (North American Network Operators Group)
  (http//www.nanog.org)
• operational issues
• holds nice workshop with measurement and real
  world papers
• RIPE, ARIN, APNIC
• regional IP address registries ? dole out chunks
  of address space to ISPs
• routing table management

105
ICANN

• Internet Corporation for Assigned Names and
  Numbers
• manages IP address space (at top level)
• DNS top-level domains (TLD)
• ccTLD country codes (.us, .uk, )
• gTLDs (.com, .edu, .gov, .int, .mil, .net, and
  .org)
• uTLD (unsponsored) .biz, .info, .name, and .pro
• sTLD (sponsored) .aero, .coop, and .museum
• actual domains handled by registrars

106
Introduction to IETF (readings-hw)

• http//www.ietf.org/rfc/rfcXXXX.txt
• RFC 2026
• RFC 2028
• RFC 3160
• RFC 3869