From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 6229F3B29E; Thu, 12 Dec 2019 16:31:19 -0500 (EST) Received: by mail-il1-x134.google.com with SMTP id t9so257902iln.4; Thu, 12 Dec 2019 13:31:19 -0800 (PST) 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=XaeFHjdgT7ENqx5vsK/4WQFTmrQbtBx1DKbr37AOJ5E=; b=g4QQnJ8ID3ncnNdAoS9OX7scm6ZCR8hZdnkhfRsHQmuJedXj1JRUwg3UFPqhJRs3YR j+rzJtJhE7yWnbkIHiuDum34Xe917TzkCMHr8Q0YHElT0LyzoYuFhereoyTPI0JC4JZv ZONFuMwIu0NWfgvrE5dARAPbYknyu6d6wdBs4I9WwluiAoP9ufLlXfMnLD67e1acsdU6 qKLi7es0JBzFD8Zply5tE35GUPHSW3atXvJgjGQtynR6/68DE9aOcU3ftZWxqMD/hPBx 41DhBtMsV5Vr1Ht0ydLuAG3R2I1jmPM+IgYoasNKnnCNAOdm/TpFOkQXjTpM/c+c3x+V e1WQ== 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=XaeFHjdgT7ENqx5vsK/4WQFTmrQbtBx1DKbr37AOJ5E=; b=k3yIWjCY83a5Q00e+YGGwXWSEUCJTxkKBoXWCcki7ug7UvbKvnS6MY7Z28Yy68UfCj OlXJh30zknd2Vvz3uT8X+c0fFAzhRAjCTas4uSBacNHIAhODUNnOFxTXzcvCEA8rHeqe cmBcwc/SDn8SLoOtcxDBp3RG293vkGfkjnR4YYhMBPdb+YB+IkvL8UQzJBz2fuULtMpl MDC2NpgjUyXT9VFmvF65keK3a6QQDCgy+GhFmWwq5siJrRZ8+0+mC59v4Tr6J69BNGmb Ssi6O/sM9nPpBAMfHBRg8C3uJsR4IRiBSIT2Hi7CJW0M8x0vgWTNiX0KA0H7La37pODJ yI3g== X-Gm-Message-State: APjAAAVg+WPzfEAZV5CWh7uyAWxV6NbkSC3VJ7iAaZcRtoG/YPTj8L5F Gb3s70prv8b0iARPgQ0kYET8DwhihxXPeLuqs6s= X-Google-Smtp-Source: APXvYqzCWJnglIuX/zrn51nT5zBsP+5lT/Sw3z+8CLCRhKlDcg+QZ3PE+wVJxsnfkc+SpPwFZsRICDtlryGThUVGLRc= X-Received: by 2002:a92:3d49:: with SMTP id k70mr9908277ila.246.1576186278752; Thu, 12 Dec 2019 13:31:18 -0800 (PST) MIME-Version: 1.0 References: <2CC1F0FF-4447-4860-BFE6-0C4CA3312953@gmail.com> In-Reply-To: <2CC1F0FF-4447-4860-BFE6-0C4CA3312953@gmail.com> From: Dave Taht Date: Thu, 12 Dec 2019 13:31:01 -0800 Message-ID: To: Jonathan Morton Cc: Prateesh Goyal , Hari Balakrishnan , ECN-Sane , Mohammad Alizadeh , bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecn-sane] [Bloat] abc congestion control on time varying wireless links 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: Thu, 12 Dec 2019 21:31:19 -0000 On Wed, Dec 11, 2019 at 12:12 PM Jonathan Morton wr= ote: > > > On 11 Dec, 2019, at 9:54 pm, Dave Taht wrote: > > > > The DC folk want a multibit more immediate signal, for which L4S is > > kind of targetted, (and SCE also > > applies). I haven't seen any data on how well dctcp or SCE -style can > > work on wildly RTT varying links as yet, although it's been pitched at > > the LTE direction, not at wifi. > > It turns out that a Codel marking strategy for SCE, with modified paramet= ers of course, works well for tolerating bursty and aggregating links. The= RED-ramp and step-function strategies do not - and they're equally bad if = the same test scenario is applied to DCTCP or TCP Prague. That matches my preliminary observations. thx. > > The difference is not small; switching from RED to Codel improves goodput= from 1/8th to 80% of nominal link capacity, when a rough model of wifi cha= racteristics is inserted into our usual Internet-path scenario. While I'm the author of the netem slotting code that does this bursty wifi emulation, and delighted you are using it, it would better to additionally use the delay distribution modelling feature added shortly therafter by members of the stadia team. The distributions of wifi delay with just slotting did not resemble the real world enough for my taste after I fiddled with it extensively. There is a very, very long tail. (or conversely: making wifi retry algos match a sane model better would be good - it makes no sense to have 30 dumb retries in the mac layer! mac retries really dominate my pdv data at these vastly lower levels of queuing) I would love it if google were to publish the wifi distribution tables they have developed since then for inclusion in iproute2. > > We're currently exploring how best to set the extra set of Codel paramete= rs involved. One of my thoughts after reading about the abc idea is that there is an underused 4th state, in taking away both ect(1) and ect(0) on a previously marked ect(0) stream as a sign you could accellerate. This would only work if you were the only bottleneck router, of course, and not with tcp as we know it. I really like the idea of paced chirping in genera, as it could better fill a wifi aggregate, and perhaps mitigate some of the exponential overshoot problems in slow start (and this is separate from fiddling with abc or other abc states) > - Jonathan Morton > --=20 Make Music, Not War Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729