Re: [aqm] ACK Suppression

["Bless, Roland (TM)" <[e-mail]>]

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 [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