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.
Simon
On 10/8/2015 2:44 AM, Bless, Roland (TM) wrote:
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
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
