Re: [tsvwg] sce vs l4s comparison plots?

Toke Høiland-Jørgensen <> Tue, 12 November 2019 11:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50E9112025D; Tue, 12 Nov 2019 03:19:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1AIeiKS07r25; Tue, 12 Nov 2019 03:19:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B132120059; Tue, 12 Nov 2019 03:19:56 -0800 (PST)
From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=20161023; t=1573557593; bh=rIkW0NGow1RMiU2lD9HiRohMsSzfvgAsskhmsvwzPZs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=tzd8mNcJGWKQM9+a/8CZqO6fHkPzj/mMA9NBuEMV599mNEX0VAsIJfz7Vhmb6XQ0U x73rI/3M9opqCUgAvJPS66Eiaqa7KRkjq3HfHoqVHenY/+cw1Ikf5+eoNiZ13yP1OR jbbBZEwGgXFzs9UUQnrrWx+Hv/RzpEQeX5/uxhy3NeOwM5LWxdgvOpX3w1sLbQMaVi Lpw2pvaSrM1lI6wr6UAa+mInop+QbjkB3h8VdcMOMsFFSK6UIxVpcn/yKp4Ifbl9xA LT3gpdEPN/aMlKFnV8rt1HQ7UVkEP2aD4qmSv6ovntDI7Tpcb3SZdkrecKtjCl5vLg tAePMke1qk/zw==
To: Dave Taht <>, "alex.burr\" <>
Cc:, tsvwg IETF list <>
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Tue, 12 Nov 2019 12:19:52 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [tsvwg] sce vs l4s comparison plots?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Nov 2019 11:19:58 -0000

Dave Taht <> writes:

> "" <> writes:
>> (see below)
>> On Monday, November 11, 2019, 12:19:26 AM GMT, Dave Taht
>> <> wrote: 
>> Cool. If only the dsl and cable worlds had adopted this! it allows for
>> much smarter handling of packet delivery higher in the stack at the
>> cost
>> of one interrupt's worth of standing queue. Without BQL we wouldn't be
>> scaling linux past 10GigE today.
>> I keep hoping *switches* will start doing bql, also.
>> [AB] at the CO end (ie downstream) my understanding (which may be out
>> of date) 
>> is that DSL ICs usually punt queuing to a switch IC. There's a
>> standard (G999.1) which exists
>> solely to enable this (it provides per-subscriber backpressure over
>> ethernet). So, switches doing
>> BQL is exactly what would be required for dsl to do BQL (in the
>> downstream direction).
> Given that a lot of stuff has moved to a purer software solution,
> slicing, sdn, etc, including switching, I can imagine this would
> move more into software, also - if folk were still producing new
> dsl gear.
> One thing that has always been unclear to me is where
> dsl subscriber software rate limits are enforced.

Generally either by forcing the DSL modem to sync up at a rate no higher
than that which the customer has bought; or (more often these days I
think) on a completely separate box that does shaping (or policing) in
the network.

I've seen small ISPs build such boxes using Linux and HTB - and Jesper
and I have been helping a few doing it right (scaling across CPUs, and
using FQ-CoDel on the leaves).