From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 0D63D3B29E for ; Tue, 30 Jul 2019 14:23:36 -0400 (EDT) Received: by mail-io1-xd30.google.com with SMTP id e20so99952079iob.9 for ; Tue, 30 Jul 2019 11:23:36 -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=ntNpo+a4juE9ejYW7xUaVosh6Db6Q2vbFXcN0/qT9hA=; b=nmQMHwYdf8ciI/lIvnkKxdb1TIWY18k25gsny7SyvYH7Lgp4UVwhhHBdX1H21yOyXB qcx2tLYuiBiF6uux9GGar6AK8jPeQTh8qgnUuODwdN5ZJOnJFI2TKgoCpusDjN+nt3PR uxuAJ3YUj01V5+CW2eIcQuZWd+vwjkDdIMoBdDlib9ZcQiseyXcEMIfjxKPm9kTSvi26 jnVbQiSYBQ4+lOyZj2f3rkGHNLJ9OquPrkPs4EyS5B62mV1c09O57GxqVxlWyi/bwOpT CbzWbv/8H5oNB4NLZspWJ6P5OIJp0p+ZkDiRD6qgjTIR0g7IYBmm6vfQ7DyQeEdUxH5G 6NaQ== 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=ntNpo+a4juE9ejYW7xUaVosh6Db6Q2vbFXcN0/qT9hA=; b=ADFZVoNUQACYcT4PeWnD30rmCGTrYy2mvsE4uiJa3RGG+kLAoPzDj718bEFCvu5OSp /5cUCGIWhXwDUwg2ugna1PbwAtwGQbArELxr2FcvYiMY5vJrh67xaTdGL6t78qTIGt/n /Cp+j6go8zKQM0DpJsIM8oGHJys4H4vvOo+lE3Z2GYwQFWEYSXgQi3hobinN8RcFOd/T shHYvTHegtcFhxnKNC+E9eicNOpYWWKDuwOd4zC04428CeLF2i3asUB7cVMvLNWCtW7k Bc0/EaaRw6vec6E1fQOz7Udt6Q4PDLppnA5/J13lVrKSGGQSVS54AkjSnijSgcENQk3o 1r7Q== X-Gm-Message-State: APjAAAWKqFd3ZbFH1FELbSdyABrI7FmbkA+1TQlWyleVwnWhhSdGZl43 96FDDr7+SlDqd9AUGwfBcoNN7hMeAnOHlmYVy5s= X-Google-Smtp-Source: APXvYqzrjWMqUDBery6G90z4K0uf92so2G5XvSD0sQBou+t4D87NgXrv1pvOgE18f63nixdS8kwdhpdJMHs/lZE2Izc= X-Received: by 2002:a6b:790a:: with SMTP id i10mr8286484iop.150.1564511015500; Tue, 30 Jul 2019 11:23:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Tue, 30 Jul 2019 11:23:24 -0700 Message-ID: To: Jonathan Morton Cc: ECN-Sane , Daniel Havey Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecn-sane] simpler solution for ecn + cwnd < 2 than sub-packet windows 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: Tue, 30 Jul 2019 18:23:36 -0000 On Mon, Jul 29, 2019 at 2:22 AM Jonathan Morton wro= te: > > No, the single easiest solution is to reduce the pacing scale factors. T= he packets are still full size, but appear less often, potentially less tha= n one per RTT. Pacing is GREAT, but unlikely to take over the universe all that rapidly. For anything else with ecn on, a fallback to signalling it's ok to drop me under extreme congestion seems helpful, and the further fallbacks that regular tcp has, has have proved sufficient for the internet. If we successfully get away from ect1 as an identifier and instead as a robust set of congestion indicators, senders falling back to 00 is a possibility. And it's simple to implement. I note that it might not just be cwnd 2 but at solid levels of SCE or CE marking. I also like dynamically reducing the MSS to keep the signal strength up for 1 per RTT for as long as possible. I've also suggested on multiple occasions that webrtc use ECN for iframes, but turn it off for deltas. I'm not saying I don't like subpacket windows! But not every packet's sacred, and my position paper laid out some nuances that I need to revise some in light of the enormous progress made on SCE so far. I rather like the SCE-enabled scavanging transport idea, as it's kind of similar to the extreme but useful response to ecn we put into mosh, where we drop the frame rate from its max of 60 to 1 or 2, in response to CE. Mosh is an example of an interactive application where going a step further to protect a packet really helps, but dropping the rate by a large amount, doesn't hurt. (much) https://tools.ietf.org/html/rfc8622 lays out two conflicting goals for a scavenging transport - one that must be low priority and another that must be capable of being silenced for long periods of time. LE + SCE enablement and a fallback to being 00 and thus lossy is a possible way to achieve those goals based on the application's actual intent. The ledbat++ preso in iccrg is also worth watching, btw, lthough I fear they haven't actually read https://perso.telecom-paristech.fr/drossi/paper/rossi14comnet-b.pdf --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740