| |||||||||||||
Essential, but not the first lineEssential, but not the first linePosted Sep 22, 2011 5:28 UTC (Thu) by cmccabe (guest, #60281)In reply to: Essential, but not the first line by sethml Parent article: LPC: An update on bufferbloat
I don't think short connection = low latency, long connection = high throughput is a good idea.
Due to the 3-way handshake, TCP connections which only transfer a small amount of data have to pay a heavy latency penalty before sending any data at all. It seems pretty silly to ask applications that want low latency to spawn a blizzard of tiny TCP connections, all of which will have to do the 3-way handshake before sending even a single byte. Also, spawning a blizzard of connections tends to short-circuit even the limited amount of fairness that you currently get from TCP.
This problem is one of the reasons why Google designed SDPY. The SPDY web page explains that it was designed "to minimize latency" by "allow[ing] many concurrent HTTP requests to run across a single TCP session."
Routers could do deep packet inspection and try to put packets into a class of service that way. This is a dirty hack, on par with flash drives scanning the disk for the FAT header. Still, we've been stuck with even dirtier hacks in the past, so who knows.
I still feel like the right solution is to have the application set a flag in the header somewhere. The application is the one who knows. Just to take your example, the ssh does know whether the input it's getting is coming from a tty (interactive) or a file that's been catted to it (non-interactive). And scp should probably always be non-interactive. You can't deduce this kind of information at a lower layer, because only the application knows.
I guess there is this thing in TCP called "urgent data" (aka OOB data), but it seems to be kind of a veniform appendix of the TCP standard. Nobody has ever been able to explain to me just what an application might want to do with it that is useful...
(Log in to post comments)
Essential, but not the first line Posted Sep 22, 2011 8:23 UTC (Thu) by kevinm (guest, #69913) [Link]
I have heard of exactly one use for TCP URG data - a terminal emulator sending a BREAK to a remote system immediately after the user types it, allowing it to jump other keystrokes that may be still on their way.
Essential, but not the first line Posted Sep 22, 2011 17:20 UTC (Thu) by nix (subscriber, #2304) [Link] I still feel like the right solution is to have the application set a flag in the header somewhere. The application is the one who knows. Just to take your example, the ssh does know whether the input it's getting is coming from a tty (interactive) or a file that's been catted to it (non-interactive). And scp should probably always be non-interactive. You can't deduce this kind of information at a lower layer, because only the application knows.And SSH can do just this: if DISPLAY is unset and SSH is running without a terminal, it sets the QoS bits for a bulk transfer: otherwise, it sets them for an interactive transfer. Unfortunately scp doesn't unset DISPLAY, so if you run scp from inside an X session I suspect it always gets incorrectly marked as interactive... but that's a small thing.
Essential, but not the first line Posted Sep 23, 2011 6:44 UTC (Fri) by salimma (subscriber, #34460) [Link]
Can't you do "DISPLAY= scp ..." ?
Essential, but not the first line Posted Sep 23, 2011 10:57 UTC (Fri) by nix (subscriber, #2304) [Link]
Yes, but my point is that you shouldn't have to. scp should pass in "-o IPQoS throughput" by default. (Speaking as someone who, er, hasn't written the patch to make it do so.)
Essential, but not the first line Posted Sep 23, 2011 0:52 UTC (Fri) by njs (guest, #40338) [Link]
> I don't think short connection = low latency, long connection = high throughput is a good idea.
I don't think anyone does? (I've had plenty of multi-day ssh connections; they were very low throughput...)
I think the idea is that if some connection is using *less* than its fair share of the available bandwidth, then it's reasonable to give it priority latency-wise. If it could have sent a packet 100 ms again without being throttled, but chose not to -- then it's pretty reasonable to let the packet it sends now jump ahead of all the other packets that have arrived in the last 100 ms; it'll end up at the same place as it would have if the flow were more aggressive. So it should work okay, and naturally gives latency priority to at least some of the connections that need it more.
Essential, but not the first line Posted Sep 23, 2011 9:39 UTC (Fri) by cmccabe (guest, #60281) [Link]
Penalizing high bandwidth users is kind of an interesting heuristic. It's definitely better than penalizing long connections, at least!
However, I think you're assuming that all the clients are the same. This is definitely not be the case in real life. Also, not all applications that need low latency are low bandwidth. For example video chat can suck up quite a bit of bandwith.
Just to take one example. If I'm the cable company, I might have some customers with a 1.5 MBit/s download and others with 6.0 MBit/s. Assuming that they all go into one big router at some point, the 6.0 MBit/s guys will obviously be using more than their "fair share" of the uplink from this box. Maybe I can be super clever and account for this, but what about the next router in the chain? It may not even be owned by my cable company, so it's not going to know the exact reason why some connections are using more bandwidth than others.
Maybe there's something I'm not seeing, but this still seems problematic...
Essential, but not the first line Posted Sep 24, 2011 1:30 UTC (Sat) by njs (guest, #40338) [Link]
Well, that's why we call it a heuristic :-) It can be helpful even if it's not perfect. A really tough case is flows that can scale their bandwidth requirements but value latency over throughput -- for something like VNC or live video you'd really like to use all the bandwidth you can get, but latency is more important. (I maintain a program like this, bufferbloat kicks its butt :-(.) These should just go ahead and set explicit QoS bits.
Obviously the first goal should be to minimize latency in general, though.
|
|||||||||||||