text: Content-Centric Networking (CCN) is a concept being considered as a potential future alternative to, or replacement for, today's Internet IP-style packet-switched host-centric networking. One factor making CCN attractive is its focus on content distribution, which dominates current Internet traffic and which is arguably not well-served by IP. Named Data Networking (NDN) is a prominent example of CCN. It is also one of several on-going research efforts aiming to design and develop a full-blown candidate future Internet architecture. Although NDN's primary motivation is content distribution, it is envisioned to support other types of traffic, such as conferencing (audio, video) as well as more historical applications, such as remote login. However, it is unclear how suitable NDN is for applications that are not obviously content-centric. In this paper, we explore NDN in the context of a class of applications that involve low- latency bidirectional communication. Specifically, we propose a few architectural amendments to NDN that provide significantly better throughput and lower latency for this class of applications. The proposed approach is validated via both simulations and testbed experiments.
  @cite_9: We use simulation to make some observations about the behavior of the congestion control algorithm currently embedded in the 4.3-Tahoe BSD TCP implementation. We investigate a simple case of a few TCP connections, originating and terminating at the same pair of hosts, using a single bottleneck link. Our simulations reveal two unexpected phenomena. First, packets from the individual connections, rather than being mixed together, completely separate into individual clusters. Second, every connection loses a single packet during each congestion epoch. As a way of exploring the cause of these phenomena, we discuss how the behavior is altered by modifications to the congestion control algorithm and to the switch queue control algorithm.
  @cite_11: We use simulation to study the dynamics of the congestion cent rol algorithm embedded in the BSD 4.3-Tahoe TCP implementation. We investigate the simple case of a few TCP connections, originating and terminating at the same pair of hosts, using a single bottleneck link. This work is an extension of our earlier work ([16]), where one-way traffic (i.e., all of the sources are on the same host and all of the destinations are on the other host) was studied. In this paper we investigate the dynamics that results from two-way traffic (in which there are data sources on both hosts). We find that the one-way traffic clustering and loss-synchronization phenomena d cussed in [16] persist in this new situation, albeit in a slightly modified form. In addition, there are two new phenomena not present in the earlier study: (1) ACK-compression, which is due to the interaction of data and ACK packets and gives rise to rapid fluctuations in queue length, and (2) an out-of-phase queue-synchronization mode, which keeps link utilization less than optimal even in the limit of very large buffers. These phenomena are helpful in understanding results from an earlier study of network oscillations ([19]).
summary: In @cite_11 , study the effect of bi-directional traffic on TCP congestion control algorithm. In particular, they observe that in the BSD Tahoe TCP implementation packets from a single connection are clustered together, similarly to what observed by the same authors in @cite_9 over one-way traffic. This causes ACK compression, which significantly reduces the available bandwidth for TCP connections. They also show that in case of two-way traffic, the issue of ACK compression is made worse by the interaction of ACKs and data packets in the queue.