Search

Mr. Dean Armann gave the historical background as to how Pacific Measurements arrived at a Scaler Network Analyzer, and gave a brief description of the NS-20. Mr. Scott Wetenkamp discussed the effects of harmonics and sub-harmonics and techniques employed to reduce these effects. He also described the nonvolatile memory.

Three key system-independent functional measures of the effectiveness of interactive computer service are response time, turnaround time, and throughput. Measurement can be made under uncontrolled conditions using a communications monitor such as the NBS Network Measurement System and under controlled conditions using Remote Terminal Emulators. Additional measurement and test tools include accounting logs and programs, stopwatches, live operators, tape loops, and internal stimulators. A feasibility test is described; a collection of illustrative data is presented.

In high-speed networks, such as 1-Gbps or higher networks, bandwidth measurement algorithms that utilize packet transmission/arrival intervals, such as packet trains and packet pairs, have a number of problems. First, network measurement for large bandwidth requires short packet transmission intervals, which causes a heavy load on the CPU. Second, network interface cards for high-speed networks usually employ Interrupt Coalescence (IC), which rearranges the arrival intervals of packets and causes bursty transmission of packets. In the present study, we introduce ICIM (Interrupt Coalescence-aware inline measurement), a new bandwidth measurement approach that overcomes these two problems. ICIM utilizes the data packets of an active TCP connection for the measurement. In order to determine the available bandwidth, rather than adjusting the packet transmission intervals, the TCP sender instead adjusts the number of packets involved in a burst and checks whether the inter-intervals of the bursts of corresponding ACK packets are increased or not. Simulation results show that ICIM can measure the bandwidth as high as some Gbps while requiring a number of data packets that is only 1/100 of that of the existing stream-based algorithm.

International audience; Public blockchains, like Ethereum, rely on an underlying peer-to-peer (P2P) network to disseminate transactions and blocks between nodes. With the rise of blockchain applications and cryptocurrencies values, they have become critical infrastructures which still lack comprehensive studies. In this paper, we propose to investigate the reliability of the Ethereum P2P network. We developed our own dependable crawler to collect information about the peers composing the network. Our data analysis regarding the geographical distribution of peers and the churn rate shows good network properties while the network can exhibit a sudden and major increase in size and peers are highly concentrated on a few ASes. In a second time, we investigate suspicious patterns that can denote a Sybil attack. We find that many nodes hold numerous identities in the network and could become a threat. To mitigate future Sybil attacks, we propose an architecture to detect suspicious nodes and revoke them. It is based on a monitoring system, a smart contract to propagate the information and an external revocation tool to help clients remove their connections to suspicious peers. Our experiment on Ethereum's Test network proved that our solution is effective.

The match between a peer-to-peer overlay and the physical Internet infrastructure is a constant issue. Time-constrained peer-to-peer applications such as live streaming systems are even more challenging because participating peers have to discover their closest neighbors as quickly as possible. We propose in this paper an approach based on landmarks and a management server. Despite its centralized architecture, this method can scale to a large population of peers. We focus in this paper on challenging this basic idea through intensive simulations, using a large-scale map of the Internet router (IR) layer in a simulator dedicated to peer-to-peer systems. We compare the results obtained by the new method with a random selection and an optimal selection and we show that this proposal makes sense.

Availability of deep packet inspection methods and systems allows network operators to classify traffic on the base of the application type. Once classified, traffic may be subject to artificial bandwidth limitations (e.g. in case of resourcedemanding applications) or to class-dependent forwarding policies (e.g. to divert the traffic generated by specific applications on low-priority links). In this paper we describe a method that can be useful to detect the presence of class-dependent forwarding policies. The method is based on traceroute-like mechanisms embedded within the normal communication flow of an application. The method is contextualized in a study about the neutrality of mobile network operators, to understand if a correlation can be found between the presence of class-dependent forwarding strategies and limitations of bandwidth.

We present a detailed re-examination of the problem of inexpensive yet accurate clock synchronization for networked devices. Based on an empirically validated, parsimonious abstraction of the CPU oscillator as a timing source, accessible via the TSC register in popular PC architectures, we build on the key observation that the measurement of time differences, and absolute time, requires separate clocks, both at a conceptual level and practically, with distinct algorithmic, robustness, and accuracy characteristics. Combined with round-trip time based filtering of network delays between the host and the remote time server, we define robust algorithms for the synchronization of the absolute and difference TSCclocks over a network. We demonstrate the effectiveness of the principles, and algorithms using months of real data collected using multiple servers. We give detailed performance results for a full implementation running live and unsupervised under numerous scenarios, which show very high reliability, and accuracy approaching fundamental limits due to host system noise. Our synchronization algorithms are inherently robust to many factors including packet loss, server outages, route changes, and network congestion.