On Mon, Sep 02, 2013 at 04:03:01PM -0500, Karl O. Pinc wrote: > Queing input traffic is hard, since it's already got to you through > the bottleneck of your Internet link. > > TCP has to "ramp up", starting slow and getting faster as more acks > show successful receipt. If your link to the net is clogged http > packets will rarely get through which slows up the "slow start" tcp > model. The solution is to throttle your bandwidth _below_ that of > your actual bandwidth. This allows "extra" "default" packets down the > pipe to be accepted while "bulk" packets are dropped, making the bulk > streams slow down and allow room in the pipe for "default" packets.
Hello Karl, Thank you for your reply! I've throttled my up- and download bandwidth. I had tested with various levels of throttling until my pings came back without lag introduced by my ISP's queuing. So I guess I'm good in that department. > At least 2 things complicate this. You're working in MSS packet size > units, so depending on the speed of your link there's definite "steps" > in just how much reserve bandwidth you want to leave in your pipe to > the net. Worse, network equipment has big buffers. This is bad > because it introduces extra latency into the process that slows down > the "bulk" tcp connections. (You can probably find a good series of > blog posts about this via the wikipedia article on bufferbloat.) > > You're probably seeing pauses after startup because your endpoint is > buffering the video stream. The buffer fills, there's no more acks, > the remote end slows down, but then the buffer empties and needs > refilling and your pipe to the net is once again clogged with "bulk" > traffic. You might be able to help this by shrinking the video buffer > at your end. Maybe :) But I'd really love to see how things behave if the bulk traffic actually made it into the correct downstream bucket (1:40). > Meanwhile, you may have an asymmetric connection to the net. With > weeny outbound bandwidth a single "full" IP packet (or series of same) > can hold up "empty" outbound ACK packets -- ACK packets that signal > successful reception of inbound "default" data. Thus, limited > outbound bandwidth throttles inbound bandwidth and interferes with > fast tcp ramp-up. The solution here is to give empty ack packets > highest priority (which won't interrupt a MSS sized outbound packet > that's in-transit over your outbound link, but at least reduces ack > latency). I believe the default configuration already does that. I says "prioritize SYNs and ACKs *if* they're not bulk traffic". At least that's the way I understand the configuration. Kind regards, Sebastian _______________________________________________ openwrt-users mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-users
