Re: [aqm] TCP ACK Suppression

[David Collier-Brown <[e-mail]>]

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


-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
[e-mail]           |                      -- Mark Twain