RFC3449 pointed to some of the reasons & problems with manipulating TCP ACKs, and could provide a useful background if people needed to get up to speed on the history...
Gorry > I'm not sure why this discussion is happening on aqm@ instead of tcpm@... > I have added cpm to the cc line, and would recommend that anyone > responding to this thread do the same and remove aqm@. > > On Oct 7, 2015, at 2:13 PM, David Lang <da...@lang.hm> wrote: >> So things that reduce the flow of acks can result in very real benefits >> to users. > > Dumb question of the month. What would it take to see wide deployment of > RFC 5690? That would result in the data/ack ratio being reduced, on > average, to whatever amount had been negotiated. > > Summary for those that haven't read it - TCP implementations today > generally ack every other packet, with caveats for isolated or final data > packets. This proposal allows consenting adults to change that ratio, > acking every third or fourth packet, or every tenth. > > If ack reductions are so very valuable, what's the chance of doing that on > an end to end basis instead of in the network? > >> On Oct 7, 2015, at 2:13 PM, David Lang <da...@lang.hm> wrote: >> On Wed, 7 Oct 2015, Jonathan Morton wrote: >>>> On 7 Oct, 2015, at 23:40, Agarwal, Anil <anil.agar...@viasat.com> >>>> wrote: >>>>> Since the cable modem link will lead to clumped ACKs the difference >>>>> between sending 100 ACKs vs. 1 ACK is probably not that big... >>>>> (except w.r.t. reliability). >>>> The difference may not be big in the spacing of new packets that a >>>> sender will send, unless the sender implements some sort of pacing or >>>> if the return link is very thin. >>> >>>> But with ABC, there will be a difference in the amount of cwnd >>>> increase at the sender. >>> >>> There is also a potential difference for detecting packet loss in the >>> forward direction. Itâs entirely possible that thinning would cause >>> a DupAck condition to be recognised only after three MAC grants in the >>> reverse direction have elapsed, rather than one. Receivers are >>> REQUIRED to send an ack for every received packet under these >>> conditions, but that would be subverted by the modem. AckCC would not >>> induce this effect, because the receiver would still produce the extra >>> acks as required. >>> >>> Packet loss causes head-of-line blocking at the application level, >>> which is perceived as latency and jerkiness by the end-user, until the >>> lost packet is retransmitted and actually arrives. Hence the addition >>> of two MAC grant delays (60ms?) may make the difference between an >>> imperceptible problem and a noticeable one. >> >> and excessive ack traffic causes congestion and results in packet loss >> on real-world hightly asymmetric links. >> >> So things that reduce the flow of acks can result in very real benefits >> to users. >> >> David Lang_______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm > > _______________________________________________ > tcpm mailing list > t...@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
