From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 D59CE3B29E; Sat, 16 Mar 2019 18:03:24 -0400 (EDT) Received: by mail-qk1-x732.google.com with SMTP id m65so11472qkl.11; Sat, 16 Mar 2019 15:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=OdS/MTgmGVwXX/nx8AX1gPgWkBlqzTvckYKgDIqiBNE=; b=OWqkK+6/iVVbGFpJka36pRXI3GEQuJaVrwSXc1hg7iSeVGzaWlUGxzQSjDtOC1WPuq 7J0MrSdEF+xZso1XfoLGbQfuQBc1AAm3xaMP2sDave5PH7ynlWoLKKfuC8jJM1i8N2R4 LLYBTH8424ngcUvWxFxRfKHOp1wCnoBNgQD5Znq3mHeWjdBZzoE86DydNux8cjWIFQn5 pxcj7ggekp0UE7nHqnb/FTYn0LIw5TZnQL5FN1PgGpINEzuKOYd3BQ6n9Biz+NTe3WXs YDQZwGe5H0rcAZgEjdW9HxhRxJmCOVlTCBJvIKfFTyFwPhcvmv11zzPptQWximv6o1xO Jhnw== 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:content-transfer-encoding; bh=OdS/MTgmGVwXX/nx8AX1gPgWkBlqzTvckYKgDIqiBNE=; b=JWy7C/lBUURxRR+lqmq8OcLjetyUjhUOuoPcX2Cw5oOzpgNfSBib6jEbPmXwxaSmji 5SvFbCB99okKE9b66urN9diAkn+37lZT13rWbWZOchqcqa9x1KnZJ4Y1wqcPv/yopvbx XLMsK8BdZDXQB1gz6cf9kRjNOOxc+nPrY6QmfGaOHk+gxaHGRajDV0m+wvT7r74X4L3u WB91i0fJ3vPCqyBjN3QWU26RaLmaZg/5kqRj+6bpja+vtrISE7opf4Zl6cnvvBTSo8FZ K4D7hZw5U6HOqMQZ0vgI0hrHcwKcvCPzJkTr1ypajicxV8bEHZn0uCZiZ/8zeTo4gMq2 +TLw== X-Gm-Message-State: APjAAAVaN7z1zPQLOXsO07ZXjuCiT1TFJ2JYdTQ+wrUUGI4BQ8uoYKCO SnRJtMZKh2KidOXYsdA3xpXmw4G2Q20E5nSaBdFZYwvW X-Google-Smtp-Source: APXvYqz9OlOm/3avdNUZ/rzt5+OmpZ2PME4olu57cOSULYAm7j+0BwUinZS4EApsYb1wnn2ZnXE/uvn9QFxtEFo/biw= X-Received: by 2002:a05:620a:1486:: with SMTP id w6mr6444713qkj.179.1552773804355; Sat, 16 Mar 2019 15:03:24 -0700 (PDT) MIME-Version: 1.0 References: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> <27FA673A-2C4C-4652-943F-33FAA1CF1E83@gmx.de> <1552669283.555112988@apps.rackspace.com> <7029DA80-8B83-4775-8261-A4ADD2CF34C7@akamai.com> In-Reply-To: From: Dave Taht Date: Sat, 16 Mar 2019 15:03:15 -0700 Message-ID: To: Vint Cerf Cc: "Holland, Jake" , bloat , "ecn-sane@lists.bufferbloat.net" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 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: Sat, 16 Mar 2019 22:03:24 -0000 Dear Vint: BBR, along with all "non ect_1 sending L4S compatable" transports, gets relegated to the dualpi "Classic" queue. https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/ On Sat, Mar 16, 2019 at 2:57 PM Vint Cerf wrote: > > where does BBR fit into all this? > > v > > > On Sat, Mar 16, 2019 at 5:39 PM Holland, Jake wrote= : >> >> On 2019-03-15, 11:37, "Mikael Abrahamsson" wrote: >> L4S has a much better possibility of actually getting deployment int= o the >> wider Internet packet-moving equipment than anything being talked ab= out >> here. Same with PIE as opposed to FQ_CODEL. I know it's might not be= as >> good, but it fits better into actual silicon and it's being proposed= by >> people who actually have better channels into the people setting har= d >> requirements. >> >> I suggest you consider joining them instead of opposing them. >> >> >> Hi Mikael, >> >> I agree it makes sense that fq_anything has issues when you're talking >> about the OLT/CMTS/BNG/etc., and I believe it when you tell me PIE >> makes better sense there. >> >> But fq_x makes great sense and provides real value for the uplink in a >> home, small office, coffee shop, etc. (if you run the final rate limit >> on the home side of the access link.) I'm thinking maybe there's a >> disconnect here driven by the different use cases for where AQMs can go. >> >> The thing is, each of these is the most likely congestion point at >> different times, and it's worthwhile for each of them to be able to >> AQM (and mark packets) under congestion. >> >> One of the several things that bothers me with L4S is that I've seen >> precious little concern over interfering with the ability for another >> different AQM in-path to mark packets, and because it changes the >> semantics of CE, you can't have both working at the same time unless >> they both do L4S. >> >> SCE needs a lot of details filled in, but it's so much cleaner that it >> seems to me there's reasonably obvious answers to all (or almost all) of >> those detail questions, and because the semantics are so much cleaner, >> it's much easier to tell it's non-harmful. >> >> >> >> But as you also said so well in another thread, this is important. ("Th= e >> last unicorn", IIRC.) How much does it matter if there's a feature that >> has value today, but only until RACK is widely deployed? If you were >> convinced RACK would roll out everywhere within 3 years and SCE would >> produce better results than L4S over the following 15 years, would that >> change your mind? >> >> It would for me, and that's why I'd like to see SCE explored before >> making a call. I think at its core, it provides the same thing L4S does >> (a high-fidelity explicit congestion signal for the sender), but with >> much cleaner semantics that can be incrementally added to congestion >> controls that people are already using. >> >> Granted, it still remains to be seen whether SCE in practice can match >> the results of L4S, and L4S was here first. But it seems to me L4S come= s >> with some problems that have not yet been examined, and that are nicely >> dodged by a SCE-based approach. >> >> If L4S really is as good as they seem to think, I could imagine getting >> behind it, but I don't think that's proven yet. I'm not certain, but >> all the comparative analyses I remember seeing have been from more or >> less the same team, and I'm not convinced they don't have some >> misaligned incentives of their own. >> >> I understand a lot of work has gone into L4S, but this move to jump it >> from interesting experiment to de-facto standard without a more critical >> review that digs deeper into some of the potential deployment problems >> has me concerned. >> >> If it really does turn out to be good enough to be permanent, I'm not >> opposed to it, but I'm just not convinced that it's non-harmful, and my >> default position is that the cleaner solution is going to be better in >> the long run, if they can do the same job. >> >> It's not that I want it to be a fight, but I do want to end up with the >> best solution we can get. We only have the one internet. >> >> Just my 2c. >> >> -Jake >> >> >> _______________________________________________ >> Ecn-sane mailing list >> Ecn-sane@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/ecn-sane > > > > -- > New postal address: > Google > 1875 Explorer Street, 10th Floor > Reston, VA 20190 > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740