Re: [aqm] TCP ACK Suppression

[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" <david@lang.hm>
To: "Jonathan Morton" <chromatix99@gmail.com>
Cc: <aqm@ietf.org>; <davecb@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
> 