From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DE03E3B29E for ; Fri, 2 Aug 2019 07:10:24 -0400 (EDT) Received: by mail-io1-xd34.google.com with SMTP id z3so10151314iog.0 for ; Fri, 02 Aug 2019 04:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pVJGExsKLlIOof1pxpFUuxa1/KESzXQPi99nbi+PJoo=; b=hf1kwvGn4qv1rBZrN1oFMNPLKeVZ/v1Yu7YV1IsuVP0nzZuDVxU8HC/xlTojv++tbC YV8FgiGK4Vib7Wwe9tAWf5W4xoekOSeH02hdEIccs3tMTbWnF8Gg3rB/Ep2Uz+NrjHHm KXDo5pKH2TlAhTmEkonQoLJj5luniWTEr4Tb9EGiVBEUFiLb6gsi3o6jPx/DxkhOO+T5 OzgF2iN2sKIc/ccs883xaL43ySLg9ot2Fsz84InNNgG6Tc6NFhkPYW/C57IBBjTOgvzY lid5rp1TQ8qIQt/cIJg35HLSwG+Fd0IuIi3ufKgL0Z8OzzgngOTihNHDVfQRZ7PnEQdu 514w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pVJGExsKLlIOof1pxpFUuxa1/KESzXQPi99nbi+PJoo=; b=oUdhTl13NBZPiodBWXVQK/nspVBWmf9TiX/hNZfW+q1HkNrzMRPnqwRf290u93OyCN Jt86lTqsjqbWHzPTUpjkCF/YTDe9jYRuKbftyJzs4YvtS4q7O9+br2gC8MMw/mqajhJl mdVQ9e5nwXVFJaZTBBXHqi8x+aLvM/LYISD6uzMoPC0BbUJ3HzAnF0K1h+sFk+Tas7qa 0dO9M70+D2JnEmHUa2tiHcujhoijOVeS9fiKbCBjC9MYlaXBtcZLVRWv+YDWQeP02tQa NRoXWk5mGUxAFQJto2xT9FJkllJjYGJT74K79JAS1LbR8RoQnm+FZs/7lbfRo+t4W6Bs 91tA== X-Gm-Message-State: APjAAAVIFXIRCKO3D6wL4i+E+OXMROZikg23biE+uO0vGVmidmEGO7B5 IDeyEPkPSzKHOJ2jJ8oggnFrvh/1MB5IDvLRE7o= X-Google-Smtp-Source: APXvYqwC8Unfs0cpHNUpmeYz3BbReJq3nJ7hrDl8xFxROTHOCDoOYaMJmbwhCSWr1AqvvWuduZOfk1PEpzfDiXM/nNQ= X-Received: by 2002:a5d:9d42:: with SMTP id k2mr11577004iok.45.1564744224165; Fri, 02 Aug 2019 04:10:24 -0700 (PDT) MIME-Version: 1.0 References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <0FD0931A-3035-4F65-BC91-E0267DF6537B@gmail.com> In-Reply-To: <0FD0931A-3035-4F65-BC91-E0267DF6537B@gmail.com> From: Dave Taht Date: Fri, 2 Aug 2019 04:10:11 -0700 Message-ID: To: Jonathan Morton Cc: Ruediger.Geib@telekom.de, tcpm IETF list , ECN-Sane , tsvwg IETF list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 11:10:25 -0000 On Fri, Aug 2, 2019 at 2:47 AM Jonathan Morton wrot= e: > > > On 2 Aug, 2019, at 9:29 am, wrote: > > > > Hi Jonathan, > > > > could you provide a real world example of links which are consecutively= narrower than sender access links? > > > > I could figure out a small campus network which has a bottleneck at the= Internet access and a second one connecting the terminal equipment. But in= a small campus network, the individual terminal could very well have a hig= her LAN access bandwidth, than the campus - Internet connection (and then t= here's only one bottleneck again). > > > > There may be a tradeoff between simplicity and general applicability. A= wareness of that tradeoff is important. To me, simplicity is the design aim= . > > A progressive narrowing of effective link capacity is very common in cons= umer Internet access. Theoretically you can set up a chain of almost unlim= ited length of consecutively narrowing bottlenecks, such that a line-rate b= urst injected at the wide end will experience queuing at every intermediate= node. In practice you can expect typically three or more potentially narr= owing points: 0: Container and vm users are frequently using htb + something to keep their bandwidths under control. 0.5: Cloudy providers use "something" to also rate limit traffic. Policers and shapers, I assume. > 1: Core to Access network peering. Most responsible ISPs regularly upgra= de these links to minimise congestion, subject to cost effectiveness. Some= consumer ISPs however are less responsible, and permit regular congestion = here, often on a daily and/or weekly cycle according to demand. Even the r= esponsible ones may experience short-term congestion here due to exceptiona= l events. Even if the originating server's NIC is slower than the peering = link, queuing may occur here if the link is congested overall due to statis= tical multiplexing. > > 2: Access to Backhaul provisioning shaper. Many ISPs have a provisioning= shaper to handle "poverty tariffs" with deliberately limited capacity. It= may also be used to impose a sanity check on inbound traffic bursts, to li= mit backhaul network traffic to that actually deliverable to the customer (= especially when the backhaul network is itself subcontracted on a gigabytes= -carried basis, as is common in the UK). In the ADSL context it's often ca= lled a BRAS. > > 3: Backhaul to head-end device. Generally the backhaul network is sized = to support many head-end devices, each of which serves some number of consu= mer last-mile links. I'm being deliberately generic here; it could be a CM= TS on a cable network, a DSLAM in a phone exchange, a cell tower, or a long= -range wifi hub. In many cases the head-end device shares several subscrib= ers' lines over a common last-mile medium, so there is still some statistic= al multiplexing. In the particular case of a cell tower, the subscriber us= ually gets less link capacity (due to propagation conditions) than his tari= ff limit. > > 4: CPE bufferbloat mitigation shaper. This is *post-last-mile* ingress s= haping, with AQM and FQ, to reduce the effects of the still-ubiquitous dumb= FIFOs on the above bottlenecks, especially the head-end device. The IQrou= ter is a ready-made CPE device which does this. > > 5: LAN, wifi, or powerline link. Most people now have GigE, but 100base-= TX is still in use in cheaper CPE and some low-end computers, and this will= be a further bottleneck in cases where the last mile is faster. For examp= le, the Raspberry Pi has only just upgraded to GigE in its latest versions,= and used 100base-TX before. Wifi is also a likely bottleneck, especially = if the mobile station is on the opposite side of the house from the base CP= E, and is additionally a "bursty MAC" with heavy aggregation. Some CPE now= runs airtime-fairness and FQ-AQM on wifi to help manage that. > > I think the above collection is not at all exotic. Not all of these will= apply in every case, or at all times in any given case, but it is certainl= y possible for all five to apply consecutively. > > - Jonathan Morton > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740