[Ecn-sane] mosh ecn bits washed out

[Pete Heist]

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 <pete at heistp.net> 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.
> > > 
> > 
> > 
> 
>