1 CS 268: Computer Networking L-20 Data-Oriented Networking Outline • Data-oriented Networking • DTNs 22 Data-Oriented Networking Overview • In the beginning... – First applications strictly focused on host-to-host interprocess communication: • Remote login, file transfer, ... – Internet was built around this host-to-host model. – Architecture is well-suited for communication between pairs of stationary hosts. • ... while today – Vast majority of Internet usage is data retrieval and service access. – Users care about the content and are oblivious to location. They are often oblivious as to delivery time: • Fetching headlines from CNN, videos from YouTube, TV from Tivo • Accessing a bank account at “www.bank.com”. 3 To the beginning... • What if you could re-architect the way “bulk” data transfer applications worked • HTTP • FTP • Email • etc. • ... knowing what we know now? 43 Innovation in Data Transfer is Hard • Imagine: You have a novel data transfer technique • How do you deploy? • Update HTTP. Talk to IETF. Modify Apache, IIS, Firefox, Netscape, Opera, IE, Lynx, Wget, … • Update SMTP. Talk to IETF. Modify Sendmail, Postfix, Outlook… • Give up in frustration 5 6 Mul$‐path*USB*USB*Xfer%Data-Oriented Network Design NET*(%DSL%)%Xfer%NET*NET*wireless%SENDER*RECEIVER*Internet* Store-carry-forward Multipath and Mirror support NET*CACHE*Xfer%Features4 New Approach: Adding to the Protocol Stack 7 Transport Network Data Link Physical Router Bridge Internet Protocol Layers ALG Middleware Application Software-defined radio Object Exchange Data Transfer Data Transfer Service • Transfer Service responsible for finding/transferring data • Transfer Service is shared by applications • How are users, hosts, services, and data named? • How is data secured and delivered reliably? • How are legacy systems incorporated? 8 Application Protocol Sender Receiver Xfer Service Xfer Service and Data Data5 Naming Data (DOT) • Application defined names are not portable • Use content-naming for globally unique names • Objects represented by an OID • Objects are further sub-divided into “chunks” • Secure and scalable! 9 Cryptographic%Hash%Similar Files: Rabin Fingerprinting 10 4 7 8 2 8 File Data Rabin Fingerprints Given Value - 8 Natural Boundary Natural Boundary Hash 1 Hash 26 Naming Data (DOT) • All objects are named based only on their data • Objects are divided into chunks based only on their data • Object “A” is named the same • Regardless of who sends it • Regardless of what application deals with it • Similar parts of different objects likely to be named the same • e.g., PPT slides v1, PPT slides v1 + extra slides • First chunks of these objects are same 11 11 Naming Data (DONA) • Names organized around principals. • Names are of the form P : L. • P is cryptographic hash of principal’s public key, and • L is a unique label chosen by the principal. • Granularity of naming left up to principals. • Names are “flat”. 127 Self-certifying Names • A piece of data comes with a public key and a signature. • Client can verify the data did come from the principal by • Checking the public key hashes into P, and • Validating that the signature corresponds to the public key. • Challenge is to resolve the flat names into a location. 13 Xfer*Service*Xfer*Service*Sender*Receiver*Locating Data (DOT) Request File X OID, Hints put(X) OID, Hints get(OID, Hints) read() data Transfer Plugins 148 Name Resolution (DONA) • Resolution infrastructure consists of Resolution Handlers. • Each domain will have one logical RH. • Two primitives FIND(P:L) and REGISTER(P:L). • FIND(P:L) locates the object named P:L. • REGISTER messages set up the state necessary for the RHs to route FINDs effectively. 15 Locating Data (DONA) 16 %REGISTER%state%FIND%being%routed%9 Establishing REGISTER state • Any machine authorized to serve a datum or service with name P:L sends a REGISTER(P:L) to its first-hop RH • RHs maintain a registration table that maps a name to both next-hop RH and distance (in some metric) • REGISTERs are forwarded according to interdomain policies. • REGISTERs from customers to both peers and providers. • REGISTERs from peers optionally to providers/peers. 17 Forwarding FIND(P:L) • When FIND(P:L) arrives to a RH: • If there’s an entry in the registration table, the FIND is sent to the next-hop RH. • If there’s no entry, the RH forwards the FIND towards to its provider. • In case of multiple equal choices, the RH uses its local policy to choose among them. 1810 Interoperability: New Tradeoffs 19 Data Link Physical Applications The Hourglass Model ‘Thin Waist’ Limits%ApplicaFon%InnovaFon%Increases%Data%Delivery%Flexibility%UDP TCP Data Link Physical Applications The Hourglass Model InnovaFon% Flexibility%Network (IP/Other) Moving up the Transport (TCP/Other) Interoperability: Datagrams vs. Data Blocks Datagrams Data Blocks What must be standardized? IP Addresses NameAddress translation (DNS) Data Labels Name Label translation (Google?) Application Support Exposes much of underlying network’s capability Practice has shown that this is what applications need Lower Layer Support Supports arbitrary links Requires end-to-end connectivity Supports arbitrary links Supports arbitrary transport Support storage (both in-network and for transport) 2011 Outline • Data-oriented Networking • DTNs 21 Unstated Internet Assumptions • Some path exists between endpoints • Routing finds (single) “best” existing route • E2E RTT is not very large • Max of few seconds • Window-based flow/cong ctl. work well • E2E reliability works well • Requires low loss rates • Packets are the right abstraction • Routers don’t modify packets much • Basic IP processing 2212 New Challenges • Very large E2E delay • Propagation delay = seconds to minutes • Disconnected situations can make delay worse • Intermittent and scheduled links • Disconnection may not be due to failure (e.g. LEO satellite) • Retransmission may be expensive • Many specialized networks
View Full Document
Unlocking...