Re: [aqm] TCP ACK Suppression

Simon Barber <> Fri, 09 October 2015 02:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 51EE41B2A81 for <>; Thu, 8 Oct 2015 19:26:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cjp7YVGoTGOZ for <>; Thu, 8 Oct 2015 19:26:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E646C1B2A7D for <>; Thu, 8 Oct 2015 19:26:46 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZkNOM-0007sv-2B for; Fri, 09 Oct 2015 03:26:43 +0100
Message-ID: <>
Date: Thu, 08 Oct 2015 19:26:45 -0700
From: Simon Barber <>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [aqm] TCP ACK Suppression
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Oct 2015 02:26:50 -0000

I like this suggestion - but it's only needed in the case where there 
are dup acks.


On 10/8/2015 7:09 PM, David Collier-Brown wrote:
> One short interjection: send at least two acks, separated by a time 
> based on available packets and/or average noise-burst durations on 
> links with noise problems...
> On 08/10/15 08:04 PM, David Lang wrote:
>> On Thu, 8 Oct 2015, Joe Touch wrote:
>>> On 10/8/2015 3:29 PM, David Lang wrote:
>>>> On Thu, 8 Oct 2015, Joe Touch wrote:
>>>>> On 10/8/2015 2:31 PM, David Lang wrote:
>>>>>> On Thu, 8 Oct 2015, Joe Touch wrote:
>>>>>>> On 10/7/2015 12:42 AM, LAUTENSCHLAEGER, Wolfram (Wolfram) wrote:
>>>>>>> ...
>>>>>>>> Is this topic addressed in some RFC already?
>>>>>>> It's a direct violation of RFC793, which expects one ACK for 
>>>>>>> every two
>>>>>>> segments:
>>>>>>> 4.2 Generating Acknowledgments
>>>>>>>   The delayed ACK algorithm specified in [Bra89] SHOULD be used 
>>>>>>> by a
>>>>>>>   TCP receiver.  When used, a TCP receiver MUST NOT excessively 
>>>>>>> delay
>>>>>>>   acknowledgments.  Specifically, an ACK SHOULD be generated for at
>>>>>>>   least every second full-sized segment, and MUST be generated 
>>>>>>> within
>>>>>>>   500 ms of the arrival of the first unacknowledged packet.
>>>>>> actually, this is only a violation of the SHOULD section, not the 
>>>>>> MUST
>>>>>> section.
>>>>> When you violate a SHOULD, you need to have a good reason that 
>>>>> applies
>>>>> in a limited subset of cases.
>>>>> "it benefits me" isn't one of them, otherwise the SHOULD would 
>>>>> *always*
>>>>> apply.
>>>>>> And if the Ack packets are going to arrive at wire-speed anyway 
>>>>>> (due to
>>>>>> other causes), is there really an advantage to having 32 ack packets
>>>>>> arriving one after the other instead of making it so that the 
>>>>>> first ack
>>>>>> packet (which arrives at the same time) can ack everything?
>>>>> If the first ACK confirms everything, you're giving the endpoint a 
>>>>> false
>>>>> sense of how fast the data was received. This is valid only if the
>>>>> *last* ACK is the only one you retain, but then you'll increase 
>>>>> delay.
>>>> why does it give the server a false sense of how fast the data was
>>>> received? the packets don't have timestamps that the server can trust,
>>>> they are just packets arriving.
>>> Well, the only reason we can no longer trust them is that an
>>> intermediate device has tampered with them.
>> no, you could not trust any timestamps in the packets even if nothing 
>> changes the packets between endpoints.
>>> See, this is the problem - the DOCSIS modem wants to do what *it* 
>>> wants,
>>> assuming everyone else plays by the rules, but it doesn't care whether
>>> it violates the assumptions other parties are making.
>>> That's an example of "tragedy of the commons".
>>>> And if the server concludes something
>>>> different from 32 packets arriving, each acking 2 packet, but all
>>>> arriving one after the other at it's wire speed (let's say it's a slow
>>>> network, only Gig-E) compared to a single packet arriving that acks 64
>>>> packets of data at once, it's doing something very strange and making
>>>> assumptions about how the network works that are invalid.
>>> Says who? The RFCs say that this assumption SHOULD be reasonable.
>>>>> Unless you know that the endpoint supports ABC and pacing, yes, 
>>>>> there's
>>>>> a very distinct advantage to getting 32 ACKs rather than 1. It also
>>>>> helps with better accuracy on the RTT calculation, which is based on
>>>>> sampling (and you've killed 97% of the samples).
>>>> the 97% of the samples that I've killed would be producing invalid 
>>>> data
>>>> for your calculation because they were delayed in returning.
>>> Why do you think that is invalid data? That's an accurate measure of 
>>> the
>>> return path of the ACK stream.
>> so how do you sanely conclude anything from 32 ack packets arriving 
>> at wire speed back-to-back?
>>> ...
>>>>>> And if there is such an advantage, does it outweight the 
>>>>>> disadvantages
>>>>>> that the extra ack packets cause by causing highly asymmetric 
>>>>>> links to
>>>>>> be overloaded and drop packets?
>>>>> Why is it so bad to drop packets?
>>>> because forcing packets for other services to be dropped to make room
>>>> for acks degrades those other services.
>>> Sure, but remember that we're not here to support the cable company's
>>> business model. They deployed networks that had severely
>>> underprovisioned backchannels so they could use shared channels rather
>>> than routers one step lower in the hierarchy. Now they pull this stunt
>>> so they can fix what's broken with their provisioning model.
>>> The trouble is that it has effects for others in the network, not just
>>> the cable company.
>> It's not just cable companies. the same sort of thing will happen 
>> with half-duplex wifi links where acks will accumulate while data 
>> packets are flowing in the other direction.
>> stop trying to say that this is the fault of one subset of industry 
>> and recognize that there are lots of legitimate reasons for this.
>> Highly asymmetric links are not just 'cable companies 
>> underprovisioning their networks'. DSL lines are highly asymmetric 
>> due to the difference in the cost of the transmitters on each end of 
>> the link. As are Satellite IP systems, etc.
>>>>> TCP isn't supposed to be the most efficient in EVERY corner case. 
>>>>> It's
>>>>> supposed to *always work* in EVERY corner case.
>>>> I don't see how it fails to work in this case. As people have pointed
>>>> out, some cable routers have been doing this for 15 years and the
>>>> Internet has not imploded from it yet, so the drawbacks of dropping
>>>> these already-delayed and redundant ack packets cannot be the
>>>> end-of-the-internet that you are painting it to be
>>> Oh, right. That argument. We haven't seen it break anything, so it
>>> *must* be safe.
>>> What would you see if it were broken? Maybe hosts that burst into the
>>> net and caused router buffers to overload? Hmmm.
>> that happens without this, so you can't blame it on the missing acks.
>>>> We are talking about only doing this in one specific case, the case
>>>> where other things have already caused some of the acks to be 
>>>> delayed to
>>>> the point where later acks have 'caught up' with them on the 
>>>> network and
>>>> both early and late acks are sitting in the same queue on the same
>>>> device waiting to be sent at the same time.
>>> They're in a queue. That means the early ones go out before the late
>>> ones. You have two choices if you coalesce their information:
>>> a) delete the early ACKs
>>>     Oh, but you wouldn't do *that* because it would hit *your*
>>>     customers with a higher delay.
>> but by not having to transmit the early acks, the later ack goes out 
>> faster, so the customers get less of a delay in getting the data they 
>> have received acked.
>> If the only thing in the queue is acks, then the last ack in the 
>> queue goes out as fast as the first ack would. By doing this you 
>> transmit less, which can speed up the network overall as the next 
>> station can transmit it's data faster (thinking of wifi as an example)
>> If there are other packets in the queue, you still can delete all the 
>> acks except the last one that will fit into the burst with no 
>> degredation in how fast data is acknoleged (and you increase the 
>> amount of usable data that is sent in that timeslot instead of 
>> wasting it on redundant ack packets)
>>> b) delete the late ACKs and alter the early ones
>>>     Giving your customers a false sense of how fast their
>>>     data was getting there. Roadrunner pulled stunts like this
>>>     in the early 90's too. It's not exactly news.
>> unless there are other packets in the flow that the ack is jumping, I 
>> see no problem with this. You aren't sending out an ack before the 
>> data is arrived, you just aren't delaying the last ack unneccessarily.
>>>> At this point there are three possiblilities
>>>> 1. all the acks get sent back-to-back, wasting bandwith with their
>>>> redundancy
>>> That's not a waste; that's information.
>> very low value information at best.
>>>> 2. send only the newest ack, trashing all the ones that would be 
>>>> redundant
>>> If you wait to send it last, maybe... but then you're still encouraging
>>> the receiver to burst its next transmissions. We already know that sort
>>> of bursting causes problems (even if *we* don't see them, someone 
>>> does).
>> how would the burst be any different if the server gets 32 acks back 
>> to back vs 1 ack that covers everything. The additional acks aren't 
>> going to get there any faster than the single one would.
>>>> 3. the total of the acks that are queued exceeds the next transmit
>>>> window, so only some of the acks get sent, the newest one doesn't and
>>>> gets delayed further.
>>>> we know that #2 doesn't break the Internet,
>>> No, you really don't. What you know is that #2 is cheap and benefits
>>> you. Everyone continually doing that *will* break the Internet.
>> you keep stating that, but you are short on details about why a 
>> string of acks at wire speed is better than a single ack covering the 
>> same data 'because I say so' doesn't cut it.
>>>> it's within the range of
>>>> responses permitted by the RFC SHOULD.
>>> SHOULD means that breaking it needs to be done for a reason. I've long
>>> argued that the SHOULD should never be there in the first place without
>>> explaining why it isn't a MUST or a MAY and the conditions under which
>>> it might be appropriate to violate it. RFC793 doesn't have that 
>>> context,
>>> unfortunately, but it doesn't mean that any - and every - SHOULD is
>>> intended to be willfully ignored at all times.
>>>> It decreases load on congested links.
>>>                       ^^^^^^^^^
>>> severely underprovisioned
>> no, merely congested for some reason. Any shared media will have the 
>> same situation, when another station is transmitting, a queue builds.
>>>> But you keep insisting that it's a horrible thing to consider doing.
>>> The tragedy of the commons is a horrible thing. Just because something
>>> doesn't hurt you or you can't see how it hurts others doesn't mean 
>>> there
>>> isn't a problem.
>>> I've outlined the reasons why this is bad - basically it works only
>>> under the assumption that DOCSIS modems get to play by their own rules
>>> and every one else plays fair. If that's not a bad idea, I don't know
>>> what is.
>> you say that it breaks timing assumptions and calculations, but then 
>> don't explain how the train of acks arriving at wire speed would let 
>> your calculations be any more accurate.
>> David Lang
>> _______________________________________________
>> aqm mailing list