1 / 17

ALF-ILP

ALF-ILP. Based on Slides by Anthony D. Joseph. 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

freya
Download Presentation

ALF-ILP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ALF-ILP Based on Slides by Anthony D. Joseph

  2. 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

  3. Application Application packets packets mux demux ALF • Basic idea: • Express application's semantics in the design of its network protocol. • “One size fits all” often inadequate

  4. 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)

  5. ALF (cont’d) • Key architectural principle is: FLEXIBLE DECOMPOSITION • Defer engineering decisions to implementor • Avoid inessential constraints

  6. 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, email, web/http) • Yes, however, even these can be improved in certain environments: • Slogin (add encryption) • multicast mail exploder (avoid duplication)

  7. 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 … …

  8. Frame N-1 Frame N Frame N+1 “JPEG” Video Sequence Hdr B0 B1 … BN Hdr B0 B1 … BN Hdr B0 B1 … BN Hdr BL BL+1 BM BM+1 BN Hdr BL H* BL H* BL Hdr BL H* BL BL+1 BM BL+1 BM H*BL+1BM H*BL+1BM H*BL+1BM BM+1 BN H*BM+1BN H*BM+1BN H*BM+1BN BM+1 BN Naïve Framing Intelligent Framing 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)

  9. 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

  10. More Protocol Functions • Control transfer • Flow / congestion control • Detecting network transmission problems: loss, duplication, re-ordering • Acknowledgement • Multiplexing • Timestamping • Framing

  11. More Details • Simple measurements and argument to say: data manipulation is bottleneck • But control semantics place constraints on implementation, leads to layered implementations.

  12. 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

  13. 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

  14. 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?

  15. 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

  16. 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)

  17. 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)

More Related