From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 B3BF63CB36 for ; Wed, 20 Mar 2019 17:56:22 -0400 (EDT) Received: by mail-lf1-x12a.google.com with SMTP id u21so3111729lfu.2 for ; Wed, 20 Mar 2019 14:56:22 -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=7xiPj1X7ib8rL4usdV0TAOK3/MC+kRxQBS6myjEajac=; b=W0yOyQK+zKTgkRWS2JgRzGleEK0JKB7tmhinTUMLZJ5b281KUZCSQ1OWCLoG3Hd9Ge iq7qN0duZJLxHzforYd6jXF0vOCIx9fHEfg+r/zagEE4zhuWeOyQG4bY5nPMXrs8pHZa Dz9wgtMFXKQ61nE9V/gYZVXSaag8ToarC4an0KKbYFXY7bLT0/Cstzt09H9849v+8UIu gVjf9GWzC+FH+hEX9EaGdv5ja9Pj8xRAY70jnKEaxJgE8WiaZUtCzYn2MKRS1pk1y7Y7 coZKP6o72zoLFdKnXMWeOfmiD5Og0hoBZNWrbXXgiS5/UR9sP9EfVGdmNWcFwL+8G/sD fdWA== 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=7xiPj1X7ib8rL4usdV0TAOK3/MC+kRxQBS6myjEajac=; b=TriIOFH+XEZKeADyY72zNDxHRlmQ9/fB0wtgH0H0DdYi0vyA3p1BzwPG/zmaebYQ2s 2SlQt+s66vv8IGn292qSzDeA/uPGlJhYTEn2kSluw6zrPU8J0bgdVGgVY84N9P/Dcdo+ StytrHYINFtvPrWUIq0WsH7FOvwFJmDlAHl/I08CtT4oZc+iDNSEEoJXoVRB/tzDa7a8 daMOthNAsyGm4WNtoSlcQ/kWlyuRBHo+/VUjR6YthRchZmzvbDhaq4Gz2J2J1d9Gk4Jb Imk9rxzDD3ctlhx8TXosxF1GdUidAnpMY6G4QU78fdTTQRoZZ/vF1tdp+pQFlMzACT3b otwg== X-Gm-Message-State: APjAAAVHKmUT9AGPC6WYqcKV0yzYjOYy2BxOhcTbeXQlL04dItRkxVoj vmpppcGEFB9FFFIoawfK3lo= X-Google-Smtp-Source: APXvYqxiZcmJcGaUwTfi5R5ddUmOswYNVf4n4tigjrULAWhd8qubXUkhftFS8rD4lEDVES8kadFSpw== X-Received: by 2002:ac2:5595:: with SMTP id v21mr44214lfg.163.1553118981593; Wed, 20 Mar 2019 14:56:21 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-226-9-nat-p.elisa-mobile.fi. [83.245.226.9]) by smtp.gmail.com with ESMTPSA id q3sm582551lff.23.2019.03.20.14.56.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Mar 2019 14:56:20 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: <8F2D0BF5-C983-4CC1-BBEB-FFE264C496E8@cablelabs.com> Date: Wed, 20 Mar 2019 23:56:19 +0200 Cc: "Holland, Jake" , Bob Briscoe , "David P. Reed" , Vint Cerf , tsvwg IETF list , bloat Content-Transfer-Encoding: quoted-printable Message-Id: 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> <1552846034.909628287@apps.rackspace.com> <5458c216-07b9-5b06-a381-326de49b53e0@bobbriscoe.net> <8F2D0BF5-C983-4CC1-BBEB-FFE264C496E8@cablelabs.com> To: Greg White X-Mailer: Apple Mail (2.3445.9.1) 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: Wed, 20 Mar 2019 21:56:23 -0000 > On 20 Mar, 2019, at 11:48 pm, Greg White = wrote: >=20 > the dual queue mechanism is not the only way to support L4S and TCP = Prague. As we=E2=80=99ve mentioned a time or two, an fq_codel system = can also support L4S and TCP Prague. I=E2=80=99m not aware that anyone = has implemented it to test it out yet (because so far most interest has = been on dual-queue), but I think the simplest version is: > =20 > At dequeue: > If packet indicates ECT(1): > If sojourn_time > L4S_threshold: > Set CE*, and forward packet > Else: > Forward packet > Else: > Do all the normal CoDel stuff > =20 > In many cases, all of the packets in a single queue will either all be = ECT(1) or none of them will. But, to handle VPNs (where a mix of ECT(1) = and non-ECT(1) packets could share a queue), I would think that = including the ECN field in the flow hash would keep those packets = separate. =20 > =20 > *a more sophisticated approach would be to mark CE based on a ramp = function between a min_thresh and max_thresh, which could be implemented = as a random draw, or via a counting function The above looks remarkably similar to our proof-of-concept for an SCE = middlebox. Essentially: At dequeue: Do all the normal Codel stuff If packet (still) carries ECT(0): If sojourn_time > SCE_threshold: Set SCE Forward packet And yes, a ramp function between 0 and codel_target would work better. = The above gives us something to test against with minimum hassle. - Jonathan Morton