Driven by diverse needs of students, as well as increasing needs of other disciplines, the past two decades have seen a proliferation of emerging variations in how computer science programs approach a second course in the discipline. Approaches more focused on majors include adaptations to a traditional introduction to data structures course that may heavily incorporate object-oriented programming or emphasize using data structures from libraries. Paths that might be concurrent with a traditional CS2, or have greater appeal to non-majors include recent efforts with data science or secure computing. In a world of increasingly limited resources but ever-increasing needs and demands from inside and outside the major, how do we provide solutions? Bringing together educators who are concerned about intermediate CS education will allow participants to hear multiple viewpoints about what the needs are and how various institutions are currently, or are considering, addressing them. The discussion leaders will kick off the conversation with local expertise---one approach of a CS2 course for majors and non-majors that emphasizes data science and modern practical skills such as databases and HTTP, another with new curricula for multiple CS2 courses, and a third with novel approaches in a traditional data structures CS2 course. Attendees will be able to connect with other people interested in the future of course curricula following CS1 and share ideas, resources, successes, and failures. We will be soliciting participants' perspectives on preparing CS2 students for downstream paths, including (i) future courses, (ii) interviews, (iii) internships, and (iv) research projects.

The need for understanding data systems, from the structure and constraints of data models to the client-server mechanisms for acquiring and curating data, includes not just computer science students, but extends to data science students and students in a wide range of interdisciplinary programs. In this paper we describe the design and implementation of a second course in computer science, whose data-centric focus emphasizes structural models of data and the skills involved in acquiring and transforming data into forms amenable for analysis. We argue that, from a user-not-designer perspective, these topics need not wait for an upper-level database course, but to achieve sufficient depth, an introductory computer science course is appropriate and sufficient as a prerequisite.

The performance of Hadoop YARN MapReduceapplications can be distilled down to a relatively small handfulof performance factors affecting the completion of the individualtask component times of map task time, shuffle time, mergetime, and reduce task time. These four components, coupledwith the operational policies of an application master and theresource management and scheduling ultimately determine theperformance of an application executing on a given cluster. Wepresent models for each of these task components and assess themodels against MapReduce applications to demonstrate their promise.

Despite much work in simulation of MapReduce applications and in optimizing scheduling to minimize workload execution time, we still need models and tools to understand the performance of the individual tasks of a MapReduce application. Armed with this knowledge, we can characterize applications and model task operation to determine their performance in a given cluster setting. We have developed and analyzed a model of MapReduce tasks that abstracts their operation at a balanced level, avoiding too much detail that slows down analysis and requires knowledge of the inner workings of the cluster system, but at sufficient detail to be able to generalize to multiple application classes and cluster systems. The model, and an accompanying simulator, are evaluated against execution of real MapReduce applications, and show very promising results.

Traditionally, cluster computing has employed checkpointing to address fault tolerance. Recently, new models for parallel applications have grown in popularity namely MapReduce and Dryad, with runtime systems providing their own re-execute based fault tolerance mechanisms, but with no analysis of their failure characteristics. Another development is the availability of failure data spanning years for systems of significant size at Los Alamos National Labs (LANL), but the time between failure (TBF) for these systems is a poor fit to the exponential distribution assumed by optimization work in checkpointing, bringing these results into question. The work in this paper describes a discrete event simulation driven by the LANL data and by models of parallel checkpointing and MapReduce tasks. The simulation allows us to then evaluate and assess the fault tolerance characteristics of these tasks with the goal of minimizing the expected running time of a parallel program in a cluster in the presence of faults for both fault tolerance models.

This article describes an architecture that allows a replicated service to survive crashes without breaking its TCP connections. Our approach does not require modifications to the TCP protocol, to the operating system on the server, or to any of the software running on the clients. Furthermore, it runs on commodity hardware. We compare two implementations of this architecture (one based on primary/backup replication and another based on message logging) focusing on scalability, failover time, and application transparency. We evaluate three types of services: a file server, a Web server, and a multimedia streaming server. Our experiments suggest that the approach incurs low overhead on throughput, scales well as the number of clients increases, and allows recovery of the service in near-optimal time.

In a recent paper we have proposed FT-TCP: an architecture that allows a replicated service to survive crashes without breaking its TCP connections. FT-TCP is attractive in principle because it does not require modifications to the TCP protocol and does not affect any of the software running on the clients; however, its practicality for real-world applications remains to be proven. In this paper, we report on our experience in engineering FT-TCP for two such applications---the Samba file server and a multimedia streaming server from Apple. We compare two implementations of FT-TCP, one based on primary-backup and another based on message logging, focusing on scalability, failover time, and application transparency. Our experiments suggest that FT-TCP is a practicable approach for replicating TCP/IP-based services that incurs low overhead on throughput, scales well as the number of clients increases, and allows recovery of the service in near-optimal time.

An Internet Service Provider must provide transit service for traffic between its customers and its providers and, at the same time, attempt to minimize network utilization and balance traffic according to the capacities of its border routers. Central to the selection of border routers for transit traffic flows is the Border Gateway Protocol (BGP) between Autonomous System (AS) peers, through which route advertisements for network prefixes determine the selection of border routers for each traffic flow. This paper examines the problem of determining an optimal set of border routers for the advertisement of network prefixes so as to minimize the cost of traffic across a transit service provider's network while maintaining egress bandwidth constraints at the border routers. Egress bandwidth constraints are considered because there is anecdotal evidence to suggest that the peering links between ASs are often bottleneck links in the Internet, and so the optimal utilization of these links is also critical. After precisely formulating the optimization problem in accordance with the operation of BGP, we relate the problem to the generalized assignment problem and develop heuristic solutions for solving it. Simulation results from an implementation show up to a 37% improvement in the utilization of the peering links when compared to hot potato routing.

Systems that are designed to recover from system failure due to software faults of the operating system and/or application typically require a means of persistently storing a subset of the state of the application. Disk drives are most often used as this persistent storage, but at a performance cost incurred repeatedly during normal execution as well as again at recovery time. Academic work has pioneered the concept of using a region of conventional memory, protecting it, and making it persist across operating system crashes and reboots, and making it as reliable as a disk. This can be used in place of a disk to alleviate the performance penalties noted above. This paper describes a project to take these concepts and apply them in a RAM disk-based realization of persistent memory (PM) as part of the Lucent DNCP (Distributed Network Control Platform) hardware fault-tolerant platform and implemented for the HP-UX operating system, focusing on its use by a main-memory database (MMDB) system. While we found that the reduction in recovery time was small relative to the reboot time, we achieved a nearly 40% reduction in execution time for an MMDB benchmark run on the PM as opposed to its normal use of a disk for achieving recoverability.

We present an implementation of a fault-tolerant TCP (FT-TCP) that allows a faulty server to keep its TCP connections open until it either recovers or it is failed over to a backup. The failure and recovery of the server process are completely transparent to client processes connected with it via TCP. FT-TCP does not affect the software running on a client, does not require to change the server's TCP implementation, and does not use a proxy.

Protocols to implement a fault-tolerant computing system are described. These protocols augment the hypervisor of a virtual-machine manager and coordinate a primary virtual machine with its backup. No modifications to the hardware, operating system, or application programs are required. A prototype system was constructed for HP's PA-RISC instruction-set architecture. Even though the prototype was not carefully tuned, it ran programs about a factor of 2 slower than a bare machine would.

Protocols to implement a fault-tolerant computing system are described.These protocols augment the hypervisor of a virtttalmachine manager and coordinate a primary virtual machine with its backup.The result is a fault-tolerant computing system.No modification to hardware, operating system, or application programs is required.A prototype system was constructed for HP's PA-RISC instruction-set architecture.The prototype was able to run programs about a factor of 2 slower than a bare machine would.