87 research outputs found

    Low weight congestion control for multi sender applications

    Get PDF
    This paper presents a prototype for single-rate reliable multicast congestion control, which has been built into an existing commercial whiteboard. The prototype was developed using a novel scheme that was engineered around conflicting industry provided requirements for collaborative workspaces. This required the scheme to be both low-weight when used with many senders and compatible with NAT, firewalls and reflectors. The key to overcome this conflict was to combine congestion control and recovery feedback. This differs from many current solutions in that they are often designed for use with a wide variety of protocols and thus operate independent of the recovery mechanism. This paper does not go into the detail required to specify a protocol but instead discusses a few important design requirements for multi-sender applications, which are generally not considered by current research, and describes an approach towards meeting these requirements. Document type: Part of book or chapter of boo

    Enhanced transport protocols

    Get PDF
    The book presents mechanisms, protocols, and system architectures to achieve end-to-end Quality-of-Service (QoS) over heterogeneous wired/wireless networks in the Internet. Particular focus is on measurement techniques, traffic engineering mechanisms and protocols, signalling protocols as well as transport protocol extensions to support fairness and QoS. It shows how those mechanisms and protocols can be combined into a comprehensive end-to-end QoS architecture to support QoS in the Internet over heterogeneous wired/wireless access networks. Finally, techniques for evaluation of QoS mechanisms such as simulation and emulation are presented. The book is aimed at graduate and post-graduate students in Computer Science or Electrical Engineering with focus in data communications and networking as well as for professionals working in this area

    ADN: An Information-Centric Networking Architecture for the Internet of Things

    Full text link
    Forwarding data by name has been assumed to be a necessary aspect of an information-centric redesign of the current Internet architecture that makes content access, dissemination, and storage more efficient. The Named Data Networking (NDN) and Content-Centric Networking (CCNx) architectures are the leading examples of such an approach. However, forwarding data by name incurs storage and communication complexities that are orders of magnitude larger than solutions based on forwarding data using addresses. Furthermore, the specific algorithms used in NDN and CCNx have been shown to have a number of limitations. The Addressable Data Networking (ADN) architecture is introduced as an alternative to NDN and CCNx. ADN is particularly attractive for large-scale deployments of the Internet of Things (IoT), because it requires far less storage and processing in relaying nodes than NDN. ADN allows things and data to be denoted by names, just like NDN and CCNx do. However, instead of replacing the waist of the Internet with named-data forwarding, ADN uses an address-based forwarding plane and introduces an information plane that seamlessly maps names to addresses without the involvement of end-user applications. Simulation results illustrate the order of magnitude savings in complexity that can be attained with ADN compared to NDN.Comment: 10 page

    Reliable Multicast Transport for Heterogeneous Mobile IP environment using Cross-Layer Information

    Get PDF
    Reliable multicast transport architecture designed for heterogeneous mobile IP environment using cross-layer information for enhanced Quality of Service (QoS) and seamless handover is discussed. In particular, application-specific reliable multicast retransmission schemes are proposed, which are aimed to minimize the protocol overhead taking into account behaviour of mobile receivers (loss of connectivity and handover) and the specific application requirements for reliable delivery (such as carousel, one-to-many download and streaming delivery combined with recording). The proposed localized retransmission strategies are flexible configured for tree-based multicast transport. Cross layer interactions in order to enhance reliable transport and support seamless handover is discussed considering IEEE 802.21 media independent handover mechanisms. The implementation is based on Linux IPv6 environment. Simulations in ns2 focusing on the benefits of the proposed multicast retransmission schemes for particular application scenarios are presented

    A Survey on TCP-Friendly Congestion Control (extended version)

    Full text link
    New trends in communication, in particular the deployment of multicast and real-time audio/video streaming applications, are likely to increase the percentage of non-TCP traffic in the Internet. These applications rarely perform congestion control in a TCP-friendly manner, i.e., they do not share the available bandwidth fairly with applications built on TCP, such as web browsers, FTP- or email-clients. The Internet community strongly fears that the current evolution could lead to a congestion collapse and starvation of TCP traffic. For this reason, TCP-friendly protocols are being developed that behave fairly with respect to co-existent TCP flows. In this article, we present a survey of current approaches to TCP-friendliness and discuss their characteristics. Both unicast and multicast congestion control protocols are examined, and an evaluation of the different approaches is presented

    IP Multicast via Satellite: A Survey

    Get PDF
    Many of the emerging applications in the Internet, such astele-conferencing, distance-learning, distributed games, softwareupdates, and distributed computing would benefit from multicastservices. In many of these applications, there is a need todistribute information to many sites that are widely dispersed fromeach other. Communication satellites are a natural technology optionand are extremely well suited for carrying such services. Despite thepotential of satellite multicast, there exists little support forsatellite IP multicast services. Both Internet Engineering andInternet Research Task Forces (IETF and IRTF) have been involved in aresearch effort to identify the design space for a general purposereliable multicast protocol and standardize certain protocolcomponents as emph{building blocks}. However, for satellitemulticast services, several of these components have a differentdesign space. In this paper, we attempt to provide an overview of thedesign space and the ways in which the network deployment andapplication requirements affect the solution space. We maintain asimilar taxonomy to that of the IETF efforts, and identify which keycomponents of a general multicast protocol are affected by two of themost common satellite network deployment scenarios. We also highlightsome of the issues which we think are critical in the development ofnext generation satellite IP multicast services

    MCQUIC: Multicast and unicast in a single transport protocol

    Full text link
    Multicast enables efficient one-to-many communications. Several applications benefit from its scalability properties, e.g., live-streaming and large-scale software updates. Historically, multicast applications have used specialized transport protocols. The flexibility of the recently standardized QUIC protocol opens the possibility of providing both unicast and multicast services to applications with a single transport protocol. We present MCQUIC, an extended version of the QUIC protocol that supports multicast communications. We show how QUIC features and built-in security can be leveraged for multicast transport. We present the design of MCQUIC and implement it in Cloudflare quiche. We assess its performance through benchmarks and in emulated networks under realistic scenarios. We also demonstrate MCQUIC in a campus network. By coupling QUIC with our multicast extension, applications can rely on multicast for efficiency with the possibility to fall back on unicast in case of incompatible network conditions.Comment: 13 page
    corecore