From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 21FC13CB35 for ; Tue, 2 Apr 2019 09:33:21 -0400 (EDT) Received: by mail-pl1-x631.google.com with SMTP id w23so3345928ply.4 for ; Tue, 02 Apr 2019 06:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mounce.com.au; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8BPhg7cYLVdE9KUxn/SxmbmZPI6/VHZ9jOmTcza68yg=; b=A4A+CJdx9IWk3SffH/XYVgIsOcGNOGraEHC2LOsgNRJSGyippxqkSE+Zx4jyuHLwaZ cNP6INstNq8T2MPlFxi+No7hiwGe6+lxDTin/TxVCSUY0LPywaE0FsfiBZUGWHMDdlB3 uDzT9gnWuL1mGRMtuhZyYH54dfdS7kyqO+bWUaJKOTnQ67hbpryC3BgoERvcoWC/lSsr Ke/KWbFsjNBPHrdAD7np33sn7hT6lNGGAgg0Cr7BrV6QJh3cmMvXUarixqfZb3iHhvLN jjThNytjjzdTeFJ22EBT9OkzMu+4bircn1RL7dC25GxeuhdhwW4hAB0Gh3dWVbkT+C1q yJTQ== 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; bh=8BPhg7cYLVdE9KUxn/SxmbmZPI6/VHZ9jOmTcza68yg=; b=gCoN2qpZBK7ZGqiR1IyoB1JkdD6nr9cARhlpB4WnydKpgT8/H8BHXHCBA2iC7BKARp 4IF8kFITbxkolMJE6lv1pWuYx0y9ie78setYKMICXFBW6D0ctzac6t1JpL1fiBCknMsc ZOKUUAhaRvJWvIw9sii0kd9BgEh8ko22LgBWDqJJwkETKytV/VKWwKVad4oGuMEATGeg Gg4R1iVm5saHkBBYrLUVg7CdfoHSG03I6fhSO+L0L0xDVOy0ODeahgwGwknwU0sV41vA ygaRoZ7324H+7LVyt1OmE/LKNHFSDOEMGin640QGRGHF9AwfyI/rEZ4Zd2RXDQbUq6Ou fdoQ== X-Gm-Message-State: APjAAAVW92ZaYTmhdSwtAF+uLbF+/8A7JM9YVBqfFLIcC50ZWeznKHbY iN+ZmVBMHkamSEakJCke1Tdu0/C3KSEXqiS1MRDi4WBqDanaGg== X-Google-Smtp-Source: APXvYqy48XoD31086ZDgEPNLohyUctD9B9WcghWbvchhVJgPTQE0BcG/5vlPlRG59iGQsQwvtNj2bjmdvteM4qWmrEc= X-Received: by 2002:a17:902:a506:: with SMTP id s6mr45819851plq.164.1554212000016; Tue, 02 Apr 2019 06:33:20 -0700 (PDT) MIME-Version: 1.0 References: <47CA8CDA-3060-40C2-AC0A-04899F08C9DE@gmx.de> In-Reply-To: From: Ryan Mounce Date: Wed, 3 Apr 2019 00:03:08 +1030 Message-ID: To: Mikael Abrahamsson Cc: Sebastian Moeller , Jonathan Foulkes , bloat Content-Type: text/plain; charset="UTF-8" Subject: Re: [Bloat] number of home routers with ingress AQM X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 13:33:21 -0000 On Tue, 2 Apr 2019 at 23:35, Mikael Abrahamsson wrote: > > I've read rumours about some ISPs implementing interaction with the VDSL > DSLAM where there is an estimation of the current link-speed for each > individual customer and then it tries to set the BNG egress shaper > appropriately. NBN here in Australia do this for their wholesale FTTN/B VDSL2 product, injecting the downstream and upstream sync speed into PPPoE/DHCP requests. This still depends on the retail service providers to make use of these attributes from their BNG to configure the shaper. > > I am very happy about my FTTH solution I have now since from what I can > see the L2 network is almost never a limiting factor (much better than my > DOCSIS connection) so my bidirectional SQM with CAKE seems to work very > well. > > Still, the HGW can never solve these problems properly, the egress shaping > in the BNG needs to do a proper job. From what I have been told, there has > been improvements here in the past few years. > > What I am more worried about is the egress shaping from the HGW. I talked > to several vendors at BBF and they talked about ingress policing being > commonly used on the BNG. This means no ingress shaping at all (just > packet drops if they exceed the configured rate). I don't know about > buffering on the HGW though and how the policed rate is set compared to > the L2 rate the HGW can send via. NBN is an example again. Their documented behaviour is to police traffic in both directions. Most ISPs then shape in the downstream - and it's up to a tightly managed (TR-069 ?) ISP HGW or a diligent end user to shape traffic in the upstream. Many - probably even most users have no shaping whatsoever in the upstream, only a policer. And then there is their new FTTdp product, where it is not currently possible to determine the real VDSL2 sync speed. If there's a drop of rain it will resync at a lower speed in the upstream, and then everything ends up queuing inside the supplied modem...