Re: [aqm] TCP ACK Suppression
Simon Barber <simon@superduper.net> Sat, 10 October 2015 20:46 UTC
Return-Path: <simon@superduper.net>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64A91B4863 for <aqm@ietfa.amsl.com>; Sat, 10 Oct 2015 13:46:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level:
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXvZRvJzcLiv for <aqm@ietfa.amsl.com>; Sat, 10 Oct 2015 13:46:45 -0700 (PDT)
Received: from masada.superduper.net (masada.superduper.net [85.119.82.91]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7A91B4862 for <aqm@ietf.org>; Sat, 10 Oct 2015 13:46:45 -0700 (PDT)
Received: from block9.public.monkeybrains.net ([162.217.75.161] helo=[192.168.128.6]) by masada.superduper.net with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <simon@superduper.net>) id 1Zl12M-00061k-PI for aqm@ietf.org; Sat, 10 Oct 2015 21:46:41 +0100
Message-ID: <56197933.8060709@superduper.net>
Date: Sat, 10 Oct 2015 13:46:43 -0700
From: Simon Barber <simon@superduper.net>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: aqm@ietf.org
References: <alpine.DEB.2.02.1510060748480.8750@uplift.swm.pp.se> <D2394BB6.548C5%g.white@cablelabs.com> <0A452E1DADEF254C9A7AC1969B8781284A7D9B66@FR712WXCHMBA13.zeu.alcatel-lucent.com> <5616DCD9.8@isi.edu> <alpine.DEB.2.02.1510081428470.3852@nftneq.ynat.uz> <5616E42D.5090402@isi.edu> <alpine.DEB.2.02.1510081517470.3852@nftneq.ynat.uz> <5616FAFA.5020707@isi.edu> <alpine.DEB.2.02.1510081647590.3852@nftneq.ynat.uz> <561721D5.307@rogers.com> <561725E5.1080502@superduper.net> <alpine.DEB.2.02.1510082106540.2943@nftneq.ynat.uz>
In-Reply-To: <alpine.DEB.2.02.1510082106540.2943@nftneq.ynat.uz>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/a3wh_6n66cLjuszG8JluDYVCg2k>
Subject: Re: [aqm] TCP ACK Suppression
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Oct 2015 20:46:48 -0000
I'm talking specifically about duplicate ACKs - same ACK, same contents - signalling that the receiver has seen a hole. These should be communicated as quickly as possible to reduce head of line blocking and application latency - hence the TCP spec that you should stop delaying your ACKs in this state. Simon On 10/8/2015 9:08 PM, David Lang wrote: > Well, the only situation we are talking about is when an AQM function > finds that there are multiple acks for one TCP session in it's queue. > The dispute is if these acks are can be considered 'duplicates' (since > the later ones will ack data for the earlier ones) and so can be > 'deduped' or if there is a significant amount of value in sending > every ack through anyway. > > David Lang > > On Thu, 8 Oct 2015, Simon Barber wrote: > >> I like this suggestion - but it's only needed in the case where there >> are dup acks. >> >> Simon >> >> 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 >>>> aqm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/aqm >>>> >>> >>> >> >> _______________________________________________ >> 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
- [aqm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] TCP ACK Suppression Greg White
- Re: [aqm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] TCP ACK Suppression LAUTENSCHLAEGER, Wolfram (Wolfram)
- Re: [aqm] TCP ACK Suppression Bless, Roland (TM)
- Re: [aqm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] TCP ACK Suppression Clark Gaylord
- Re: [aqm] TCP ACK Suppression Steve Bauer
- Re: [aqm] TCP ACK Suppression Francini, Andrea (Andrea)
- Re: [aqm] TCP ACK Suppression Richard Scheffenegger
- Re: [aqm] TCP ACK Suppression Greg White
- Re: [aqm] TCP ACK Suppression Bless, Roland (TM)
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Collier-Brown
- Re: [aqm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Richard Scheffenegger
- Re: [aqm] TCP ACK Suppression Yuchung Cheng
- Re: [aqm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Greg White
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Yuchung Cheng
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Christian Huitema
- Re: [aqm] TCP ACK Suppression Rick Jones
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Christian Huitema
- Re: [aqm] TCP ACK Suppression David Collier-Brown
- Re: [aqm] TCP ACK Suppression Simon Barber
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Yuchung Cheng
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression Greg White
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Simon Barber
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Dave Taht
- Re: [aqm] [tcpm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] [tcpm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] [tcpm] TCP ACK Suppression Simon Barber
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Greg White
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang