On Sat, Nov 23, 2013 at 1:52 AM, Catalin Patulea <[email protected]> wrote: > I noticed that dropbear sets IPTOS_LOWDELAY on all sockets: > https://secure.ucc.asn.au/hg/dropbear/file/14342451d3df/dbutil.c#l190 > > This is great for interactive sessions, but not ideal for bulk > transfer sessions like scp or sftp. Many networks ignore the TOS byte, > but on my local network I respect it because I trust my devices and > wish to prioritize some of them (SIP phone). > > The problem that I ran into was that an sftp upload slowed all the > rest of my Internet traffic to a crawl because it was prioritized. > Ideally I would like dropbear to not set that TOS byte for bulk > transfers.
See "Bufferbloat". > The definition of "bulk transfer" seems a bit hard to pin down. Would > any "subsystem" request cause the connection to be considered bulk? > That covers sftp but what about scp. Would bulk sessions also disable > TCP_NODELAY? What about sshfs mounts (sftp subsystem) where file > operations may happen as a result of interactive user actions (low > latency is desirable)? > > Is this the right place to solve this problem? Should I be fixing this > at the network layer in some way? Few bottleneck gateways (without a shaper in place that respects classification), do anything about the TOS bits. Certainly signalling "intent" when doing a bulk transfer via ssh would be nice. Other ways to optimize stuff at the gateway can be had by (for example) enabling cerowrt, openwrt, dd-wrt or gargoyle's qos/aqm systems, which try to provide a level of fairness between flows (and also respect classification in some cases). If you have a linux box of any sort at the gateway, the same source code applies... While obsolete (don't use it!) , wondershaper was the root of all these systems a decade ago, and is a lot easier to study and understand than these successors. -- Dave Täht
