TOS byte for bulk transfers

Dave Taht dave.taht at gmail.com
Sun Nov 24 05:26:13 WST 2013


On Sat, Nov 23, 2013 at 1:52 AM, Catalin Patulea <cat at vv.carleton.ca> 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


More information about the Dropbear mailing list