Protocol Layering Boon or Bust Anthony D Joseph

Protocol Layering: Boon or Bust? Anthony D. Joseph CS 262 a October 31, 2001 CS 262 a

Outline • • Network Architecture and Layering OSI Seven-layer Model Application Level Framing Integrated Layer Processing • Portions of this lecture material derived from L. Peterson's on-line lecture notes. ALF figure from V. Jacobson. October 31, 2001 CS 262 a 2

Traditional Network Architecture • Protocol Architecture • Layering October 31, 2001 CS 262 a 3

Protocol Architecture • protocol = agreed upon conventions (for communication) • architecture = method or style of building • So “protocol architecture” is the common “design style” for set of related network protocols --- “blueprints”. October 31, 2001 CS 262 a 4

Protocol Suite • Often called a protocol suite – (e. g. , TCP/IP suite) • Examples: – ISO Open Systems Interconnections (OSI) Seven-layer Reference Model – Internet architecture – IBM’s System Network Architecture October 31, 2001 CS 262 a 5

Layering • Use abstractions to hide complexity • Abstraction naturally leads to layering Application Programs Process-to-Process Channels Host-to-Host Connectivity Hardware October 31, 2001 CS 262 a 6

Protocols • 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 October 31, 2001 CS 262 a 7

Protocol Interfaces P 2 P 1 Service interface Peer-to-peer interfaces • Term “protocol” is overloaded – Specification of peer-to-peer interface – Module that implements this interface October 31, 2001 CS 262 a 8

Key concepts • Multiplexing / Demultiplexing (demux key) • Encapsulation (header/body) encapsulation Ether UDP eh. type IP atalk IP ip. proto TCP October 31, 2001 demultiplexing TCP Ether CS 262 a 9

Standard Architectures • Open Systems Interconnect (OSI) Architecture – International Telecommunications Union (ITU); formerly CCITT • Internet Architecture – Internet Engineering Task Force (IETF) October 31, 2001 CS 262 a 10

Example: Open Systems Interconnect (OSI) Architecture • International Standards Organization (ISO) • “X dot” series: – X. 25 -- OSI internetworking layer – X. 400 -- mail services – X. 500 -- user directory services (LDAP) October 31, 2001 CS 262 a 11

Reference Model October 31, 2001 CS 262 a 12

Reference Model • Vague set of design goals leads to layered “Reference Model” – “new layer created where different level of abstraction needed” – “each layer should perform a well defined function‘” – etc. October 31, 2001 CS 262 a 13

Terminology (see Zim 80): • (N) layer, (N+1) layer, (N-1) layer • (N) entity is anything in (N) layer • Modularity – Independently develop layers while maintaining layer interface – Each layer adds value • (N) entities collectively provide (N) service to (N+1) entities • (N+1) entities make use of (N) services • (N) service access point, (N) SAP, – Interface exported to (N+1) layer • (N) layer offers connections between (N) SAP's • Lots of complexity. . . October 31, 2001 CS 262 a 14

Discussion questions • Where do X. n protocols fall in stack? • Where would you put … – security? – reliability? • Though clean and modular, hasn't had widespread acceptance. Why not? October 31, 2001 CS 262 a 15

Problems • Tannenbaum: – – Bad technology Bad timing Bad implementation Bad politics October 31, 2001 CS 262 a 16

Bad technology • Model and protocol flawed • Standardized before implemented – Design by committee w/o implementation vs. design by implementors/researchers/engineers – Boundaries somewhat arbitrary – Top three layers never quite resolved (application, presentation, session) October 31, 2001 CS 262 a 17

Bad technology (cont’d) • Why seven layers? – Many fundamental issues can be addressed at multiple layers • • Reliability Flow control Security Addressing/naming October 31, 2001 CS 262 a 18

Bad timing • D. Clark's “apocalypse of the two elephants” – Technology activity vs. time wrt to standardization • TCP/IP already entrenched by mid/late eighties October 31, 2001 CS 262 a 19

Bad implementations • Complexity huge & slow implementations • Competition (BSD TCP/IP) was good, free, and easy to deploy October 31, 2001 CS 262 a 20

Bad politics • Pushed by European Community and U. S. government • Negative image of government dictating standards – Remember “Clipper Chip” October 31, 2001 CS 262 a 21

OSI Summary • Layering is good (sometimes) for describing protocols; • but can lead to inefficient implementations October 31, 2001 CS 262 a 22

Internet Architecture • Internet Engineering Task Force (IETF) FTP HTTP NV TFTP UDP TCP IP NET 1 October 31, 2001 NET 2 CS 262 a NETn 23

Alternate View Application TCP UDP IP Network October 31, 2001 CS 262 a 24

Features • Layering not strict - only where appropriate – Can define new abstractions on top of any existing protocol – IP/UDP provides simple “send a packet” svc • Ex: RPC, DNS, IP phone, etc. • Hourglass shape – IP centerpiece, common denominator • Design and implementation go hand-in-hand – IETF requires two independent, interoperable implementations before standardization – The “dogma”: We reject kings, presidents, and voting. We believe in rough consensus and working code. --- D. Clark October 31, 2001 CS 262 a 25

Layered Implementation • Layering clean and manageable protocol stack boundary crossings user kernel app socket task context app copy tcp recv add to IP input queue packet arrives October 31, 2001 tcp sw intr ip ether CS 262 a hw intr 26

Implementation • Bottlenecks: – – Boundary crossings Context switches (in typical implementations) Loss of information due to abstraction (lots of research addresses bottlenecks) • So strict layering is problematic in two dimensions: – often too constraining as an architecture – implementation overhead October 31, 2001 CS 262 a 27

ALF and ILP • Clark and Tennenhouse, 1990 – Application Level Framing (ALF) • ALF solves problems with strictly-layered architecture – Integrated Layer Processing (ILP) • ILP solves problems with layered impl’n • ALF a mainstream concept, major impact – basis for Real-time Transport Protocol • ILP still in research stage – Hard problem, e. g. , HIPPARCH project October 31, 2001 CS 262 a 28

ALF Application packets mux demux • Basic idea: – Express application's semantics in the design of its network protocol. • “One size fits all” often inadequate October 31, 2001 CS 262 a 29

ALF (cont’d) • ”In the case of layered architectures, practical experience provides strong support for alternative engineering design”. • Not obvious – Streaming A/V on web (via TCP) – XPhone system (A/V over TCP) October 31, 2001 CS 262 a 30

ALF (cont’d) • Key architectural principle is: FLEXIBLE DECOMPOSITION • Defer engineering decisions to implementor • Avoid inessential constraints October 31, 2001 CS 262 a 31

• Examples: More ALF – Real-time Transport Protocol – LBL whiteboard / reliable multicast • But isn't TCP “one size fits all”? – Hasn't this worked really well? – (e. g. , telnet, ftp, email, web/http) • Yes, however, even these can be improved in certain environments: – Slogin (add encryption) – multicast mail exploder (avoid duplication) October 31, 2001 CS 262 a 32

Application Data Units • Notion of “application data unit” (ADU) explicit in the network/application interface. • Example: – “Intelligent” framing of compressed video – Bit-oriented JPEG video stream – Frame bit-stream into ADUs/packets for … … October 31, 2001 CS 262 a 33

Frame N-1 Video Framing Hdr B 0 B 1 … BN Frame N+1 Hdr B 0 B 1 … BN “JPEG” Video Sequence Hdr BL BL+1 BM BM+1 BN Naïve Framing H* BL H*BL+1 BM H*BM+1 BN Intelligent Framing • Add header (H*) to each packet to make “idempotent”; independently “processable” • Allows receiver to: – Proceed in the presence of loss – Selectively decide which data to retransmit (if at all) October 31, 2001 CS 262 a 34

Protocol Functions • Performance issues: separation of control and “data manipulation” • Data manipulation (touching / moving) – – – Move to/from net Error detection Buffering for retransmission Encryption Moving to/from app address space Presentation formatting October 31, 2001 CS 262 a 35

More Protocol Functions • Control transfer – Flow / congestion control – Detecting network transmission problems: loss, duplication, re-ordering – Acknowledgement – Multiplexing – Timestamping – Framing October 31, 2001 CS 262 a 36

More Details • Simple measurements and argument to say: data manipulation is bottleneck • But control semantics place constraints on implementation, leads to layered implementations. October 31, 2001 CS 262 a 37

Consider TCP • What happens when data is reordered? (actually: how does data get reordered? ) – TCP stalls system to wait for retransmission lost packet stalls “presentation conversion” • Instead: let application process misordered data: – App might accept less than perfect delivery, merely continue – Sending app can provide missing data (rather than keeping buffered copy in transport layer) – App might want to retransmit new not old data to fix consequence of original loss October 31, 2001 CS 262 a 38

How can we do this? • TCP doesn't work (API wrong, reliable byte stream) • Instead: Application Data Unit (ADU) – Unit of manipulation – ADUs processed in any order – ADU boundaries replace packet boundaries (for data manipulation functions like error detection) – Lost piece of ADU lost ADU October 31, 2001 CS 262 a 39

Discussion questions • How to name ADUs? – Sequence numbers? • Why not make ADU = packet? • Why not make ADU >> packet? • Does ALF imply a user-level protocol? October 31, 2001 CS 262 a 40

Integrated Layer Processing • Layering: + Design / - Implementation • Naive implementation sequential processing at each layer • Clark/Tennenhouse argue that layering is not fundamental; rather, it's just one design option. • Alternative engineering principle: Integrated Layer Processing October 31, 2001 CS 262 a 41

ILP • Motivation: ever-widening memory / CPU bottleneck • ”Integrated processing loop” – – Loop over bytes in packet Touch each byte at most once Massive integrated loop w/ all steps in-line Trivial example: bcopy + checksum • Architecture must minimize precedence/ordering constraints, e. g. , – Some steps needs ordering (DES/CBC, decompression? ) – Many steps need per/app state (wait for demux) October 31, 2001 CS 262 a 42

Discussion Questions • How to implement ILP? – – By hand? Automatic synthesis? How? compiler? formal language? Protocol implementations typically ad hoc, and thus difficult to transform. – Formal techniques haven't panned out (yet. . . ? ) • Where are bottlenecks? where is most opportunity? – I claim at application! Then this is no longer really a networking problem; it's a really a compiler/application problem. . . (Example: encrypted/compressed video) October 31, 2001 CS 262 a 43