Source author record

Dave Oran

Dave Oran appears in the imported research catalog. Authorship, coauthor and topic links are available while profile ownership is still unclaimed.

ResearcherUnclaimed source record

Catalog footprint

What is connected

2works
1topics
4close collaborators

Actions

Connect this record

Log in to claim

Research graph

See the researcher in context

Open full explorer

Inspect adjacent papers, topics, institutions and collaborators without losing the researcher page.

Building this map preview

BZPEER is loading the nearby papers, people, topics and institutions for this page.

Published work

2 published item(s)

preprint2016arXiv

Aesop Fable for Network Loops

Detecting loops in data networks usually involves counting down a hop limit or caching data at each hop to detect a cycle. Using a hop limit means that the origin of a packet must know the maximum distance a packet could travel without loops. It also means a loop is not detected until it travels that maximum distance, even if that is many loops. Caching a packet signature at each hop, such as a hash or nonce, could require large amounts of memory at every hop because that cached information must persist for as long as a loop could forward packets. This paper presents a new distributed loop detection mechanism based on a Tortoise and Hare algorithm that can quickly detect loops without caching per-packet data at each hop with a modest amount of additional state in each packet.

preprint2013arXiv

Probe and Adapt: Rate Adaptation for HTTP Video Streaming At Scale

Today, the technology for video streaming over the Internet is converging towards a paradigm named HTTP-based adaptive streaming (HAS). HAS comes with two unique flavors. First, by riding on top of HTTP/TCP, it leverages the network-friendly TCP to achieve firewall/NATS traversal and bandwidth sharing. Second, by pre-encoding and storing the video in a number of discrete bitrate levels, it introduces video bitrate adaptivity in a scalable way that the video encoding is excluded from the closed-loop adaptation. A conventional wisdom is that the TCP throughput observed by a HAS client indicates the available network bandwidth, thus can be used as a reliable reference for the video bitrate selection. We argue that this no longer holds true when HAS becomes a substantial fraction of the Internet traffic. We show that when multiple HAS clients compete at a network bottleneck, the presence of competing clients and the discrete nature of the video bitrates would together create confusion for a client to correctly perceive its fair-share bandwidth. Through analysis and real experiments, we demonstrate that this fundamental limitation would lead to, for example, video rate oscillation that negatively impacts the video watching experiences. We therefore argue that it is necessary to implement at the application layer a "probe-and-adapt" mechanism for HAS video rate adaptation, which is akin but orthogonal to the transport-layer network rate adaptation achieved by TCP. We present PANDA -- a client-side rate adaptation algorithm for HAS -- as an embodiment of this idea. Our testbed results show that compared to conventional algorithms, PANDA is able to reduce the instability of video rate by 60%, at a given risk of buffer underrun.