[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...
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.
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...
Best regards,
Richard
----- Original Message -----
From: "David Lang" <da...@lang.hm>
To: "Jonathan Morton" <chromati...@gmail.com>
Cc: <aqm@ietf.org>; <dav...@spamcop.net>
Sent: Wednesday, October 07, 2015 8:02 PM
Subject: Re: [aqm] TCP ACK Suppression
[...]
It’s not “in the wild”, but this sort of thing is a headache for ELR. It
essentially means that it won’t be able to use AccECN for its feedback
(since
AccECN doesn’t allow reconstructing a complex 32-packet history of ECN
codepoints from a single ACK), but must introduce some other mechanism to
feed
back the required data to the sender.
but if you are getting all 32 acks at the same time, with no other packets
flowing, are you going to be able to do anything sane? do you mark every one
of
the acks with ECN (sending a super-strong backoff message), or only mark one
of
the acks (sending a weak backoff message)
David Lang
--------------------------------------------------------------------------------
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
