Fall 07 1

1
"End-to-End Arguments in System Design",

• J. Saltzer and D. Reed and D. Clark
• ACM TOCS, 1984

2
Background layered models

• Each layer element
• Talk to its peer element
• Carries traffic for its parent
• Deliver traffic through its child

3
OSI Network Layering Model
4
Layering vs End-to-End

• The argument for layering
• modularity
• standardized interfaces
• software engineering (more interoperability)
• avoid re-inventing the wheel
• software engineering (fewer errors)
• The arguments for end-to-end (nutshell version)
• unneeded functionality in lower level
• functionality might be duplicated
• app might be only place all information is
  available

5

• The function in question can completely and
  correctly be implemented only with the knowledge
  and help of the application standing at the end
  points of the communication system.
• Therefore, providing that questioned function as
  a feature of the communication system itself is
  not possible. (Sometimes an incomplete version of
  the function provided by the communication system
  may be useful as a performance enhancement.)

6
Example File Transfer

• Potential errors copying a file from host A to
  host B
• read errors on A
• file system, OS, or app copying/buffering errors
• transient hardware (memory or CPU) bit errors
• comm system errors
• crashes

7
File Transfer Cont.

• Possible approaches to fixing this
• make each step error-proof
• each of the modules app, comm, FS, etc. must be
  bulletproof
• end-to-end
• checksum for entire file
• addresses all error sources
• very fast if few errors
• third approach reliable communication subsystem
• use per-packet checksums, sequence numbers,
  retries, etc.
• comm system errors become rare!
• other errors still present ? app must still use a
  checksum

8
Another Quick Example (End-To-End Important)

• Installing OS on new machine over the network
• App programmers knew they had reliable comm, and
  didnt do end-to-end
• One gateway computer had a transient error,
  flipped two bytes every million or so
• The install didnt go so well

9
Reality

• reliability should not be totally end-to-end
• transfer of large files w/ only end-to-end
  reliability is slow
• probability that all pkts correct increases
  exponentially w/ file size
• instead, lower levels need to be good, but not
  perfect
• engineering tradeoff
• performance argument is tricky
• low-level can be slower
• low-level might not have all the right
  information
• not all apps might need all such functionality
• w/ file-transfer again, need early checks, but
  performance arguments do not say where

10
Other Examples

• Why not secure communication subsystem?
• comm system must be trusted
• data will be in clear in OS between comm and app
• authenticity must still be checked by app
• this can be combined w/ decryption if app does
  both
• Duplicate suppression
• prevent a message from being duplicated by
  network, delivered twice
• but app needs to do this anyway, as
• app might duplicate msgs in failure/retry
  situations
• user might restart

11
Other Issues Identifying the Ends

• telecom system that carries voice traffic.
• the ends are people
• slightly damaged packets are ok
• people introduce their own errors (loud kids)
  and know how to retry
• delay is not
• one end is voice capture for later listening
• damaged packets bad
• no people retries
• delay is fine

12
Summary and Critique

• Conclusions
• KISS dont help app programmers more than
  necessary
• Occams razor make as few assumptions as
  possible
• What I liked
• Flies in the face of (then) current authority
• Emperor has no clothes
• What I didnt like
• simplistic
• but this is ok, its basically a position paper

13
Active Networking and the End-to-End Argument

• Samrat Bhattacharjee and Kenneth L. Calvert and
  Ellen W. Zegura
• ICNP 1997

14
Active Networking and the End-to-End Argument

• app-specific functionality in routers

Host
Host
Router
ftp
voice
15
Essential Argument

• First, AN would seem to be in conflict w/ E2E
• BUT!
• Paraphrasing
• E2E is essentially an argument about WHICH module
  implements functionality (app, comm, OS, etc.),
  not WHERE

16
How Do We Decide Where to Put Functionality?

• Information availability
• network
• when and where congestion occurs
• global patterns (more thanone user)
• where losses occur in multicast trees
• app
• dependencies between packets
• some are useless if others not received
• variations on importance of pkts
• whether cached data is useable
• Cost model
• compare cost w/ just E2Ed vs w/ AN support
• this assumes cost of any AN support is zero for
  those apps that do not use it

17
Model

• Exclusively end-system (design X)
• TX
• Combined end-system and network
• TC overall expected performance
• pn Prnetwork support does the job
• TE performance if network does the work
• TN performance if end-system does the work
• TC (1-pn) TE pnTN

18
Extended Example Reliable Multicast

• Two approaches, both use multicast trees for
  sending
• end-to-end
• recipient pushes retries up until no lost, then
  vectored to nearby recipient
• network
• retry travels upstream until finding a node not
  in the loss tree
• Caveats
• the multicast tree might be slower than direct
  for pkts not lost (more buffering)
• this analysis only looks at retry cost (but MBONE
  traffic rarely makes it to all sites correctly
  (20)

19
Setup

• Transits and stubs
• all host nodes in stub domain
• a single transit domain connects all stub domains
• one receiver per stub
• Variables
• both
• tR hops between affected receiver and exit from
  receiver stub
• tL hops from loss node to entrance of
  receivers stub
• design X
• tY hops from loss node to entrance to nearby
  receivers stub
• tR hops from nearby receivers entrance to
  receiver
• tE hops from entrances of two receivers stubs
  to transit
• design C
• tL hops between sender stub entrance and loss
  node
• tS hops between send and entrance to sender
  stub
• pn probability that the node upstream of the
  loss node has buffered a copy

20
So

• Latency for retry w/ e2e case
• TX tR tL tY 2tR tE tR
• For network case
• if node above loss node has a copy
• TN 2(tR tL 1)
• otherwise, we go to sender
• TE 2(tR tL tL tS)
• so
• TC 2pn(tR tL 1) 2(1-pn)(tR tL tL
  tS)
• if we assume tR tR tS, and tL tL, then
  network approach better if

21
Bottom line on this example?

• Network smarts good

22
Summary and Critique

• What I liked
• AN is an extension of end-to-end argument
• in fact, should restate e2e to reflect WHERE
  being the important question, rather than how the
  functionality is decomposed
• provided an example
• What I didnt like
• example not really clear. Is IP multicast assumed
  or not? How does the e2e version find loss node,
  and nearby recipient?
• No clear bottom line, should have related back to
  some real installation.

23
Else

• Contention is that the choice is performance,
  hence the paper.
• But also
• Security
• Buy-in from telcos
• Security