Hi, Am 07.10.2015 um 17:57 schrieb Richard Scheffenegger: > [as individual] > > Hi Mikael, > > ACK thinning will interfere with the ACK clock of the sender; a good > recipie to require much more buffering at the bottlneck hop of that > session (since the sender will start bursting out TCP data packets at > it's line rate, rather than the bottleneck link rate).
Yes, however, if I understood Mikael correctly, the 100 ACKs are waiting to be transmitted anyway, so the cable modem link isn't able to provide feedback at a higher rate, i.e., there is a choice of getting 100 ACKs transmitted as burst (lets say an ACK train) or a single ACK for the same amount of data. The effect for congestion control is probably the same (sender sends out a burst) if the link is the only bottleneck and the single ACK will not get lost (i.e., you are throwing away lots of redundancy that may help in case of packet loss affecting the ACK. > So, if your goal is to have the sender send out TCP data segments at the > bottleneck rate, you'd not want to ACK too many segments at once... 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). > Of course, the drawback is your observation, that TCP (over Ethernet) > typically requires 64 bytes of ACK per 2x 1448 bytes, or about 1:45 > uplink/downlink bandwidth). > > Others have already pointed out some relevant RFCs in this thread too... Regards, Roland _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
