Hi, Am 13.10.2015 um 05:00 schrieb Simon Barber: > The problem is that many of these link layers are working around > physical limitations, and cannot avoid clumping packets together or > delaying them in some way.
Sure, but that wasn't my main point in the mail below. I can't tell whether alternative link layer access schemes could have led to smaller request slot times, which would have been beneficial for smoother ACK feedback. Not sure whether https://tools.ietf.org/html/rfc3819 is well know to link layer designers... Regards, Roland > On 10/8/2015 2:44 AM, Bless, Roland (TM) wrote: >> Hi David, >> >> Am 07.10.2015 um 21:52 schrieb [email protected]: >>> 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 [email protected] https://www.ietf.org/mailman/listinfo/aqm
