Re: [tsvwg] Comments on L4S drafts
Dave Taht <dave@taht.net> Fri, 14 June 2019 21:44 UTC
Return-Path: <dave@taht.net>
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 52150120047 for <tsvwg@ietfa.amsl.com>; Fri, 14 Jun 2019 14:44:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 UuqCy_VH0FGN for <tsvwg@ietfa.amsl.com>; Fri, 14 Jun 2019 14:44:48 -0700 (PDT)
Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CFF4120133 for <tsvwg@ietf.org>; Fri, 14 Jun 2019 14:44:48 -0700 (PDT)
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 6A4421F40B; Fri, 14 Jun 2019 21:44:43 +0000 (UTC)
From: Dave Taht <dave@taht.net>
To: Luca Muscariello <muscariello@ieee.org>
Cc: Bob Briscoe <ietf@bobbriscoe.net>, "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <cc446538-cf23-4fd0-12df-7839ec6c04a2@bobbriscoe.net> <CAH8sseSPz3FoLWZNPEJcwb4xQNYk_FXb8VS5ec9oYwocHAHCBg@mail.gmail.com>
Date: Fri, 14 Jun 2019 14:44:31 -0700
In-Reply-To: <CAH8sseSPz3FoLWZNPEJcwb4xQNYk_FXb8VS5ec9oYwocHAHCBg@mail.gmail.com> (Luca Muscariello's message of "Fri, 14 Jun 2019 22:10:03 +0200")
Message-ID: <87sgsbkfk0.fsf@taht.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/6PhXsdM10D8LrRk-32He2z2lyj0>
Subject: Re: [tsvwg] Comments on L4S drafts
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: Fri, 14 Jun 2019 21:44:51 -0000
This thread using unconventional markers for it is hard to follow. Luca Muscariello <muscariello@ieee.org> writes: > On Fri, Jun 7, 2019 at 8:10 PM Bob Briscoe <ietf@bobbriscoe.net> > wrote: > > > > > I'm afraid there are not the same pressures to cause rapid > roll-out at all, cos it's flakey now, jam tomorrow. (Actually > ECN-DualQ-SCE has a much greater problem - complete starvation of > SCE flows - but we'll come on to that in Q4.) Answering that statement is the only reason why I popped up here. more below. > I want to say at this point, that I really appreciate all the > effort you've been putting in, trying to find common ground. I am happy to see this thread happen also, and I do plan to stay out of it. > > In trying to find a compromise, you've taken the fire that is > really aimed at the inadequacy of underlying SCE protocol - for > anything other than FQ. The SCE idea does, indeed work best with FQ, in a world of widely varying congestion control ideas as explored in the recent paper, 50 shades of congestion control: https://arxiv.org/pdf/1903.03852.pdf > If the primary SCE proponents had > attempted to articulate a way to use SCE in a single queue or a > dual queue, as you have, that would have taken my fire. I have no faith in single or dual queues with ECN either, due to how anyone can scribble on the relevant bits, however... > > > But regardless, the queue-building from classic ECN-capable endpoints that > only get 1 congestion signal per RTT is what I understand as the main > downside of the tradeoff if we try to use ECN-capability as the dualq > classifier. Does that match your understanding? > > This is indeed a major concern of mine (not as major as the > starvation of SCE explained under Q4, but we'll come to that). I think I missed a portion of this thread. Starvation is impossible, you are reduced to no less than cwnd 2 (non-bbr), or cwnd 4 (bbr). Your own work points out a general problem with needing sub-packet windows with too many flows that cause excessive marking using CE, which so far as I know remains an unsolved problem. https://arxiv.org/pdf/1904.07598.pdf This is easily demonstrated via experiment, also, and the primary reason why, even with FQ_codel in the field, we generally have turned off ecn support at low bitrates until the first major release of sch_cake. I had an open question outstanding about the 10% figure for converting to drop sch_pie uses that remains unresolved. As for what level of compatability with classic transports in a single queue that is possible with a SCE capable receiver and sender, that remains to be seen. Only the bits have been defined as yet. Two approaches are being tried in public, so far. > > Fine-grained (DCTCP-like) and coarse-grained (Cubic-like) > congestion controls need to be isolated, but I don't see how, > unless their packets are tagged for separate queues. Without a > specific fine/coarse identifier, we're left with having to re-use > other identifiers: > > * You've tried to use ECN vs Not-ECN. But that still lumps two > large incompatible groups (fine ECN and coarse ECN) together. > * The only alternative that would serve this purpose is the flow > identifier at layer-4, because it isolates everything from > everything else. FQ is where SCE started, and that seems to be > as far as it can go. Actually, I was seeking a solution (and had been, for going on 5 years) to the "too many flows not getting out of slow start fast enough", problem, which you can see from any congested airport, public space, small office, or coffeeshop nowadays. The vast majority of traffic there does not consist of long duration high rate flows. Even if you eliminate the wireless retries and rate changes and put in a good fq_codel aqm, the traffic in such a large shared environment is mostly flows lacking a need for congestion control at all (dns, voip, etc), or in slow start, hammering away at ever increasing delays in those environments until the user stops hitting the reload button. Others have different goals and outlooks in this project and I'm not really part of that. I would rather like to see both approaches tried in an environment that had a normal mix of traffic in a shared environment like that. Some good potential solutions include reducing the slower bits of the internet back to IW4 and/or using things like initial spreading, both of which are good ideas and interact well with SCE's more immediate response curve, paced chirping also. > > Should we burn the last unicorn for a capability needed on > "carrier-scale" boxes, but which requires FQ to work? Perhaps yes > if there was no alternative. But there is: L4S. The core of the internet is simply overprovisioned, with fairly short queues. DCTCP itself did not deploy in very many places that I know of. could you define exactly what carrier scale means? > > > > I have a problem to understand why all traffic ends up to be > classified as either Cubic-like or DCTCP-like. > If we know that this is not true today I fail to understand why this > should be the case in the future. > It is also difficult to predict now how applications will change in > the future in terms of the traffic mix they'll generate. > I feel like we'd be moving towards more customized transport services > with less predictable patterns. > > I do not see for instance much discussion about the presence of RTC > traffic and how the dualQ system behaves when the > input traffic does not respond as expected by the 2-types of sources > assumed by dualQ. > > If my application is using simulcast or multi-stream techniques I can > have several video streams in the same link, that, as far as I > understand, > will get significant latency in the classic queue. Unless my app > starts cheating by marking packets to get into the priority queue. > > In both cases, i.e. my RTC app is cheating or not, I do not understand > how the parametrization of the dualQ scheduler > can cope with traffic that behaves in a different way to what is > assumed while tuning parameters. > For instance, in one instantiation of dualQ based on WRR the weights > are set to 1:16. This has to necessarily > change when RTC traffic is present. How? > > Is the assumption that a trusted marker is used as in typical diffserv > deployments > or that a policer identifies and punishes cheating applications? > > BTW I'd love to understand how dualQ is supposed to work under more > general traffic assumptions. > > Luca
- [tsvwg] Comments on L4S drafts Holland, Jake
- Re: [tsvwg] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] Comments on L4S drafts Ingemar Johansson S
- Re: [tsvwg] Comments on L4S drafts Holland, Jake
- Re: [tsvwg] Comments on L4S drafts Holland, Jake
- Re: [tsvwg] Comments on L4S drafts Luca Muscariello
- Re: [tsvwg] Comments on L4S drafts Dave Taht
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] Comments on L4S drafts Ingemar Johansson S
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Ingemar Johansson S
- Re: [tsvwg] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] Comments on L4S drafts Holland, Jake
- Re: [tsvwg] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] Comments on L4S drafts Luca Muscariello
- Re: [tsvwg] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Jonathan Morton
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Jonathan Morton
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Jonathan Morton
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Jonathan Morton
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Luca Muscariello
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Holland, Jake
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] Comments on L4S drafts Holland, Jake
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Holland, Jake
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Gorry Fairhurst
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Wesley Eddy
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Black, David
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Jonathan Morton
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Wesley Eddy
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Scharf, Michael
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Gorry Fairhurst
- [tsvwg] Hackathon tests Dave Taht
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Jonathan Morton
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Black, David
- Re: [tsvwg] New Version Notification for draft-gr… alex.burr@ealdwulf.org.uk
- Re: [tsvwg] New Version Notification for draft-gr… Jonathan Morton
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] New Version Notification for draft-gr… alex.burr@ealdwulf.org.uk
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- Re: [tsvwg] [tcpm] New Version Notification for d… Scharf, Michael
- Re: [tsvwg] [tcpm] New Version Notification for d… Jonathan Morton
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Bless, Roland (TM)
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Pete Heist
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Dave Taht
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] [tcpm] New Version Notification for d… Bob Briscoe
- Re: [tsvwg] [tcpm] New Version Notification for d… Scharf, Michael
- Re: [tsvwg] [tcpm] New Version Notification for d… Black, David
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Bob Briscoe
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Sebastian Moeller
- [tsvwg] [Ecn-sane] Compatibility with singlw queu… Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Comments on L4S drafts Pete Heist
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … Black, David
- [tsvwg] The state of l4s, bbrv2, sce? Dave Taht
- Re: [tsvwg] The state of l4s, bbrv2, sce? Dave Taht
- Re: [tsvwg] The state of l4s, bbrv2, sce? Neal Cardwell
- Re: [tsvwg] The state of l4s, bbrv2, sce? Dave Taht
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … Holland, Jake
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … Black, David
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … Black, David
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … Sebastian Moeller
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … Jonathan Morton
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … Mikael Abrahamsson
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … Mikael Abrahamsson
- Re: [tsvwg] [Ecn-sane] Compatibility with singlw … John Leslie
- Re: [tsvwg] New Version Notification for draft-gr… Rodney W. Grimes
- Re: [tsvwg] New Version Notification for draft-gr… Gorry Fairhurst
- Re: [tsvwg] New Version Notification for draft-gr… Jonathan Morton
- Re: [tsvwg] New Version Notification for draft-gr… Gorry Fairhurst
- Re: [tsvwg] New Version Notification for draft-gr… Sebastian Moeller
- Re: [tsvwg] New Version Notification for draft-gr… Gorry Fairhurst
- Re: [tsvwg] [tcpm] New Version Notification for d… Scharf, Michael
- Re: [tsvwg] New Version Notification for draft-gr… Rodney W. Grimes
- Re: [tsvwg] [tcpm] New Version Notification for d… Loganaden Velvindron
- Re: [tsvwg] [tcpm] New Version Notification for d… Black, David