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

CS 262a2 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, 2001CS 262a3 Traditional Network Architecture Protocol Architecture Layering

October 31, 2001CS 262a4 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, 2001CS 262a5 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, 2001CS 262a6 Layering Use abstractions to hide complexity Abstraction naturally leads to layering Application Programs Process-to-Process Channels Host-to-Host Connectivity Hardware

October 31, 2001CS 262a7 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, 2001CS 262a8 Protocol Interfaces Term “protocol” is overloaded –Specification of peer-to-peer interface –Module that implements this interface P2 P1 Service interface Peer-to-peer interfaces

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

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

October 31, 2001CS 262a11 Example: Open Systems Interconnect (OSI) Architecture International Standards Organization (ISO) “X dot” series: –X OSI internetworking layer –X mail services –X user directory services (LDAP)

October 31, 2001CS 262a12 Reference Model

October 31, 2001CS 262a13 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, 2001CS 262a14 Terminology (see Zim80): (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, 2001CS 262a15 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, 2001CS 262a16 Problems Tannenbaum: –Bad technology –Bad timing –Bad implementation –Bad politics

October 31, 2001CS 262a17 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, 2001CS 262a18 Bad technology (cont’d) Why seven layers? –Many fundamental issues can be addressed at multiple layers Reliability Flow control Security Addressing/naming

October 31, 2001CS 262a19 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, 2001CS 262a20 Bad implementations Complexity  huge & slow implementations Competition (BSD TCP/IP) was good, free, and easy to deploy

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

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

October 31, 2001CS 262a23 Internet Architecture Internet Engineering Task Force (IETF) FTP TCP IP NET2NETn UDP HTTPNVTFTP NET1

October 31, 2001CS 262a24 Alternate View TCPUDP IP Network Application

October 31, 2001CS 262a25 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, 2001CS 262a26 Layered Implementation Layering clean and manageable  protocol stack app user kernel task context app copy socket tcp ip ether sw intr hw intr tcp recv add to IP input queue packet arrives boundary crossings

October 31, 2001CS 262a27 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, 2001CS 262a28 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, 2001CS 262a29 ALF Basic idea: –Express application's semantics in the design of its network protocol. “One size fits all” often inadequate Application packets mux Application packets demux

October 31, 2001CS 262a30 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, 2001CS 262a31 ALF (cont’d) Key architectural principle is: FLEXIBLE DECOMPOSITION Defer engineering decisions to implementor Avoid inessential constraints

October 31, 2001CS 262a32 More ALF Examples: –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, , web/http) Yes, however, even these can be improved in certain environments: –Slogin (add encryption) –multicast mail exploder (avoid duplication)

October 31, 2001CS 262a33 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, 2001CS 262a34 Video 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) Hdr B0 B1 … BN Frame N-1 Frame NFrame N+1 “JPEG” Video Sequence Hdr BLBL+1 BMBM+1 BNHdr BLBL+1 BMBM+1 BNHdr BLBL+1 BMBM+1 BN Naïve Framing H* BLH*BL+1BMH*BM+1BNH* BLH*BL+1BMH*BM+1BNH* BLH*BL+1BMH*BM+1BN Intelligent Framing

October 31, 2001CS 262a35 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, 2001CS 262a36 More Protocol Functions Control transfer –Flow / congestion control –Detecting network transmission problems: loss, duplication, re-ordering –Acknowledgement –Multiplexing –Timestamping –Framing

October 31, 2001CS 262a37 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, 2001CS 262a38 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, 2001CS 262a39 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, 2001CS 262a40 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, 2001CS 262a41 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, 2001CS 262a42 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, 2001CS 262a43 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)