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 41A813B29E for ; Fri, 19 Mar 2021 11:27:11 -0400 (EDT) Received: by mail-io1-xd30.google.com with SMTP id b10so6486669iot.4 for ; Fri, 19 Mar 2021 08:27:11 -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=tgXbTWXCZmAkwLaQy5xRhG46x28yodm5LxK9nPEmHV4=; b=ngBB9+6j8MBR8ZYveiy+TIMqFEQeeFBJ/O0jnPmliEROgQ69jSa1mqL+oxh1aOKhan IjLR9MaZ1qHxoQvuGt6RSMmkUQgZ+FS0oF9c7R3K7gg2bl/3u+V0yYN/326CCJa2vCIV 28BrQ7rokaOeG7cCXDP0h35DuP5SOquUX8CYCOxD7tU3BJWBZCelwmRJpb6UZ+oiQ3QB uoc/W42+0gQiccYS9t3vQHtZqigzNuYPJ69O/5A5mh1w7lCvaoG+ASqWJBJJh/UHvNVU l0iog2Hpjg2fTZY0KhEnBXmzyoM2FiUtUMQldUfFxmclEg8h+ruJ1o3JBgMwZ6vmA0Oi +nug== 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=tgXbTWXCZmAkwLaQy5xRhG46x28yodm5LxK9nPEmHV4=; b=mXZyhKIt+a6AEU4VZPKAhbNm0/inN3s96oIGSXcl2DwRVTweOpoblQGpldLg2pvh1r Gwvy+AtJhieOTJWGV3Kgrd3QJhGiVc1SKFhZPCPgMYaZjEjD+DWpFrsCOouKC9bkM/P/ D6vzaDeSBAlny5DuVbBsJZeSZ50YzWMa5H3M6UTs3nQ2eWzRqzPSPhGC+GA55UDEHjBs R8N2E0zGg35YOzbyioDPkv5L9a+L1LSplwj34rXZjWDPvBCUIgG4Q3dxalvyldqfRdvu 6WBrdEg2Jj1e8/EbNq9ix39hdNENFTe60cZQT0nXCdbm+ks4oUpVDJKUPWbxnsgOOJsL Cwcg== X-Gm-Message-State: AOAM530MjUCgUp7VLZcnOI0EVKvWBCeQxgOb4EoZyGUx3T6bQkHxNvg6 n2PUObOFeEVmFQYsJb5HjeV89ANPKpeGRGhoh18= X-Google-Smtp-Source: ABdhPJzk987VvwH10fd/k2CJ03/kmNwq5UoJJIn0q2k8iUwt0RjV1yz1aHjZ9C2/6kDltBwBM1D1SiVN23yOihT3/io= X-Received: by 2002:a6b:6618:: with SMTP id a24mr3274441ioc.100.1616167630687; Fri, 19 Mar 2021 08:27:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Fri, 19 Mar 2021 08:26:58 -0700 Message-ID: To: Pete Heist Cc: ECN-Sane Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecn-sane] mosh ecn bits washed out 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: Fri, 19 Mar 2021 15:27:11 -0000 Plug: I note that I live and breathe and die in mosh, as it keeps the conne= ction nailed up no matter what happens.... nat timeouts especially. I had never noticed it "just worked" on ipv6 before now. Despite spending a few minutes fiddling with mosh trying to make it set tcl= ass, it didn't work on a modern kernel, (only a few minutes of fiddling tho) and I was kind of amused to find myself documenting it on the internet a decade back. you *can* set the bits any way you want via irtt irtt client -6 --dscp=3D0xff tun.taht.net On Fri, Mar 19, 2021 at 7:59 AM Pete Heist wrote: > > Ah I see, so mosh is a decent way to see if ECT(0) traverses the path > you're using. I haven't used it before, so I assumed TCP. > > SCE would be a piece of cake for this, but with L4S you've got the same > problem as elsewhere, which is that if you set ECT(1), you don't know > which type of CE you're getting back. For an interactive protocol like > this that doesn't seek capacity, bottleneck detection seems impossible. > > On Fri, 2021-03-19 at 07:08 -0700, Dave Taht wrote: > > On Fri, Mar 19, 2021 at 1:25 AM Pete Heist wrote: > > > > > > Meaning, the negotiation succeeds and ECT(0) is set going up, but > > > zeroed on packets by the time they come down? > > > > There has never been any "negotiation" for setting the ect(0) bit in > > mosh. > > It's been set since 2012 on all udp packets. > > > > I reasoned at the time, that since mosh is the tool of desparate > > sysadmins > > everywhere coping with excessive latency and jitter on everything > > (the local > > echo of keystrokes is a godsend), that turning further enabling CE > > would > > help, or, if stuff with that bit set was dropped, be the focus of > > outrage by sysadmins > > everywhere and ecn support quickly reverted. > > > > Nothing went wrong. :) > > > > mosh has an extremely robust response to marks, reducing the rate to > > 2 frames > > per second from as much as 60 fps on receipt of a single CE. Not > > going > > any further is analogous to the "subpacket window" problem ecn > > enabled tcps have, and attempting to > > sustain that low frame rate essential for mosh's operation. > > > > Ironically, since I last bothered to look, mosh gained ipv6 support, > > but the > > parsing of cmsg and the setsockopt for ecn capability were not > > updated for that. > > > > Also ironically, mosh packets were originally marked AF42 but it > > stopped working > > on one of MITs networks, so the dscp setting was removed, but ecn > > kept. > > > > https://github.com/mobile-shell/mosh/blob/master/src/network/network.cc= #L166 > > > > It would be trivial to sce enable mosh. > > > > > > > > The negotiation can also be blocked with iptables --ecn-tcp-remove, > > > which just zeroes out ECE and CWR, preventing negotiation > > > (https://git.netfilter.org/iptables/tree/extensions/libipt_ECN.c), > > > but > > > I doubt that's very commonly done. > > > > > > On Thu, 2021-03-18 at 13:00 -0700, Dave Taht wrote: > > > > mosh, which has long had excellent support for ecn, appears to be > > > > getting the > > > > ecn bit washed out along my path from california to england. > > > > > > > > ecn survives up that way, but not down. > > > > > > > > Just a single data point thus far. > > > > > > > > > > > > > > > > --=20 "For a successful technology, reality must take precedence over public relations, for Mother Nature cannot be fooled" - Richard Feynman dave@taht.net CTO, TekLibre, LLC Tel: 1-831-435-0729