From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 9944A3B29E for ; Fri, 19 Mar 2021 10:59:44 -0400 (EDT) Received: by mail-wr1-x42f.google.com with SMTP id x16so9414094wrn.4 for ; Fri, 19 Mar 2021 07:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heistp.net; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=wLzoHPOJlTPhhOpYbLZgsVNZM4lp9/NM3BFbgUuv0ro=; b=W9xfo9MX2jSPbkFgLljv5AYdFZwIcu/a2yPxvgIgxH9g/XkuCwxOgZu6vqo4BSXwa+ XsFemQrSAV0b/8A2/MgA5PfL2TJxWFGB6yf7nbO8/AgjpG/c/8xvlXkuStOSXNU+k0uw rpmGZJ1JjMCoERBuRpEEzBiSGTP3td9kxlshEUIMF46jiHJ5e4eLB1XxqVs+iJfef9zY dyqyIkcdOJ1WjuLypZZJ9NQYJR1m+yBUde5jO9Q9mTPjeiLWWv4u4CW4SB/v8bLr+wzf uLj30fW0QhEXQnOSTg1/zFUEaOjHRFgsJuBxmoSVBV2FoZ/k0HcNW4tM0ICWoWe53o5i KbYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=wLzoHPOJlTPhhOpYbLZgsVNZM4lp9/NM3BFbgUuv0ro=; b=teTqXvrrlY2ZT2ky2SF7vTHk5mObdYtIRfYKLGJ/VOkeTheXt0yZzDd8cQU4iucWD5 DVWJNPgunbPgffJ+NGZ2+jh1w6Z2Xn1DSsl4s81YkdRmaL7iAUdDyDdBp67jc2XNRY+e cV4BIg+RfY8pn+ScnWvmKJo3GqKHQe45B8W4eG57Re64yL77Ha90KFka2V/8ZttYvuy5 gxC7UCeXE8nriOeub713DJcz4C+VyU3+LFKRe+w6fGaXCcoxZUqK6TgA9CAbWdTyVF+g UBEf2aYfWD6/SIIW336SH1jm5QrjILTtIVTLja56858QTeM16PmCMh6+4wNAp5ymS/zj GgzA== X-Gm-Message-State: AOAM532UCdPA/B+TT1zU/gUNROfzmiK3/bnjHA2F6eFfcL6xRU5+0z5W BExoKAXIY3DVS6ZUxqjY3ZIhlA== X-Google-Smtp-Source: ABdhPJxUaMsGUQBP5rV0JtypRFgZ5+y6nJve+PtyN4lZK0pvqprW/W9ZSBib99IbQSMIhNiVf/pxSQ== X-Received: by 2002:a5d:4307:: with SMTP id h7mr4891150wrq.227.1616165983605; Fri, 19 Mar 2021 07:59:43 -0700 (PDT) Received: from [10.72.0.88] (h-1169.lbcfree.net. [185.193.85.130]) by smtp.gmail.com with ESMTPSA id s12sm6486538wmj.28.2021.03.19.07.59.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Mar 2021 07:59:43 -0700 (PDT) Message-ID: From: Pete Heist To: Dave Taht Cc: ECN-Sane Date: Fri, 19 Mar 2021 15:59:42 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 14:59:44 -0000 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. > > > > > > > > >