From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 569E83CB36 for ; Fri, 2 Aug 2019 05:47:10 -0400 (EDT) Received: by mail-wm1-x32b.google.com with SMTP id v19so65754975wmj.5 for ; Fri, 02 Aug 2019 02:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2bNlBJG7BPKPCc0Bkg+mHeGfatut4ewrSZR9mqXgnzo=; b=p6kD7vvAyLaEztIRPRGWhrHu6uH5r1PN4dsPPATlO3oFTvUIdTBj14mWHMR0yPRbQs 91/sNw1p1we9QmXjJjQcE4zi2AwtUvh9FcYGG4gp39RKYR/jf9dDfaFHOP2eJVwB77cd B1gX+1uTIQ2WW8533+yWQ6PIO5UU+eOG0sfOuWR3+ZD5TpAvp1Ld+Pn5PTayhTvV9zdC Ju4vb9j5kGHGrhcqOPl+feomUzauGlPg9vbMpLaQ9Yym57f2nzggZf/OOz69c66Pc2I7 jLXDfszdUGrRdDc4xIdHudCWFge8wH5azv7t2K2oVTKdxXeUcg57ESHluIrh6Kqn2yH6 pUvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2bNlBJG7BPKPCc0Bkg+mHeGfatut4ewrSZR9mqXgnzo=; b=KJ+WYpW6se8MUBpfFhFjS3Clqrnkd87TtbgH0ME4Y2c+sH9IpLD29JOZ/h7VyoCIY4 rSrwqpoyHjdqaWMjUUHK/qTYGfumVEZqmeMS+wjZxsasqoYbWR1GnOb+sC/r9YgIDY/F +/kxqbX55GKOq/YVevMPW2/GG20wSx0mppf/PD/LyvL1bGWYqJjkQhqWCHwa8qJW48jW qRvD4nD3b3SPMMNKPctb2STyZz5FjCRqpr6m56XH3KBqFkhHMXg7FbXsxshazkg7FLTI WW6+LxDl1y3bLnKqOdljY4osBZOjdlraXFhZN8/NCIru7y6CIMDEH9GhJzRLfHXoc/u+ HTiw== X-Gm-Message-State: APjAAAU/rWj5rvhWn03fgMo50FuvfRhGgsMk6tXGtpF1I+C7WL5u0uaY 14zn2UFvh6ZRp29z9MTkcDs= X-Google-Smtp-Source: APXvYqwu4RXOzQ7LFFDoP/0Hcz/SjulHkJmfSX4btD5ZDtIA13+YWjLjHSm5GysXGrCAobunqza+yQ== X-Received: by 2002:a7b:cae9:: with SMTP id t9mr3740479wml.126.1564739229409; Fri, 02 Aug 2019 02:47:09 -0700 (PDT) Received: from [192.168.1.9] (host-2-100-232-204.as13285.net. [2.100.232.204]) by smtp.gmail.com with ESMTPSA id w67sm104132142wma.24.2019.08.02.02.47.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Aug 2019 02:47:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Fri, 2 Aug 2019 10:47:06 +0100 Cc: tcpm@ietf.org, ecn-sane@lists.bufferbloat.net, tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0FD0931A-3035-4F65-BC91-E0267DF6537B@gmail.com> References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> To: Ruediger.Geib@telekom.de X-Mailer: Apple Mail (2.3445.9.1) 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 09:47:10 -0000 > On 2 Aug, 2019, at 9:29 am, = wrote: >=20 > Hi Jonathan, >=20 > could you provide a real world example of links which are = consecutively narrower than sender access links? >=20 > 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 higher LAN access bandwidth, than the campus - Internet = connection (and then there's only one bottleneck again). >=20 > There may be a tradeoff between simplicity and general applicability. = Awareness of that tradeoff is important. To me, simplicity is the design = aim.=20 A progressive narrowing of effective link capacity is very common in = consumer Internet access. Theoretically you can set up a chain of = almost unlimited length of consecutively narrowing bottlenecks, such = that a line-rate burst injected at the wide end will experience queuing = at every intermediate node. In practice you can expect typically three = or more potentially narrowing points: 1: Core to Access network peering. Most responsible ISPs regularly = upgrade 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 responsible ones may experience = short-term congestion here due to exceptional 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 statistical = 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 limit 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 called 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 = consumer last-mile links. I'm being deliberately generic here; it could = be a CMTS 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 subscribers' lines over a common last-mile medium, so there is = still some statistical multiplexing. In the particular case of a cell = tower, the subscriber usually gets less link capacity (due to = propagation conditions) than his tariff limit. 4: CPE bufferbloat mitigation shaper. This is *post-last-mile* ingress = shaping, with AQM and FQ, to reduce the effects of the still-ubiquitous = dumb FIFOs on the above bottlenecks, especially the head-end device. = The IQrouter 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 example, 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 CPE, 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 = certainly possible for all five to apply consecutively. - Jonathan Morton=