Re: [aqm] ACK Suppression

[Simon Barber <[e-mail]>]

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 [e-mail]:
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm