I presume this is not a serious focus of the AQM group. So maybe I'm wasting my time by writing about this. Nonetheless I am troubled by the very fact of the discussion taking place, for two reasons: 1) TCP ACKs are TCP's business only. It's not a gateway or router's job to get involved in or to understand end-to-end protocols, *even if* the router thinks it knows exactly what the endpoints' goals are. And the router cannot know that for every protocol, not even the many higher level protocols on top of TCP, which use TCP quite differently. The idea that routers can be omniscient, merely by looking at packets and taking the designers' personal prejudices into account, seems ridiculous. TCP endpoints on both ends of a connection can reduce the number of ACKs they send if they want. If ACKs are filling up buffers in intermediate routers, just drop them or mark them to notify that they are contributing to congestion. The endpoints have to slow down something, and they can slow down ACKs by mutual agreement. 2) The hypothetical that there will be a sufficiently long sequence of ACKs for a single end-to-end flow buffered in a single router queue may seem plausible, *until it becomes clear that in the big picture, having so many packets in a queue means that the network is extremely congested by that point*. In other words, in order for this "optimization" to apply, you would have to operate the network at an unacceptable operating point! It's like saying that when a highway has slowed to a crawl, we can load all the cars going to a particular destination onto single "car carrier" to save gas. Far better to insure that queues are 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. It's said that in committees the amount of time spent on trivialities far exceeds the time spent on important issues. That seems to be true as I watch the discussion on this list. There are real congestion problems in the real Internet. Real engineers would be working on solving them with practical solutions that actually work. I see none of that here. It's very, very sad. We still have serious "bufferbloat" in most access networks nationwide, and lots of gear sold by the biggest brand name vendors of both high-speed fiber/copper access and packet wireless data access that is allowing queueing of between 1/2 second to 4 seconds to build up and sustain itself. But this group dithers.
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
