[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).
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...
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...
Best regards,
Richard
----- Original Message -----
From: "Mikael Abrahamsson" <[email protected]>
To: "Bless, Roland (TM)" <[email protected]>
Cc: "LAUTENSCHLAEGER, Wolfram (Wolfram)"
<[email protected]>; "Greg White"
<[email protected]>; <[email protected]>
Sent: Wednesday, October 07, 2015 12:51 PM
Subject: Re: [aqm] TCP ACK Suppression
On Wed, 7 Oct 2015, Bless, Roland (TM) wrote:
Oh, I hope that this is an exception. Such kind of optimizations may
cause a lot of trouble since a link layer device is interfering with
transport layer semantics. We all know that exactly these kinds of
interference eventually end up in problems with end-to-end transparency
and deployment of new protocol options. At least it interferes with the
ACK clocking expectation of some congestion control algorithms...
Personally, I think you're going to see more and more of this. There are
mulitple shared access medium where you're allowed to send only part of
the time, and it's someone else who tells you when you may send.
So if you're sitting there with 100 ACK packets all nicely ACKing
increasing values indicating no packet loss, and now you're allowed to
send, why not just kill 99 of those ACK packets?
While I agree with you on principle, these kinds of mechanisms cut the
amount of ACK traffic down by factor 15-30, meaning I can download at 250
megabit/s and only have a few hundred kilobit/s of upstream ACKs, instead
of 5-10 megabit/s of ACKs. That's a huge opimization for any kind of
asymmetric and/or time slot access medium such as ADSL, LTE, DOCSIS, PON
and I'm sure there are others.
Btw, what is the reason for TCP doing ACKs for every 2 packets in
steady-state, even with window sizes in the hundreds of kilobytes or even
megabytes? I would prefer if the TCP host stack sent fewer ACKs instead of
trying to optimize this at the access routing device.
--
Mikael Abrahamsson email: [email protected]
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
