Re: [tsvwg] sce vs l4s comparison plots?

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

Return-Path: <toke@toke.dk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E9112025D; Tue, 12 Nov 2019 03:19:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AIeiKS07r25; Tue, 12 Nov 2019 03:19:56 -0800 (PST)
Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (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?= <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; 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 <dave@taht.net>, "alex.burr\@ealdwulf.org.uk" <alex.burr@ealdwulf.org.uk>
Cc: tcpm@ietf.org, tsvwg IETF list <tsvwg@ietf.org>
In-Reply-To: <87k186z2wr.fsf@taht.net>
References: <742142FB-6233-4048-931B-EE2DD9024454@gmx.de> <87mud4ejl9.fsf@taht.net> <4b67d594-e4fc-92d8-fcdc-8384fcb7286b@tomh.org> <87a7931d1k.fsf@taht.net> <1369738724.1583995.1573472465758@mail.yahoo.com> <87k186z2wr.fsf@taht.net>
Date: Tue, 12 Nov 2019 12:19:52 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <874kz9qr3b.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/-Of3M0JFWfcJXAkzFYk7Vvq_jtE>
Subject: Re: [tsvwg] sce vs l4s comparison plots?
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Nov 2019 11:19:58 -0000

Dave Taht <dave@taht.net> writes:

> "alex.burr@ealdwulf.org.uk" <alex.burr@ealdwulf.org.uk> writes:
>
>> (see below)
>>
>> On Monday, November 11, 2019, 12:19:26 AM GMT, Dave Taht
>> <dave@taht.net> 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).

-Toke