From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 009893CB3D for ; Sat, 20 Jul 2019 17:03:02 -0400 (EDT) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 9E4FD221EC; Sat, 20 Jul 2019 21:03:00 +0000 (UTC) From: Dave Taht To: Sebastian Moeller Cc: Jonathan Morton , "Black\, David" , "tsvwg\@ietf.org" , "ecn-sane\@lists.bufferbloat.net" , "De Schepper\, Koen \(Nokia - BE\/Antwerp\)" References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <4aff6353-eb0d-b0b8-942d-9c92753f074e@bobbriscoe.net> <1238A446-6E05-4A55-8B3B-878C8F39FC75@gmail.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <87ef2myqzv.fsf@taht.net> <803D9CA8-220E-4F98-9B8E-6CE2916C3100@gmail.com> <0079BC6B-4792-48ED-90D3-D9A69407F316@gmx.de> Date: Sat, 20 Jul 2019 14:02:48 -0700 In-Reply-To: <0079BC6B-4792-48ED-90D3-D9A69407F316@gmx.de> (Sebastian Moeller's message of "Sat, 20 Jul 2019 00:03:57 +0200") Message-ID: <871rykzafb.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Ecn-sane] [tsvwg] Comments on L4S drafts 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: Sat, 20 Jul 2019 21:03:03 -0000 Sebastian Moeller writes: > Hi Jonathan, > > > >> On Jul 19, 2019, at 22:44, Jonathan Morton wrote: >> >>> On 19 Jul, 2019, at 4:06 pm, Black, David wrote: >>> >>> To be clear on what I have in mind: >>> o Unacceptable: All traffic marked with ECT(1) goes into the L4S queue, independent of what DSCP it is marked with. >>> o Acceptable: There's an operator-configurable list of DSCPs >>> that support an L4S service - traffic marked with ECT(1) goes into >>> the L4S queue if and only if that traffic is also marked with a >>> DSCP that is on the operator's DSCPs-for-L4S list. >> >> I take it, in the latter case, that this increases the cases in >> which L4S endpoints would need to detect that they are not receiving >> L4S signals, but RFC-3168 signals. The current lack of such a >> mechanism therefore remains concerning. For comparison, SCE >> inherently retains such a mechanism by putting the RFC-3168 and >> high-fidelity signals on different ECN codepoints. >> >> So I'm pleased to hear that the L4S team will be at the hackathon >> with a demo setup. Hopefully we will be able to obtain comparative >> test results, using the same test scripts as we use on SCE, and also >> insert an RFC-3168 single queue AQM into their network to >> demonstrate what actually happens in that case. I think that the >> results will be illuminating for all concerned. > > What I really would like to see, how L4S endpoints will deal > with post-bottleneck ingress shaping by an RFC3168 -compliant > FQ-AQM. I know the experts here deems this not even a theoretical > concern, but I really really want to see data, that L4S flows will not > crowd out the more reactive RFC3168 flows in that situation. This is > the set-up quite a number of latency sensitive end-users actually use > to "debloat" the internet and it would be nice to have real data > showing that this is not a concern. +10 > > Best Regards > Sebastian > > > >> >> - Jonathan Morton >> _______________________________________________ >> Ecn-sane mailing list >> Ecn-sane@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/ecn-sane