The Logistical Session Layer

1. The Logistical Session Layer Martin Swany

2. Network Logistics • The definition of Logistics “…the process of planning, implementing, and controlling the efficient, effective flow and storage of goods, services and related information from point of origin to point of consumption.” • Shipping and distribution enterprises make use of storage (and transformation) when moving material • Improving the flow, storage, and access of data is necessary to make advanced distributed computing viable

3. The Logistical Session Layer • LSL allows systems to exploit “logistics” in stream-oriented communication • LSL Service Nodes (depots) provide short-term buffering and cooperative data forwarding • The initial focus is improved throughput for reliable data streams • Both unicast and multicast • Other functionality is enabled M. Swany, R. Wolski, Data Logistics in Network Computing: The Logistical Session Layer, Proc. IEEE Network Computing and Applications, October, 2001.

4. The Logistical Session Layer

5. Internet Backplane Protocol • LSL is closely related to IBP • Depots are similar in spirit but don’t yet share an implementation Exposed network buffers J. Plank, A. Bassi, M. Beck, T. Moore, M. Swany, R. Wolski, The Internet Backplane Protocol: Storage in the Network, IEEE Internet Computing, September/October 2001.

6. User Space Transport Network Data Link Session Session Physical Transport Transport Network Network Data Link Data Link Physical Physical Session Layer • A session is the end-to-end composition of segment-specific transports and signaling • More responsive control loop via reduction of signaling latency • Adapt to local conditions with greater specificity • Buffering in the network means retransmissions need not come from the source

7. Initial Deployment US Test Deployment

8. LSL Performance Improvement

9. TCP Overview • TCP provides reliable transmission of byte streams over best-effort packet networks • Sequence number to identify stream position inside segments • Segments are buffered until acknowledged • Congestion (sender) and flow control (receiver) “windows” • Everyone obeys the same rules to promote stability, fairness, and friendliness • Congestion-control loop uses ACKs to clock segment transmission • Round Trip Time (RTT) critical to responsiveness • Conservative congestion windows • Start with window O(1) and grow exponentially then linearly • Additive increase, multiplicative decrease (AIMD) congestion window based on loss inference • “Sawtooth” steady-state • Problems with high bandwidth delay product networks

10. End-to-End Session HOPI

11. Routing and Network Scheduling • This approach needs to take current network conditions into account • Dynamic network conditions allow the application and the LSL Service nodes to adapt buffering and to make choices where alternative paths exist • When the connection is no longer as sensitive to latency, there are many more opportunities • How can we get this information?

12. System Architecture & Protocol • Logistical Service Nodes (LSNs) at strategic locations in the network • LSNs provide a data store • LSNs provide a locus of control • Session-layer protocol establishes transport- layer connections

13. LSL Implementation • The LSL client library provides compatibility with current socket applications • Although more functionality is available using the API directly • LD_PRELOAD for function override • socket(), bind(), connect(), setsockopt()… • Allows Un*x binaries to use LSL without recompilation • Daemon runs on all Un*x platform • Forwarding is better on Linux than on BSD

14. Transparent Intercept • Intercept the TCP SYN with IP Tables (on Linux) • Redirect to local LSL process • Establish connection with appropriate LSNs or end node • Based on policy, DSCP, ToS… • Transparent to end hosts

15. Recall TCP’s sequence number and ACKs We can observe the progress of a TCP connection by plotting the sequence number acknowledged by the receiver For this experiment, we captured packet-level traces of both LSL and end-to-end connections 10 traces for each path and subpath were gathered We compute the average growth of the sequence number with respect to time The following graphs depict average progress of a set of transfers Cascaded TCP Dynamics

16. LSL Speedup - UCSB/UIUC

17. UCSB->Denver->UIUC (64M)

18. LSL Speedup - UCSB/UF

19. UCSB->Houston->UFL (64M)

20. LSL Summary • Logistical data overlays can significantly improve performance for data movement • Demonstrated speedup with user-level implementation • The notion of a session as the composition of network-specific transport layers is powerful • There are many cases in which a single transport protocol from end to end might not be the best choice • High bandwidth*delay • Network heterogeneity • Wireless • Optical (with time-division multiplexing) • Potential to become a new model rather than short-term solution for TCP’s problems

21. The End to End Arguments • Why aren’t techniques like this already in use? • Recall the end-to-end arguments • E2E Integrity • Network elements can’t be trusted • Duplication of function is inefficient • Fate sharing • State in the network related to a user • Scalability • Network transparency or opacity • Pervious assumptions regarding scalability and complexity may not hold true any longer

22. Current Work • LSL • Deploying on GÉANT to support eVLBI • Linux kernel module • Phoebus (and HOPI) • LSL-NP • Intel IXP implementation • GSL

23. Benefits for Switched Optical Networks • Push adaptation points toward shared edge networks • Reduced number of contending entities for scheduling (1 < Entities < Nodes) • Advanced scheduling brokers • Buffering for efficient coarse-grained burst switching • Trusted signaling points able to evaluate rich policy definitions • IP-based ACLs are insufficient (or worse!)

24. LSL-NP • Implementation of LSL on IXP Network Processor from Intel • The IXP2800 can forward at 10Gb/sec with ~80 cycle budget per packet • We’re using the IXP2400 which differs in the number of packet handling Microengines • Xscale processor handles connection establishment • Microengines should do as much of the work as possible • Many router vendors can insert an NP blade

25. Generic Session Layer (GSL) • New version of the LSL protocol that unifies the LSL and Phoebus work • Support for Session-Layer Frames • Similar to markers as described in ISO/OSI 8827 • Essentially the megagrams discussed previously • Rendezvous protocol for changing IP addresses • IPv6 multihoming issues (Is Shim6 really the answer?) • Strong authentication at session initialization time is amortized over the life of the connection • Are per-packet firewalls really the answer?

26. GSL Benefits • Incremental deployability • No need to upgrade end hosts or current packet infrastructure • Reduced burden on end hosts • CPU Load • Software maintenance • TCP friendly at the edges (as necessary) • Adaptation point and control plane for network tuning and evolution • Signaling, Transport, QoS

27. GSL Benefits • Buffering data • Best effort is nice, but what if we’d really like to have that data? • Explicit security that is flexible • Credential exchange • Rich policy evaluation • QoS adaptation point • Frame size adaptation point

28. Questions or Comments? • Thank you for attending!