On Wed, 7 Oct 2015, Richard Scheffenegger wrote:
[as one of the AccECN authors]
Hi David,
I believe you are convoluting a few things in the assumptions behind your
comment...
First, as of now, ACKs are non-ECT; and even if they were marked as ECT by
the receiver, and subsequently marked CE by the network device when they get
bundled and thinned (which, by the way, may be the signal required for AckCC
RFC5690), that would not affect the rate of the data sent to the receiver...
fair enough.
The issue with ACK thinning has most to do with causing a burst of data
segments that get sent all at once, requiring increased buffering later in
the network.
The point here is that the ACKs are going to all arrive at the same time anyway,
so it doesn't matter if 32 ack packets arrive at wire speed, or just one packet
arrives that acks all the data, in either case the data that is held up waiting
for acks is going to be sent at the same time (if anything, avoiding the delay
in receiving and processing the extra acks would decrease latency)
And how the ECN-mark fraction or exact sequencing of the data segments is
conveyed back to the sender by the receiver, can be independent of ACK
thinning (you may want to read through one suggestion to have better ACK loss
protection while still being able to fully reconstruct the exact sequencing
of ECN markings in revision
https://www.ietf.org/archive/id/draft-kuehlewind-tcpm-accurate-ecn-03.txt
(section 3.3.4).
So, you have two issues - one of timing (ACK clock eliciting new data to
send), and one of loss of signal fidelity to deal with, when devices bundle
up ACKs, or thin out ACKs...
The issue here isn't that anything delays acks in order to bundle or thin them
out, but that other criteria result in the acks sitting in one queue at some
point in time. If they are already together like that, it makes sense to thin
them.
David Lang
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
