You are thinking that the point of a router is to be totally focused on TCP as it is at the moment. cwnd is a TCP-only concept. And in fact, you are focused on a "long-hold time" FTP-like TCP flow with maximal bitrate. TCP in the Internet is not like that. In ns2 experiments that are used to generate benchmarks, maybe. But those benchmarks are rarely realistic.
On Wednesday, October 7, 2015 4:40pm, "Agarwal, Anil" <anil.agar...@viasat.com> said: > > Bless, Roland (TM) <roland.bl...@kit.edu> > 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. > With 100 ACKs, each ACK will result in cwnd increase by 2 * MSS (assuming > delayed > Acks) during slow start and > 2 * MSS / cwnd during congestion avoidance. > With a single ACK covering 200 segments, cwnd will increase by L*MSS, during > slow > start and > L * MSS / cwnd during congestion avoidance; L =2, as stated in RFC 3465. > Hence, > cwnd increase will be much slower. > Unless L is set to a larger value. > > Anil > > -----Original Message----- > From: aqm [mailto:aqm-boun...@ietf.org] On Behalf Of Mikael Abrahamsson > Sent: Wednesday, October 07, 2015 4:18 PM > To: dpr...@reed.com > Cc: aqm@ietf.org > Subject: Re: [aqm] ACK Suppression > > On Wed, 7 Oct 2015, dpr...@reed.com wrote: > > > 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. > > There is no congestion when the ACK suppression kicks in and is useful. > > If I download at 250 megabit/s, at 1500 byte packets, this is around 21kpps. > That > means I am sending around 10kpps worth of ACKs. > > If my media access layer only gives me access to send packets every 1-3 ms > (but I > can send many packets at a time each time), that means I basically will have > 10-30 > ACKs in queue each time I get access to the medium. > > For each transmit opportunity, you will see a "train of ACKs" with a duration > of > 0.1-0.5ms, then there will be nothing for 1-3ms, then you will see a train of > ACks > again. > > So providing that the router in question actually knows what it's doing, this > is a > useful optimization. Actually, I'd say I don't really understand why the TCP > stack > is sending 10kpps anyhow, is this very fine grained resolution used for > anything > anyhow? Even considering that this "train of ACKs" will arrive back-to-back, > is > the difference that big compared to just sending fewer ACKs (from the host, > so the > router doesn't have to optimize). > > My ISP has a very common service with is 250 megabit/s down and 10 megabit/s > up. > If this TCP ACK suppression doesn't exist, then much of the customer upstream > capacity is used for ACKing the download packets (for no great use for the > user as > far as I can tell). > > Wouldn't it make sense to for TCP to limit ACKs to once per millisecond or > 1/10th > RTT, whatever is lower? Or something along these lines, perhaps the 1/10th of > RTT > is not low enough, so perhaps 1/50th of RTT. > > For instance for my test here with around 10ms RTT, what would limit the ACKs > from > 10kpps to 2kpps in the host stack itself (with 1/50th of RTT being lower in > this > case). > > It would at least make sense when using a time based media access layer such > as > LTE, DOCSIS etc. > > -- > Mikael Abrahamsson email: swm...@swm.pp.se > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_aqm&d=BQICAg&c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=O9YyDhG9aYPKoP_qfqzx2qr1WyA9s7n8zHybjDGhnkM&s=KQjsKwtKdO7fKEDJ2iWN7o0p-LVDX5-7it_eroz_ew0&e= >
_______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
