Hi David, Am 07.10.2015 um 21:52 schrieb dpr...@reed.com: > 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.
+1 > 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. +1 Maybe an incentive for some people to think about alternative link layer access schemes that will be better suited for such kind of Internet traffic. As already pointed out the specific optimization will be useless for newer transport protocols as well as for tunneled or encrypted traffic or advanced TCP features, including ECN feedback. > 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. I think the "discussion" seems to be necessary since Mikael's original question was: >> Now, this kind of mechanism, how should it be treated when it comes >> to AQM? This mechanism is basically done at de-queue, when a number of >> packets are emptied from the queue at one time, which is then allowed to >> fill up again until the next transmit opportunity arises. I really hate it if the IETF tries to work around "broken" (short-sighted, cross-layer optimized, and so on) behavior of middleboxes or other devices. So I don't think that the AQM WG should take into account this particular optimization of specific link layer boxes. Otherwise, we'll make the situation only worse for transport protocol evolution. We've got enough examples for ossification due to non-farseeing implementations of middlebox stuff. It's quite perverted if we start to design mechanisms according to such kind of "special/broken" behavior. Regards, Roland _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
