9 research outputs found

    Dual Queue Coupled AQM: Deployable Very Low Queuing Delay for All

    Full text link
    On the Internet, sub-millisecond queueing delay and capacity-seeking have traditionally been considered mutually exclusive. We introduce a service that offers both: Low Latency Low Loss Scalable throughput (L4S). When tested under a wide range of conditions emulated on a testbed using real residential broadband equipment, queue delay remained both low (median 100--300 μ\mus) and consistent (99th percentile below 2 ms even under highly dynamic workloads), without compromising other metrics (zero congestion loss and close to full utilization). L4S exploits the properties of `Scalable' congestion controls (e.g., DCTCP, TCP Prague). Flows using such congestion control are however very aggressive, which causes a deployment challenge as L4S has to coexist with so-called `Classic' flows (e.g., Reno, CUBIC). This paper introduces an architectural solution: `Dual Queue Coupled Active Queue Management', which enables balance between Scalable and Classic flows. It counterbalances the more aggressive response of Scalable flows with more aggressive marking, without having to inspect flow identifiers. The Dual Queue structure has been implemented as a Linux queuing discipline. It acts like a semi-permeable membrane, isolating the latency of Scalable and `Classic' traffic, but coupling their capacity into a single bandwidth pool. This paper justifies the design and implementation choices, and visualizes a representative selection of hundreds of thousands of experiment runs to test our claims.Comment: Preprint. 17pp, 12 Figs, 60 refs. Submitted to IEEE/ACM Transactions on Networkin

    iRED: A disaggregated P4-AQM fully implemented in programmable data plane hardware

    Full text link
    Routers employ queues to temporarily hold packets when the scheduler cannot immediately process them. Congestion occurs when the arrival rate of packets exceeds the processing capacity, leading to increased queueing delay. Over time, Active Queue Management (AQM) strategies have focused on directly draining packets from queues to alleviate congestion and reduce queuing delay. On Programmable Data Plane (PDP) hardware, AQMs traditionally reside in the Egress pipeline due to the availability of queue delay information there. We argue that this approach wastes the router's resources because the dropped packet has already consumed the entire pipeline of the device. In this work, we propose ingress Random Early Detection (iRED), a more efficient approach that addresses the Egress drop problem. iRED is a disaggregated P4-AQM fully implemented in programmable data plane hardware and also supports Low Latency, Low Loss, and Scalable Throughput (L4S) framework, saving device pipeline resources by dropping packets in the Ingress block. To evaluate iRED, we conducted three experiments using a Tofino2 programmable switch: i) An in-depth analysis of state-of-the-art AQMs on PDP hardware, using 12 different network configurations varying in bandwidth, Round-Trip Time (RTT), and Maximum Transmission Unit (MTU). The results demonstrate that iRED can significantly reduce router resource consumption, with up to a 10x reduction in memory usage, 12x fewer processing cycles, and 8x less power consumption for the same traffic load; ii) A performance evaluation regarding the L4S framework. The results prove that iRED achieves fairness in bandwidth usage for different types of traffic (classic and scalable); iii) A comprehensive analysis of the QoS in a real setup of a DASH) technology. iRED demonstrated up to a 2.34x improvement in FPS and a 4.77x increase in the video player buffer fill.Comment: Preprint (TNSM under review

    Ruuhkan- ja jononhallinta tiedonsiirron alkuvaiheessa

    Get PDF
    Transmission Control Protocol (TCP) has served as the workhorse to transmit Internet traffic for several decades already. Its built-in congestion control mechanism has proved reliable to ensure the stability of the Internet, and congestion control algorithms borrowed from TCP are being applied largely also by other transport protocols. TCP congestion control has two main phases for increasing sending rate. Slow Start is responsible for starting up a flow by seeking the sending rate the flow should use. Congestion Avoidance then takes over to manage the sending rate for flows that last long enough. In addition, the flow is booted up by sending the Initial Window of packets prior to Slow Start. There is a large difference in the magnitude of sending rate increase during Slow Start and Congestion Avoidance. Slow Start increases the sending rate exponentially, whereas with Congestion Avoidance the increase is linear. If congestion is detected, a standard TCP sender reduces the sending rate heavily. It is well known that most of the Internet flows are short. It implies that flow startup is a rather frequent phenomenon.  Also, many traffic types exhibit an ON-OFF pattern with senders remaining idle for varying periods of time. As the flow startup under Slow Start causes exponential sending rate increase, the link load is often subject to exponential load transients that escalate in a few round trips into overload, if not controlled properly. It is true especially near the network edge where traffic aggregation is limited to a few users. Traditionally much of the congestion control research has focused on behavior during Congestion Avoidance and uses large aggregates during testing. To control router load, Active Queue Management (AQM) is recommended. The state-of-the-art AQM algorithms, however, are designed with little attention to Slow Start. This thesis focuses on congestion control and AQM during the flow startup. We explore what effect the Initial Window has to competing latency-sensitive traffic during a flow startup consisting of multiple parallel flows typical to Web traffic and investigate the impact of increasing Initial Window from three to ten TCP segments. We also highlight what the shortcomings are in the state-of-the-art AQM algorithms and formulate the challenges AQM algorithms must address to properly handle flow startup and exponential load transients. These challenges include the horizon problem, RTT (round-trip time) uncertainty and rapidly changing load. None of the existing AQM algorithms are prepared to handle these challenges. Therefore we explore whether an existing AQM algorithm called Random Early Detection (RED) can be altered to control exponential load transients effectively and propose necessary changes to RED. We also propose an entirely new AQM algorithm called Predict. It is the first AQM algorithm designed primarily for handling exponential load transients. Our evaluation shows that because of shortcomings in handling exponential load transients, the state-of-the-art AQM algorithms often respond too slowly or too fast depending on the actual RTT of the traffic. In contrast, the Predict AQM algorithm performs timely congestion indication without compromising throughput or latency unnecessarily, yielding low latency over a large range of RTTs. In addition, the load estimation in Predict is designed to be fully compatible with pacing and the timely congestion indication allows relaxing the large sending rate reduction on congestion detection.Ruuhkanhallinta on yksi keskeisimpiä Internetin sujuvan dataliikenteen turvaavia toimintoja. Ilman toimivaa ruuhkanhallintaa Internet ylikuormittuisi ja tulisi käyttökelvottomaksi. TCP-protokollaa (Transmission Control Protocol) on käytetty siirtämään tietoa Internetissä jo vuosia. Sen sisäänrakennettu ruuhkanhallinta on osoittautunut tehokkaaksi estämään pitkäkestoista verkon ylikuormittumista. TCP:n keskeiset ruuhkanhallinta-algoritmit ovat hidas aloitus (Slow Start) ja ruuhkan välttely (Congestion Avoidance). Hidasta aloitusta käytetään vallitsevan verkkotilanteen salliman lähetysnopeuden selvittämiseen. Kun sopiva lähetysnopeus on saavutettu, TCP siirtyy käyttämään ruuhkan välttely -algoritmia. Hitaan aloituksen ja ruuhkan välttelyn käyttämät algoritmit eroavat merkittävästi toisistaan. Hidas aloitus kasvattaa lähetysnopeutta eksponentiaalisesti, kun taas ruuhkan välttelyn aikana lähetysnopeus kasvaa lineaarisesti. Koska Internetissä yhden tiedonsiirtoyhteyden yli siirrettävä tietomäärä on tyypillisesti vähäinen ja uusien yhteyksien tiheä avaaminen sekä lähetystauot ovat erittäin yleisiä, aiheutuu hitaan aloituksen käyttämisestä usein toistuvia kuormapiikkejä, joiden aikana kuorman kasvu verkossa on eksponentiaalista. Verkon reuna-alueella lähellä käyttäjän laitetta verkon kuorma koostuu tyypillisesti vain yhden tai muutaman käyttäjän liikenteestä, jolloin kuormatason vaihtelu on suurta ja siirtyminen matalasta kuormasta ylikuormaan tapahtuu hitaan aloituksen käyttämisen takia erittäin nopeasti. Standardinmukaisen TCP:n hidas aloitus -algoritmi edellyttää ruuhkasignaalia joltakin verkkopolun liikennettä välittävältä reitittimeltä ennen kuin hidas aloitus lopetetaan ja siirrytään ruuhkan välttely -algoritmin käyttöön. Valtaosa aiemmasta ruuhkanhallintaan kohdistuvasta tietoliikennetutkimuksesta on sivuuttanut hitaan aloituksen ja on keskittynyt huomioimaan pelkästään ruuhkan välttely -algoritmille ominaisen toiminnan. Tämä väitöstyö sen sijaan keskittyy ongelmiin, joita aiheutuu uusien yhteyksien avaamisesta ja hitaan aloituksen käyttämisestä. Tämä väitöstyö osoittaa etteivät reitittimissä toimivat jononhallinta-algoritmit (Active Queue Management), jotka säätelevät ruuhkasignaaleja, yleensä reagoi riittävän nopeasti hitaaseen aloitukseen. Siksi hidas aloitus pääsee kiihdyttämään lähetysnopeutta huomattavasti yli verkkotilanteen mukaisesti määrittyvän sopivan lähetysnopeuden. Tämä ylitys siirtyy yleensä suoraan siirtoviiveeseen kasvattaen sitä, mikä myös osoitetaan tapahtuvan hitaan aloituksen aikana nykyaikaisia jononhallinta-algoritmeja käytettäessä. Toisaalta samat algoritmit voivat reagoida myös liian nopeasti, jos kiertoviive on pitkä, koska monet algoritmit perustuvat oletettuun maksimikiertoviiveeseen (yleensä 100 millisekunttia). Tämä väitöstyö valottaa kuinka jononhallinta-algoritmin on haasteellista selvittää todellinen kuormataso tutkimalla reitittimellä olevaa jonoa. Kyse on eräänlaisesta "horisontista", joka estää näkemästä kuormaa aiheuttavia tietoliikennepaketteja muilta verkkopolun osilta. Myös pidempikestoinen kuormamittaus on haasteellista, koska reitittimellä ei yleensä ole tietoa kuinka pitkää ajanjaksoa tulisi käyttää mittauksessa. Lisäksi hitaan aloituksen aikana nopeasti muuttuva kuormataso johtaa kuormamittaustulosten vanhenemiseen ennenaikaisesti. Jotta ruuhkasignaali voitaisiin lähettää ajoissa, täytyy jononhallinta-algoritmin huomioida kaikki kolme yllämainittua haastetta. Tämän väitöstyön osana suunniteltiin Predict-niminen jononhallinta-algoritmi, joka osaa havaita hitaan aloituksen ja reagoi siihen oikeaan aikaan estäen tehokkaasti hitaasta aloituksesta johtuvan ylikuormituksen ja siitä johtuvat suuret viivepiikit. Näin ollen Predict välttää muille algoritmeille ongelmalliset reagointinopeuden sudenkuopat. Lisäksi työssä selvitettiin kuinka uusien yhteyksien avaamista tulisi hallita, jotta samanaikaisesti mahdollisesti käynnissä olevalle interaktiiviselle tiedonsiirrolle ei aiheuteta ongelmia

    Moving toward the intra-protocol de-ossification of TCP in mobile networks: Start-up and mobility

    Get PDF
    182 p.El uso de las redes móviles de banda ancha ha aumentado significativamente los últimos años y se espera un crecimiento aún mayor con la inclusión de las futuras capacidades 5G. 5G proporcionará unas velocidades de transmisión y reducidos retardos nunca antes vistos. Sin embargo, la posibilidad de alcanzar las mencionadas cuotas está limitada por la gestión y rendimiento de los protocolos de transporte. A este respecto, TCP sigue siendo el protocolo de transporte imperante y sus diferentes algoritmos de control de congestión (CCA) los responsables finales del rendimiento obtenido. Mientras que originalmente los distintos CCAs han sido implementados para hacer frente a diferentes casos de uso en redes fijas, ninguno de los CCAs ha sido diseñado para poder gestionar la variabilidad de throughput y retardos de diferentes condiciones de red redes móviles de una manera fácilmente implantable. Dado que el análisis de TCP sobre redes móviles es complejo debido a los múltiples factores de impacto, nuestro trabajo se centra en dos casos de uso generalizados que resultan significativos en cuanto a afección del rendimiento: movimiento de los usuarios como representación de la característica principal de las redes móviles frente a las redes fijas y el rendimiento de la fase de Start-up de TCP debido a la presencia mayoritaria de flujos cortos en Internet. Diferentes trabajos han sugerido la importancia de una mayor flexibilidad en la capa de transporte, creando servicios de transporte sobre TCP o UDP. Sin embargo, estas propuestas han encontrado limitaciones relativas a las dependencias arquitecturales de los protocolos utilizados como sustrato (p.ej. imposibilidad de cambiar la configuración de la capa de transporte una vez la transmisión a comenzado), experimentando una capa de transporte "osificada". Esta tesis surge como respuesta a fin de abordar la citada limitación y demostrando que existen posibilidades de mejora dentro de la familia de TCP (intra-protocolar), proponiendo un marco para solventar parcialmente la restricción a través de la selección dinámica del CCA más apropiado. Para ello, se evalúan y seleccionan los mayores puntos de impacto en el rendimiento de los casos de uso seleccionados en despliegues de red 4G y en despliegues de baja latencia que emulan las potenciales latencias en las futuras capacidades 5G. Estos puntos de impacto sirven como heurísticas para decidir el CCA más apropiado en el propuesto marco. Por último, se valida la propuesta en entornos de movilidad con dos posibilidades de selección: al comienzo de la transmisión (limitada flexibilidad de la capa de transporte) y dinámicamente durante la transmisión (con una capa de transporte flexible). Se concluye que la propuesta puede acarrear importantes mejoras de rendimiento al seleccionar el CCA más apropiado teniendo en cuenta la situación de red y los requerimientos de la capa de aplicación
    corecore