DOCSLIB.ORG

Dynamic Jumbo Frame Generation for Network Performance Scalability

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Dynamic Jumbo Frame Generation for Network Performance Scalability 1 JumboGen: Dynamic Jumbo Frame Generation For Network Performance Scalability David Salyers, Yingxin Jiang, Aaron Striegel, Christian Poellabauer Department of Computer Science and Engineering University of Notre Dame Notre Dame, IN. 46530 USA Email: {dsalyers, yjiang3, striegel, cpoellab}@nd.edu Abstract— Network transmission speeds are increasing at a there is a fixed amount of overhead processing per packet, significant rate. Unfortunately, the actual performance of the it is a challenge for CPUs to scale with increasing network network does not scale with the increases in line speed. This speeds [2]. In order to overcome this issue, many works on is due to the fact that the majority of packets are less than or equal to 64 bytes and the fact that packet size has not scaled with high performance networks, as in [3] and [4], have advocated the increases in network line speeds. This causes a greater and the use of a larger MTU length or jumbo frames. These works greater load to be placed on routers in the network as routing show that the performance of TCP and the network in general decisions have to be made for an ever increasing number of can significantly improve with the use of jumbo-sized packets. packets, which can cause increased packet delay and loss. In Unfortunately, the benefits of jumbo frames are limited for order to help alleviate this problem and make the transfer of bulk data more efficient, networks can support an extra large several reasons. First, the majority of packets transferred are MTU size. Unfortunately, when a packet traverses a number of 64 bytes or less. In this case, a larger MTU would not increase different networks with different MTU sizes, the smallest of the the efficiency of the network since the smaller MTU is already MTU sizes will determine the size of the packet that arrives at significantly greater than the packet size. The second factor the destination, which will limit the effectiveness of large MTU that limits the use of jumbo frames is the lack of end-to- packets. In this paper we present our solution, JumboGen, an approach end support. If at any point during the packet transmission that will allow for a higher utilization of larger packet sizes on the jumbo frame passes through a node that does not support a domain-wise basis, instead of on an end-to-end basis. Smaller jumbo frames, the packet will be fragmented into many smaller packets are encapsulated into a larger packet for transmission packets via IP fragmentation. The destination will then receive across the domain. At the egress point, the original packets are these small fragments instead of the original jumbo frame. removed from the jumbo-sized packet and forwarded toward their final destination such that no nodes besides the ingress and Given that network speeds will be increasing for the fore- egress are aware any conversion took place. Through simulations, seeable future, a reduction in the volume of packet processing we show that the dynamic creation of jumbo packets for the is critical. However, the legacy nature of the current Internet domain does not adversely affect the network in terms of link dictates that attempts to impose end-to-end solutions for larger utilization or fairness while decreasing the number of packets packet sizes will be plagued by fragmentation, thus removing processed by core routers. The decrease in the number of packets seen by the core routers will lessen their load and improve their their benefit. In this paper, we propose the JumboGen approach ability to scale to greater and greater network speeds. which allows for the incremental deployment and efficient utilization of jumbo-size packets. JumboGen dynamically aggregates smaller packets at the I. INTRODUCTION ingress to a domain for domain-wise transmission as a single Network (LAN and WAN) speeds are continuously increas- large JumboGen packet. At the egress point, the original ing and are such that computer networks can now transfer packets are de-queued, shaped, and transmitted toward their billions of bits, and beyond, of information every second. final destination. The end result of JumboGen is a significant However, in these high speed networks, the number of packets reduction in the number of packets, hence significantly im- becomes a major bottleneck for the performance of the routers proving the scalability of the core of the network. due to the overhead associated with each packet. There are two However, before JumboGen can be implemented numerous primary reasons for this bottleneck. First, as network speeds issues need to be addressed. These issues include, how to have increased, the common MTU size has not. Second, since determine which packets can be aggregated together, RED the majority of packets transferred over the network are 64 Queue effects on JumboGen packets, release of encapsulated bytes or less in length [1], a larger MTU would not help reduce packets, and partial deployment issues. The remainder of the the number of those types of packets. These two facts have paper is organized as follows: Section II presents an overview caused the number of packets the routers in the network need of the JumboGen approach and presents solutions to important to process to increase substantially. issues, JumboGen packet assembly, RED interactions, schedul- For example, consider a 10 Mb/s network that can handle ing, and deployment. Next, Section III discuses the details N packets every second. If the network is upgraded to 10 Gb/s of the simulation studies performed with JumboGen. Then, the routers would be expected to handle 1000N packets. Since background and related works are discussed in Section IV. 2 B D A 4,5 C 6 7 C D C 4 B A J IP JumboGen B 1,2,3 De-Aggregator A JumboGen Aggregator D Standard Packets JumboGen Packets Standard Packets Fig. 1. JumboGen operation Overview Finally, Section V presents conclusions for the paper. may be difficult to discern. Thus, JumboGen includes mechanisms to ensure that only packets sharing the same II. JUMBOGEN DETAILS egress point will be combined into the same JumboGen packet. Fig. 1 shows an overview of the JumboGen approach. The • Packet Encapsulation: The structure of the JumboGen basic flow of events is described below: packet is such that the method is computationally simplis- 1) Packets arrive at an ingress node to the domain. tic with little overhead. Furthermore, the packet structure 2) At the ingress node, the packets are sorted into queues must be easily modifiable to allow for pruning of ag- based on egress node, while starting a Jumbo Frame gregated packets to support RED-like behavior on a fine Aggregation Timer (JFAT) for the queue. granularity. 3) Packets that are being sent through the same egress point • Structure of Packet Queues: JumboGen incorporates an are combined into the same JumboGen packet, subject efficient and fast method for determination of packet to MTU. placement at the ingress. 4) Once the JFAT for the queue has expired, the JumboGen • RED Interactions: Since JumboGen packets consist of packet is released towards the egress point. many smaller encapsulated packets, the loss of a Jumbo- 5) The JumboGen packet is routed through the core of Gen packet has more significant implications for network the network. Routing is provided by using the standard dynamics. Thus, the JumboGen approach includes con- routing mechanism of the network1. siderations for RED and the interactions with JumboGen 6) The JumboGen packet arrives at the egress node and the and non-JumboGen packets. original packets are separated out. 7) Finally, the original packets are forwarded onto their final destination. A. Aggregation with Shared Egress Points There are two main benefits to this approach. The first is that If packets are randomly aggregated without consideration JumboGen lowers the number of packets that the core routers for their egress points, it is likely that when the JumboGen are responsible for processing, thus allowing the network to packet arrives at an egress node, many of the encapsulated better scale as line speeds increase. The second beneficial packets will be routed back across the domain. This can aspect to the use of JumboGen is that data is more efficiently add a significant amount of delay and is unacceptable from transferred over the network. The increase of efficiency is due a network routing perspective. Hence, in order to aggregate to the reduced number of physical layer headers used (due to packets together at the ingress node, the egress node for the a lower number of packets) to transfer the same amount of packet should be known. data over the network. Unfortunately, in standard IP intra-domain routing (ie. While this process seems relatively simple there are a OSPF, IS-IS) only the next hop is known at any given link number of non-trivial issues that need to be addressed. Issues on the packets path to the destination. However, it is possible that need to be addressed include: to discern which packets will have the same egress point, even if the specific egress point can not be determined. • Aggregation with Shared Egress Points: Since IP based If the network supports MPLS [5], aggregation of packets routing provides only the next hop, the egress point can be performed by matching MPLS labels. Since the same 1Information from the header of an encapsulated packet (MPLS or IP) is MPLS label indicates that packets are in the same Forward simply copied to the actual JumboGen packet Equivalence Class (FEC) and will be routed along the same 3 Packet Queues Filter Addr: 129.154.190 Parent Link: IP Header NULL Filter Addr: Filter Addr: { 129.154.160 129.154.200 QTime Parent Link: Parent Link: NULL NULL avgLen nPkt pLen1 pLen2 Filter Addr: Filter Addr: JumboGen Header 129.154.150 129.154.195 Parent Link: Parent Link: NULL 129.154.160 {pLen(n-1) pLen(n) Packet 1 Fig.
Load more

Recommended publications
  • Redes De Computadores (RCOMP)
    Redes de Computadores (RCOMP) Lecture 03 2019/2020 • Ethernet local area network technologies. • Virtual local area networks (VLAN). • Wireless local area networks. Instituto Superior de Engenharia do Porto – Departamento de Engenharia Informática – Redes de Computadores (RCOMP) – André Moreira 1 ETHERNET Networks – CSMA/CD Ethernet networks (IEEE 802.3 / ISO 8802-3) were originally developed by Xerox in the 70s. Nowadays, ethernet is undoubtedly the most widely used technology in wired LANs. Originally, access control to the medium (MAC - Medium Access Control) was a key issue. The CSMA/CD technique used in ethernet is not ideal, it doesn’t avoid collisions and, as such, results in low efficiency under heavy traffic. The early Ethernet networks were based on a coaxial cable to which all nodes were connected (bus topology), the most important variants were: Thick Ethernet - 10base5 - 10 Mbps / Digital Signal(1) / maximum 500 m bus length Thin Ethernet - 10base2 - 10 Mbps / Digital Signal(1) / maximum 180 m bus length Node Node Node Node Node Node Node Node Node Node (1) base stands for a baseband transmission medium, therefore digital signals must be used. Instituto Superior de Engenharia do Porto – Departamento de Engenharia Informática – Redes de Computadores (RCOMP) – André Moreira 2 ETHERNET networks – Collision Domain CSMA/CD (Carrier Sense Multiple Access with Collision Detection) requires packet collisions to be detected by all nodes before the emission of the packet ends. This introduces limitations on the relationship between the packet’s transmission time and the signal propagation delay. To ensure collision detection by all nodes, there’s minimum packet size of 64 bytes (this sets a minimum transmission time), also there is a maximum segment size (sets the maximum propagation delay).
    [Show full text]
  • MTU and MSS Tutorial
    MTU and MSS Tutorial Dr. E. Garcia, [email protected] Published: November 16, 2009. Last Update: November 16, 2009. © 2009 E. Garcia Abstract – This tutorial covers maximum transmission unit ( MTU ), maximum segment size ( MSS ), PING, NETSTAT, and fragmentation. Expressions relevant to these concepts are systematically derived and explained. Keywords: maximum transmission unit, MTU , maximum segment size, MSS , PING, NETSTAT 1 MTU and MSS As discussed in the IP Packet Fragmentation Tutorial (http://www.miislita.com/internet-engineering/ip-packet-fragmentation-tutorial.pdf ) and elsewhere (1 - 3), the data payload ( DP ) of an IP packet is defined as the packet length ( PL ) minus the length of its IP header ( IPHL ), (Eq 1) whereܦܲ theൌ maximum ܲܮ െ ܫܲܪܮ PL is defined as the Maximum Transmission Unit (MTU) . This is the largest IP packet that can be transmitted without further fragmentation. Thus, when PL = MTU (Eq 2) However,ܦܲ ൌ an ܯܷܶ IP packet െ ܫܲܪܮ encapsulates a TCP packet such that DP = TCPHL + MSS (Eq 3) where TCPHL is the length of the TCP header and MSS is the data payload of the TCP packet, also known as the Maximum Segment Size (MSS) . Combining Equations 2 and 3 leads to MSS = MTU – IPHL – TCPHL (Eq 4) Figure 1 illustrates the connection between MTU and MSS –for an IP packet decomposed into three fragments. Figure 1. Fragmentation example where MTU = PL = pl 1 = pl 2 > pl 3 and DP = dp 1 + dp 2 + dp 3 = PL – IPHL . © 2009 E. Garcia 1 Typically, IP and TCP headers are 20 bytes long. Thus, MSS = MTU – 40 (Eq 5) If IP or TCP options are specified, the MSS is further reduced by the number of bytes taken up by the options (OP), each of which may be one byte or several bytes in size.
    [Show full text]
  • Iethernet W5500 Datasheet Kr
    W5500 Datasheet Version 1.0.6 http://www.wiznet.co.kr © Copyright 2013 WIZnet Co., Ltd. All rights reserved. W5500 The W5500 chip is a Hardwired TCP/IP embedded Ethernet controller that provides easier Internet connection to embedded systems. W5500 enables users to have the Internet connectivity in their applications just by using the single chip in which TCP/IP stack, 10/100 Ethernet MAC and PHY embedded. WIZnet‘s Hardwired TCP/IP is the market-proven technology that supports TCP, UDP, IPv4, ICMP, ARP, IGMP, and PPPoE protocols. W5500 embeds the 32Kbyte internal memory buffer for the Ethernet packet processing. If you use W5500, you can implement the Ethernet application just by adding the simple socket program. It’s faster and easier way rather than using any other Embedded Ethernet solution. Users can use 8 independent hardware sockets simultaneously. SPI (Serial Peripheral Interface) is provided for easy integration with the external MCU. The W5500’s SPI supports 80 MHz speed and new efficient SPI protocol for the high speed network communication. In order to reduce power consumption of the system, W5500 provides WOL (Wake on LAN) and power down mode. Features - Supports Hardwired TCP/IP Protocols : TCP, UDP, ICMP, IPv4, ARP, IGMP, PPPoE - Supports 8 independent sockets simultaneously - Supports Power down mode - Supports Wake on LAN over UDP - Supports High Speed Serial Peripheral Interface(SPI MODE 0, 3) - Internal 32Kbytes Memory for TX/RX Buffers - 10BaseT/100BaseTX Ethernet PHY embedded - Supports Auto Negotiation (Full and half duplex, 10 and 100-based ) - Not supports IP Fragmentation - 3.3V operation with 5V I/O signal tolerance - LED outputs (Full/Half duplex, Link, Speed, Active) - 48 Pin LQFP Lead-Free Package (7x7mm, 0.5mm pitch) 2 / 68 W5500 Datasheet Version1.0.6 (DEC 2014) Target Applications W5500 is suitable for the following embedded applications: - Home Network Devices: Set-Top Boxes, PVRs, Digital Media Adapters - Serial-to-Ethernet: Access Controls, LED displays, Wireless AP relays, etc.
    [Show full text]
  • Automotive Ethernet: the Definitive Guide
    Automotive Ethernet: The Definitive Guide Charles M. Kozierok Colt Correa Robert B. Boatright Jeffrey Quesnelle Illustrated by Charles M. Kozierok, Betsy Timmer, Matt Holden, Colt Correa & Kyle Irving Cover by Betsy Timmer Designed by Matt Holden Automotive Ethernet: The Definitive Guide. Copyright © 2014 Intrepid Control Systems. All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and publisher. Printed in the USA. ISBN-10: 0-9905388-0-X ISBN-13: 978-0-9905388-0-6 For information on distribution or bulk sales, contact Intrepid Control Systems at (586) 731-7950. You can purchase the paperback or electronic version of this book at www.intrepidcs.com or on Amazon. We’d love to hear your feedback about this book—email us at [email protected]. Product and company names mentioned in this book may be the trademarks of their respective owners. Rather than use a trademark symbol with every occurence of a trademarked name, we are using the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The information in this book is distributed on an “As Is” basis, without warranty. While every precaution has been taken in the preparation of this book, neither the authors nor Intrepid Control Systems shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in this book.
    [Show full text]
  • EDSA-401 ISA Security Compliance Institute – Embedded Device Security Assurance – Testing the Robustness of Implementations of Two Common “Ethernet” Protocols
    EDSA-401 ISA Security Compliance Institute – Embedded Device Security Assurance – Testing the robustness of implementations of two common “Ethernet” protocols Version 2.01 September 2010 Copyright © 2009-2010 ASCI – Automation Standards Compliance Institute, All rights reserved EDSA-401-2.01 A. DISCLAIMER ASCI and all related entities, including the International Society of Automation (collectively, “ASCI”)provide all materials, work products and, information (‘SPECIFICATION’) AS IS, WITHOUT WARRANTY AND WITH ALL FAULTS, and hereby disclaim all warranties and conditions, whether express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of reliability or availability, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence, all with regard to the SPECIFICATION, and the provision of or failure to provide support or other services, information, software, and related content through the SPECIFICATION or otherwise arising out of the use of the SPECIFICATION. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION, OR NON- INFRINGEMENT WITH REGARD TO THE SPECIFICATION. WITHOUT LIMITING THE FOREGOING, ASCI DISCLAIMS ALL LIABILITY FOR HARM TO PERSONS OR PROPERTY, AND USERS OF THIS SPECIFICATION ASSUME ALL RISKS OF SUCH HARM. IN ISSUING AND MAKING THE SPECIFICATION AVAILABLE, ASCI IS NOT UNDERTAKING TO RENDER PROFESSIONAL OR OTHER SERVICES FOR OR ON BEHALF OF ANY PERSON OR ENTITY, NOR IS ASCI UNDERTAKING TO PERFORM ANY DUTY OWED BY ANY PERSON OR ENTITY TO SOMEONE ELSE. ANYONE USING THIS SPECIFICATION SHOULD RELY ON HIS OR HER OWN INDEPENDENT JUDGMENT OR, AS APPROPRIATE, SEEK THE ADVICE OF A COMPETENT PROFESSIONAL IN DETERMINING THE EXERCISE OF REASONABLE CARE IN ANY GIVEN CIRCUMSTANCES.
    [Show full text]
  • Practical TCP/IP and Ethernet Networking Titles in the Series
    Practical TCP/IP and Ethernet Networking Titles in the series Practical Cleanrooms: Technologies and Facilities (David Conway) Practical Data Acquisition for Instrumentation and Control Systems (John Park, Steve Mackay) Practical Data Communications for Instrumentation and Control (Steve Mackay, Edwin Wright, John Park) Practical Digital Signal Processing for Engineers and Technicians (Edmund Lai) Practical Electrical Network Automation and Communication Systems (Cobus Strauss) Practical Embedded Controllers (John Park) Practical Fiber Optics (David Bailey, Edwin Wright) Practical Industrial Data Networks: Design, Installation and Troubleshooting (Steve Mackay, Edwin Wright, John Park, Deon Reynders) Practical Industrial Safety, Risk Assessment and Shutdown Systems for Instrumentation and Control (Dave Macdonald) Practical Modern SCADA Protocols: DNP3, 60870.5 and Related Systems (Gordon Clarke, Deon Reynders) Practical Radio Engineering and Telemetry for Industry (David Bailey) Practical SCADA for Industry (David Bailey, Edwin Wright) Practical TCP/IP and Ethernet Networking (Deon Reynders, Edwin Wright) Practical Variable Speed Drives and Power Electronics (Malcolm Barnes) Practical TCP/IP and Ethernet Networking Deon Reynders Pr Eng, BSc BEng, BSc Eng (Elec)(Hons), MBA Edwin Wright MIPENZ, BSc(Hons), BSc(Elec Eng), IDC Technologies, Perth, Australia . Newnes An imprint of Elsevier Linacre House, Jordan Hill, Oxford OX2 8DP 200 Wheeler Road, Burlington, MA 01803 First published 2003 Copyright 2003, IDC Technologies. All rights reserved No part of this publication may be reproduced in any material form (including photocopying or storing in any medium by electronic means and whether or not transiently or incidentally to some other use of this publication) without the written permission of the copyright holder except in accordance with the provisions of the Copyright, Designs and Patents Act 1988 or under the terms of a licence issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London, England W1T 4LP.
    [Show full text]
  • Error Behaviour in Optical Networks Laura Bryony James
    Error Behaviour in Optical Networks Laura Bryony James Corpus Christi College This dissertation is submitted for the degree of Doctor of Philosophy 30th September 2005 Department of Engineering, University of Cambridge This dissertation is my own work and contains nothing which is the outcome of work done in collaboration with others, except as speci¯ed in the text and Acknow- ledgements. Abstract Optical ¯bre communications are now widely used in many applications, including local area computer networks. I postulate that many future optical LANs will be required to operate with limited optical power budgets for a variety of reasons, including increased system complexity and link speed, low cost components and minimal increases in transmit power. Some developers will wish to run links with reduced power budget margins, and the received data in these systems will be more susceptible to errors than has been the case previously. The errors observed in optical systems are investigated using the particular case of Gigabit Ethernet on ¯bre as an example. Gigabit Ethernet is one of three popular optical local area interconnects which use 8B/10B line coding, along with Fibre Channel and In¯niband, and is widely deployed. This line encoding is also used by packet switched optical LANs currently under development. A probabilistic analysis follows the e®ects of a single channel error in a frame, through the line coding scheme and the MAC layer frame error detection mechanisms. Empirical data is used to enhance this original analysis, making it directly relevant to deployed systems. Experiments using Gigabit Ethernet on ¯bre with reduced power levels at the receiver to simulate the e®ect of limited power margins are described.
    [Show full text]
  • Computer Networking Exercises
    Computer Networking Exercises Antonio Carzaniga Faculty of Informatics USI (Università della Svizzera italiana) Edition 2.4 April 2020 1 ◮Exercise 1. Consider a DNS query of type A within a DNS system containing IN class information. Using boxes to represent servers and lines with labels to represent packets, diagram an iterative request for “www.ban.mcyds.net”. The answer must be authoritative. Label any DNS servers you need to contact using a descriptive label. Label every packet with the essential information. For example, a box may be labeled “authority for .com,” while a packet might be labeled “answer, www.ban.mcyds.net, 192.168.23.45” (10’) Consider the same DNS request specified above. Now create a new diagram showing a recursive request. Once again, the answer must be authoritative. (10’) ◮Exercise 2. Given the utility functions listed below, write the pseudo-code to perform an iterative DNS lookup. dns_query_pkt make_dns_packet(type, class, flags) Creates a new DNS query packet. Flags can be combined via the ‘|’ operator. So for a query that is both authoritative and recursive, one would write: (DNS_AUTH | DNS_RECURSE). Only the DNS_AUTH and DNS_RECURSE flags are valid. Type can be A, MX, NS, or any other valid DNS type. value get_dns_answer(dns_answer_packet, n) Return the value in the nth answer of a dns_answer_pkt packet. For example, in re- ply to a MX lookup for inf.unisi.ch, get_dns_answer(pkt,1) would return the SMTP mail server for the inf.unisi.ch domain. In reply to a NS query it would return the authoritative name server. dns_answer_packet send_and_wait(dns_query_packet, server) Send the given dns_query_packet and wait for a replay from the given DNS server.
    [Show full text]
  • Exploring Usable Path MTU in the Internet
    Exploring usable Path MTU in the Internet Ana Custura Gorry Fairhurst Iain Learmonth University of Aberdeen University of Aberdeen University of Aberdeen Abstract—To optimise their transmission, Internet endpoints methodologies and tools [7] [8], providing an up-to-date need to know the largest size of packet they can send across PMTUD behaviour report for both IPv4 and IPv6. a specific Internet path, the Path Maximum Transmission Unit We include an in-depth exploration of server and client (PMTU). This paper explores the PMTU size experienced across the Internet core, wired and mobile edge networks. advertised Maximum Segment Size (MSS), taking advantage Our results show that MSS Clamping has been widely deployed of existing measurement platforms, MONROE [9] and RIPE in edge networks, and some webservers artificially reduce their Atlas [10], and using or extending existing tools Netalyzr [11] advertised MSS, both of which we expect help avoid PMTUD and PATHspider [12]. failure for TCP. The maximum packet size used by a TCP We also look at ICMP quotation health and analyze a connection is also constrained by the acMSS. MSS Clamping was observed in over 20% of edge networks tested. We find a large number of ICMP quotations from a previous large- significant proportion of webservers that advertise a low MSS scale measurement campaign. These results provide important can still be reached with a 1500 byte packet. We also find more insight to inform the design of new methods that can robustly than half of IPv6 webservers do not attempt PMTUD and clamp discover the PMTU for UDP traffic where there are currently the MSS to 1280 bytes.
    [Show full text]
  • Europeancommission—FP7
    European Commission — FP7 Title: Network systems analysis and preliminary development report Work Package: WP2 Version: 1 Date: November 1. 2013 Pages: 30 Project acronym: RITE Author: David Ros Project number: 317700 Work package: Network and interaction Co-Author(s): Iffat Ahmed, Amadou Bagayoko, Anna Brunstrom, Gorry Fairhurst, Carsten Griwodz, David Hayes, Naeem Khademi, Deliverable number and name: Andreas Petlund, Ing-Jyh Tsang, D2.1: Network systems analysis and preliminary devel- Michael Welzl opment report To: Rüdiger Martin Project Officer Status: Confidentiality: [] Draft [ X ] PU — Public [] To be reviewed [] PP — Restricted to other programme participants [] Proposal [] RE — Restricted to a group [ X ] Final / Released to CEC [] CO — Confidential Revision: (Dates, Reviewers, Comments) Contents: Report describing the outcome of the network systems analysis, corresponding to Task 2.1. The most promising avenues for further investigation and prototype development are identified. The report also includes initial results from simulations and prototype developments in Task 2.2 and Task 2.3. Contents RITE: Reducing Internet Transport Latency No. 317700 Abbreviations 1 1 Introduction 3 1.1 Analysis breakdown and document structure ......................... 3 2 Analysis of the causes of delay in broadband access and aggregation networks 4 2.1 Transmission delay due to physical and link layer mechanisms ................ 4 2.1.1 Digital subscriber line (DSL) .............................. 5 2.1.2 Cable ........................................... 6 2.1.3 Fiber ........................................... 7 2.1.4 Wireless .......................................... 7 2.2 Traffic prioritisation and queue management .......................... 8 2.3 Recommendations on network buffering and Active Queue Management .......... 9 3 Interaction of deployed congestion-control algorithms with latency-sensitive flows in network buffers 10 3.1 Multimedia-unfriendly TCP congestion control and home gateway queue management .
    [Show full text]
  • SVSI N2312/N2322 4K Series
    QUICK START GUIDE SVSI N2312/N2322 4K Series Overview Product Specifications The NMX-ENC-N2312 Encoder and NMX-DEC-N2322 Decoder provide a Models Available (in NMX-ENC-N2312 Encoders flexible, feature-rich, and simple-to-deploy Digital Media Distribution and stand-alone or card NMX-DEC-N2322 Decoders Switching solution which satisfies the most demanding 4K applications with versions): resolutions up to 4096x2160. Distribution and switching is over standard Power Requirements: PoE: Can be powered via a PoE switch or other equipment gigabit Ethernet networks. with a PoE source. Conforms to IEEE 802.3af Class 3 (802.3at Type 1). HD signals from the N2312 Encoder are provided as a compressed 200- External power supply: 2.0 Amp @ 12 Volts DC; 100-240 Mbps stream through the RJ-45 or small-form-pluggable (SFP) connector. Volts AC power supply; Part number N9312 (sold separately). Any source can be sent to multiple displays by routing through appropriate Dimensions (HWD): 1.05” x 7.888” x 5.5” (2.67cm x 20.04cm x 14cm) switches. System scalability may be limited by up-link and stacking Weight: 1.55 lbs (0.7kg) connector bandwidths. Standard features like output scaling, bi-directional serial, IR, embedded 7.1 audio, and KVM-over-IP extension are included. The Certifications: FCC, CE, and UL N2312 and N2322 cards are compatible with the N-Series N9206 card cage Environmental: Temperature: 32° to 104°F (0° to 40°C) for high-density applications. Humidity: 10% to 90% RH (non-condensing) Mounting Options: Stand alone, surface mount, wall mount, or rack mount.* One USB Mini-B Port (supported by Encoders) NOTE: *Mounting wings (part number N9101) required for surface and wall mounting.
    [Show full text]
  • Ethernet Theory of Operation
    AN1120 Ethernet Theory of Operation Author: M. Simmons However, with ubiquitous deployment, internet Microchip Technology Inc. connectivity, high data rates and limitless range expansibility, Ethernet can accommodate nearly all wired communications requirements. Potential INTRODUCTION applications include: This document specifies the theory and operation of • Remote sensing and monitoring the Ethernet technology found in PIC® MCUs with • Remote command, control and firmware updating integrated Ethernet and in stand-alone Ethernet • Bulk data transfer controllers. • Live streaming audio, video and media • Public data acquisition (date/time, stock quotes, Ethernet technology contains acronyms and terms news releases, etc.) defined in Table 1. THEORY OF OPERATION APPLICATIONS Ethernet is a data link and physical layer protocol Ethernet is an asynchronous Carrier Sense Multiple defined by the IEEE 802.3™ specification. It comes in Access with Collision Detect (CSMA/CD) many flavors, defined by maximum bit rate, mode of protocol/interface, with a payload size of 46-1500 octets. transmission and physical transmission medium. With data rates of tens to hundreds of megabits/second, it is generally not well suited for low-power applications. • Maximum Bit Rate (Mbits/s): 10, 100, 1000, etc. • Mode of Transmission: Broadband, Baseband • Physical Transmission Medium: Coax, Fiber, UTP, etc. TABLE 1: ETHERNET GLOSSARY Term Definition CRC Cyclic Redundancy Check: Type of checksum algorithm used when computing the FCS for all Ethernet frames and the hash table key for hash table filtering of receive packets. DA Destination Address: The 6-octet destination address field of an Ethernet frame. ESD End-of-Stream Delimiter: In 100 Mb/s operation, the ESD is transmitted after the FCS (during the inter-frame gap) to denote the end of the frame.
    [Show full text]