1. Publish/Subscribe Internetworking Transport Abstractions & Congestion Control Somaya Arianfar & Pasi Sarolahti 26.9.2011

2. Publish/Subscribe Internetworking Transport & Congestion Control © Pasi Sarolahti 2011 Agenda (for the general transport part) Traditional transport abstractions –Reflections from how things are done today Rethinking the transport concepts (layering etc.) Reliable Multicast Transport Peer-to-Peer Transport HTTP as a Pub/Sub Transport Open Issues 2

3. Publish/Subscribe Internetworking Transport & Congestion Control © Pasi Sarolahti 2011 The OSI Layer Model 3 Application Presentation Session Transport Network Data link Physical Program Application Presentation Session Transport Network Data link Physical Program Data DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData DataData

4. Publish/Subscribe Internetworking Transport & Congestion Control © Pasi Sarolahti 2011 PURSUIT Functional Model 4

5. Publish/Subscribe Internetworking Transport & Congestion Control © Pasi Sarolahti 2011 API Current Internet Transport Protocols Reliable Byte Stream Unreliable Datagrams Reliable Messages TCP UDP SCTP DCCP - Segmentation - Flow multiplexing - Retransmissions - Congestion ctrl - Segmentation - Flow multiplexing - Retransmissions - Congestion ctrl - Flow multiplexing - Cong. ctrl - Flow multiplexing - Cong. ctrl - Flow multiplexing - Retransmissions - Congestion ctrl - Lots of features… - Extensible - Flow multiplexing - Retransmissions - Congestion ctrl - Lots of features… - Extensible Internet Protocol

6. Publish/Subscribe Internetworking Transport & Congestion Control © Pasi Sarolahti 2011 IETF and the Transport Area 6 Congestion control and related transport protocols Interconnecting Content Distribution Networks Network File System, network storage Peer-to-peer communication TCP extensions and maintenance Reliable multicast transport QoS, new transport protocols, traffic engineering DCCP LEDBAT CONEX PCN CDNI NFSV4 STORM PPSP DECADE ALTO TCPM MPTCP RMT TSVWG

7. Publish/Subscribe Internetworking Transport & Congestion Control © Pasi Sarolahti 2011 Classical Example: TCP Service model: Reliable byte stream –No message boundaries Send(1024 bytes) may result in Receive(512 B) + Receive(512 B) –One-to-one association Segmentation to packets –Depends on network path MTU Reliable: retransmissions based on acknowledgments and timer Congestion control: based on RTT measurements and packet loss events Much intelligence at sender, some intelligence at receiver –No intelligence in network 7

8. Publish/Subscribe Internetworking Transport & Congestion Control © Pasi Sarolahti 2011 Another Example: DCCP (Datagram Congestion Control Protocol) Service Model: Unreliable datagrams –Send(1024 B) results in Receive(1024 B) – or no Receive at all –One-to-one association Unreliable: no retransmissions Congestion control: based on RTT measurements and packet loss events –Requires acknowledgment mechanism –…and connection state at the sender Feature negotiation (e.g., for congestion control algorithm) Much intelligence at sender, some intelligence at receiver –Very different from UDP (for unreliable datagrams) 8

9. Publish/Subscribe Internetworking Transport & Congestion Control © Pasi Sarolahti 2011 Connection-oriented vs. Connectionless Two ends of the connection need to agree on –Protocol parameters e.g., type of acknowledgments, maximum segment size –Shared “secrets” e.g., TCP’s initial sequence number Reliable connection establishment method needed –Typically: three-way handshake Connection-oriented is easy with 1-to-1 connections –How to do it between multiple senders and receivers? 9

10. Publish/Subscribe Internetworking Transport & Congestion Control © Pasi Sarolahti 2011 Middleboxes and Connectivity NATs, Firewalls and other types of intermediaries have become common –These operate on packets’ transport headers (or deeper) –Typically support only the most common protocols TCP and UDP One difficulty: pseudoheader checksum calculation and NATs Difficult challenge for deployment of new protocols –Unknown protocols often lost in transit Common trick is to encapsulate packets inside UDP Additional problem: short lease times –Idle periods lead to dropped connections 10

11. Publish/Subscribe Internetworking Transport & Congestion Control © Pasi Sarolahti 2011 Rethinking Layering Transport Layer –Communication abstractions, reliability, etc. Flow Regulation Layer –Congestion control, etc. –Adaptability to special algorithms and path conditions –Multipath communication Endpoint Layer –Logical endpoints (i.e., ports) –Extension of network layer 11 B. Ford and J. Iyengar, “Breaking Up the Transport Logjam” In Proc. of ACM HotNets-VII, October 2008

12. Publish/Subscribe Internetworking Transport & Congestion Control © Pasi Sarolahti 2011 Structured Streams Addresses some of TCP problems –Head-of-Line blocking –Integrated congestion control Channel Protocol –Congestion control –Security associations Stream Protocol –Hierarchical model E.g., “www” root stream distributed into streams of web pages and subobjects –Stream is associated with channel 12 B. Ford, “Structured Streams: a New Transport Abstraction” In Proc. of ACM SIGCOMM ‘07, August 2007

13. Publish/Subscribe Internetworking Transport & Congestion Control © Pasi Sarolahti 2011 Host-Centric Networking vs. Content-Centric Networking Host networking –Resources are located based on topological address IP addresses Routing is “easy” –DNS is used to map host names to IP addresses –Communication associations are between hosts E.g. TCP connections –Security model usually based on hosts Content networking –Resources are located by content-based name Often flat, topology- independent namespace Routing is difficult Sometimes host identities not even known –No host-based communication abstractions Content distribution, content migration becomes easier –Security model based on content 13

14. Publish/Subscribe Internetworking Transport & Congestion Control © Pasi Sarolahti 2011 But… 14 How do we implement transport for publish/subscribe networks? Picture from: http://www.clker.com

15. Publish/Subscribe Internetworking Transport & Congestion Control © Pasi Sarolahti 2011 Multicast Transport Special IP address range reserved for “channels” –UDP packets –Receivers join and leave channels using IGMP or MLD protocols –Source specific multicast limits the allowed sources of data Multicast not globally deployed –But in limited use e.g. in IPTV distribution Many channels do not need reliability –Real-time A/V streaming, etc. How to guarantee reliability in multicast session? –In a session of 100 subscribers, what if one receiver misses data? What is the feedback mechanism? What to retransmit, when and where? 15

16. Publish/Subscribe Internetworking Transport & Congestion Control © Pasi Sarolahti 2011 Reliable Multicast Transport Designated receivers (RMTP) –Separate acknowledgments, aggregated over tree of designated receivers Network coding –Add redundancy along data –For the price of overhead, can re-construct individual packets Data Carousel –Repeated transmission of same data 16 A. Dimakis, K. Ramchandran, Y Wu and C. Suh, “A Survey on Network Codes for Distributed Storage”, In Computing Research Repository, April 2010. http://arxiv.org/abs/1004.4438 J.C. Lin and S. Paul, “RMTP: A Reliable Multicast Transport Protocol”, In Proc. of IEEE Infocom ‘96, March 1996.

17. Publish/Subscribe Internetworking Transport & Congestion Control © Pasi Sarolahti 2011 Peer-to-Peer Transport (BitTorrent) Peers exchange 256 KB chunks –Controlled by tracker –Exchanged in “random” order Old version: on top of TCP –Each peer runs multiple TCP connections –TCP congestion control New version: dedicated transport protocol –Delay-based congestion control –Yields to other traffic 17 tracker

18. Publish/Subscribe Internetworking Transport & Congestion Control © Pasi Sarolahti 2011 Content-orientedness and TCP (Warning: research in progress…) Target: get some of the benefits of content-centric networking to TCP –mainly caching New TCP option –Content label – identifies content in TCP payload Benefits: –Packet-based caching in current infrastructure Challenges –Interactions with some TCP details 18 cache senderreceiver

19. Publish/Subscribe Internetworking Transport & Congestion Control © Pasi Sarolahti 2011 HTTP as a Pub/Sub Transport Much of the Internet traffic use HTTP –Accessible from most locations behind middleboxes –Lots of apps: real-time video, Email, version control, file storage Content-centric protocol methods –GET: fetch a resource from a server –PUT: push content to a server –HTTP chunking enables datagram-like service (e.g., for video) Pub/Sub could be implemented with variation of GET –S-GET: Remember the GET request at HTTP server (like named pipe) 19 L. Popa, A. Ghodsi, I. Stoica, “HTTP as the Narrow Waist of the Future Internet” In Proc. of ACM HotNets-IX, October 2010

20. Publish/Subscribe Internetworking Transport & Congestion Control © Pasi Sarolahti 2011 Open(?) Issues with Publish/Subscribe Transport How to know Maximum Transmission Unit? –What is the packet size? When to retransmit (if retransmissions are needed)? Request per packet vs. request per “flow”? –How to do flow control? How to build feedback channel? Reliability? Buffering? Reliable transport on top of pub/sub, or pub/sub over reliable transport? 20