On Wednesday, October 7, 2015 4:18pm, "Mikael Abrahamsson" <swm...@swm.pp.se> said: > On Wed, 7 Oct 2015, dpr...@reed.com wrote: > > > not built up! The purpose of queueing is to absorb bursts that can't be > > anticipated, not to build up congestion in order to have enough data to > > perform a dubious optimization that can best be done at the source of > > traffic in cooperation with the destination. > > There is no congestion when the ACK suppression kicks in and is useful. > We may be defining congestion *differently*. If a backlog of packets from one endpoint to another builds up in an outbound queue, that is congestion. That it might be caused by scheduling the "channel" is not relevant, really - at least in my definition of congestion. So let's look at what TCP can do (or any other end-to-end protocol can do) to avoid such congestion: 1) knowing that the packets will be "hung up" in the middle (which it can observe by noticing that acks do get hung up), it can delay sending acks, since it will make no difference to send a cumulative ack rather than multiple acks. That's assuming that the link in question is the "bottleneck" link on the path. 2) the ideal TCP behavior here would be to bundle packets and to bundle ACKs, given that it can see that the bottleneck link has intermittent traffic openings with long gaps between open packet slots. Let's look at what the MAC layer of the shared link can do: 1) It can bundle IP packets being sent from a station (from an arbitrary number of sources) into a cumulative bundle (concatenating them). This is far more general than ACK consolidation, and covers protocols that have small packets, no ACKs at all, etc. Obviously this is dependent on the specific MAC protocol, and the MAC protocol should maintain some degree of "fair sharing", because in essence there is one queue waiting for airtime, it is just distributed across many transmitters. Thus the amount of bundling needs to be bounded. Since arbitration time for channel access is wasted, the critical parameter is the arbitration overhead, as a percentage of maximum load - this controls the desired bundle size. 2) to the extent that packets will be bundled, there is a certain degree of compressability of the data. For example, simple adaptive compression algorithms like Lempel-Ziv encoding are protocol independent. If the frequent case is a series of ACKs, for example, Lempel-Ziv encoding the bundle will reduce the air time occupied by the bundle. 3) note that the critical parameter here is the arbitration overhead. For the normal mode of the WiFi MAC, that is huge. The preambles, etc. needed to deal with unequal received signal strength are relative large (multiple microseconds), plus the cost of a collision (due to lack of RTS/CTS usage that limits the cost of a collision). Reducing the arbitration overhead is much more effective than ACK thinning. On the principle of working on the big payoffs first, the idea of ACK thinning just doesn't seem to make sense outside a hypothetical that disallows much more significant improvements that don't require specialization to a particular version of TCP at a specific point in time. In general, if you have a network that is NOT an Internet, which has a fixed set of protocols and a fixed and unchanging workload, of course you can tune every part of the system to that single case and get some benefit. But this is the *Internet* Engineering Task Force. The whole point of the Internet is to enable evolution. That's why it is not a telephone voice network optimized for a 3 KHz voice coded in 8-bit digitized form with globally synchronized clocking. And it doesn't have pre-allocation of fixed bit-rate flows. That's the real engineering challenge. Modularity is your friend when engineering large systems with very broad requirements. Focusing on a very narrow issue, especially one that assumes way too much about what should be allowed and what traffic "must" look like, misses the point.
_______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
