From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 4139A3BA8E; Fri, 15 Mar 2019 11:49:38 -0400 (EDT) Received: by mail-lj1-x230.google.com with SMTP id a17so8372678ljd.4; Fri, 15 Mar 2019 08:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Qcdfc6KtsJQm8Rc4/SR3WCWlKBs2YEIfEcoqzuojq+M=; b=nZeFwlgGdSFIdEzvWKlj3VNj/JkQeXEqSmu3mr6iu0ezOv2HxF1R7W1vtizMbiEORE tflmkK7/EvLVGszcRtXXbTqzMXOi3TBnLyXXV8r8RZxhx6vz8SKMGdjzsyzCxUbtckLi RhR90YRiEWmdC394S24XXc64gGnO7O7rlthyOL0YUMgZCFXJ2qwEHkMZcTJC8T6DKGCB TWyKE3g6/YQJgys4rbqoLCo5iiB8aXwT19Rg897DgiZFdqEodBSANFLwfQW9msrqTu7i N7rXGCmdvCD3TG1pRDu8ScnD3fuud4nG/Sj7b7ECjaGlNY/Dq0HvOxp1GUe5whP3tc4f YUhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Qcdfc6KtsJQm8Rc4/SR3WCWlKBs2YEIfEcoqzuojq+M=; b=thkJ5FEuVFCewFVLkSrO5BKZK9KFDIOWIHe/jViWJ1Y6xfRZD+5lnyv9FU1MGIZ3CR 3xZ6yUrzVv9j5KpsDDj9aTtGfLhqsHbCiy4EJ4bOusobUUouYo59WVRP9uF9Nyr/BqJm b1ABmDJRlkrqxy6+vV2xxGqDr26BgXHekMOiDyThtpTp+y04ynBMEtnlf1GlajBEc4NQ YN0EmSEx0seLdjKo7xUgtQDPRIKz2JZ5tv2GoHHtlFJjDLZwzqFUZuElWEds71+4ncJp leW9nKJNG91Xs9avPpADq9KJFbe9y2y3RmreT0RQJEP/mZ6q84aMxQLt3lIkIukYFstA usTA== X-Gm-Message-State: APjAAAUJtrPYFi/Otq5ppstJUFWuFuncCe+Eoy/5ddwZ2+RV1inx/DNK xG3uuszK+WLCGEvXB0mSFq0= X-Google-Smtp-Source: APXvYqxChqer7y+jjRznKJ2vKOxjg3w1fkX3Yr/YZ0kO/oi25gScuaBRrkW7OkDM4G5d13uxrw07Xg== X-Received: by 2002:a05:651c:114:: with SMTP id a20mr229716ljb.53.1552664977140; Fri, 15 Mar 2019 08:49:37 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-235-46-nat-p.elisa-mobile.fi. [83.245.235.46]) by smtp.gmail.com with ESMTPSA id j8sm485185ljh.58.2019.03.15.08.49.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Mar 2019 08:49:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Fri, 15 Mar 2019 17:49:34 +0200 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , bloat , ecn-sane@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> To: Sebastian Moeller X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Bloat] [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: Fri, 15 Mar 2019 15:49:38 -0000 > On 15 Mar, 2019, at 4:44 pm, Sebastian Moeller = wrote: >=20 > In essence, they do not want to deal with the diffserv mess under the = end-to-end perspective and making it reliable. Yeah, that's pretty much what I thought. Diffserv really does need to = be fixed sometime. >> But Codel-type AQMs don't provide the ideal ECN signal for L4S (and = nor do RED-type AQMs without specific tuning for L4S), and any = single-queue AQM is going to end up with L4S flows outcompeting standard = ones quite seriously. >=20 > Except L$S flows are required to "degrade" to classic congestion = contro once they have proof of not being handled by a l4s aware AQM, = like real packet drops or ECT(0) + CE... That isn't enough, because ECN AQMs as presently specified won't change = ECT(1) to ECT(0) (nor will SCE), and it would require a lot of overload = before dropping actually started. So those signals don't reliably = identify a legacy AQM. > L4S would find uses for SCE, but that still faces the same roll-out = issue... It's not the same roll-out issue, because in an SCE context L4S would = have to be legacy-compatible by default, and only employ the "new" = behaviour when SCE information appears - the reverse of its present = behaviour - which then makes it backwards compatible and incrementally = deployable. The real snag is that DCTCP's setpoint is 2 marks per RTT, which is = different from SCE's specified setpoint of 50% packets marked (unless = the cwnd is down to 4 packets). That'd make it difficult for a straight = port of DCTCP to SCE to achieve full throughput. A sane compromise could be for SCE to be marked in the same way as L4S = marks CE, and a valid interpretation of SCE to follow the 1/n response = of DCTCP. That would leverage existing TCP-Prague R&D, but in a = backwards-compatible, incrementally-deployable manner. Perhaps that's = something worth discussing at IETF? - Jonathan Morton