Subject: [tcpm] ECN++: Congestion response to CE on Pure ACK

From: Bob Briscoe <[email-masked]>
Date: Wed, 19 Jul 2017 08:26:46 +0100

Jana, Marcelo,

For those who have not read the draft, it proposes that
     "A host that sets ECT on pure ACKs MUST reduce its congestion 
window in response to any congestion feedback"

*1/ Altering a variable that does not control the rate of the packets 
being marked.**
***
Jana made the point that the rate of pure ACKs is controlled by the rate 
of the data flow in the opposite direction. So it seems illogical to 
control the rate of any data mixed in with the ACK flow by responding to 
markings on this ACK flow.

This overlooks the point that the markings on the ACK flow are also not 
only due (solely) to the ACKs themselves. They are measurements of a 
queue on the path induced by the combined effect of any pure ACKs and 
any other data in this flow and others. So it is correct to use these 
measurements when sending data into this queue. Irrespective of whether 
it controls the rate of the particular packet used to probe for that 
measurement. And irrespective of whether there is any data at all being 
sent at the moment.

*2/ Response to CE on Pure ACK**
*
I've realized that, in the conversation in tcpm on Monday, we forgot to 
express the over-arching caveat about congestion responses defined in 
this ECN++ draft...

The draft is meant to be independent of each congestion control 
specification. So it says "MUST reduce", but it doesn't say by how much. 
In general that is left to be defined by future CC spec's. Nonetheless, 
this draft ought to have said what reduction it would expect for 
existing standardized congestion control(s).

If one's mind is trapped within the Kafkaesque {Note 1} world of Reno 
[RFC5681] congestion control, one would require CE on a pure ACK to 
halve the congestion window, or perhaps halve ssthresh. However, the 
suspension of disbelief necessary to persist in this worldview would 
increase one's alienation from normal human relations and common sense.

If one switches context to the slightly more comfortable world where a 
sender reacts to the extent of congestion, not its existence (as in 
DCTCP), one would consider CE on a pure ACK as one more contribution to 
the moving average of congestion. And one could go further and factor 
down the contribution to the moving average proportionate to the bytes 
in the marked packet (rather like appropriate byte counting [RFC3465], 
but for decreases as well as increases).

This flow of logic starts to unravel when one has to decide which 
headers to include in the byte count. It would be correct to include 
those headers present when the packet was marked. But L4 cannot know 
that - consider tunnels etc. So one might at least include a 'typical' 
size of the TCP and IP headers that are being added by the sending host 
- at least those that the TCP CC algo can discover.

Bob

{Note 1}: For those who did not have the pleasure of visiting the Kafka 
museum last night at the IETF social, "Kafka's work is characterized by 
nightmarish settings in which characters are crushed by nonsensical, 
blind authority. Thus, the word /Kafkaesque/ is often applied to bizarre 
and impersonal administrative situations where the individual feels 
powerless to understand or control what is happening."

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 19 Jul 2017 09:38:04 +0100

> existing standardized congestion control(s).

More generally, what effect.  I'd like to know what the interaction
(if any) between ECN and TCP-BBR might be.
-- 
Cheers,
  Jeremy

---

From: Anna Brunstrom <[email-masked]>
Date: Wed, 19 Jul 2017 16:34:21 +0200

On 2017-07-19 09:26, Bob Briscoe wrote:

> Jana made the point that the rate of pure ACKs is controlled by the 
> rate of the data flow in the opposite direction. So it seems illogical 
> to control the rate of any data mixed in with the ACK flow by 
> responding to markings on this ACK flow.
>
> This overlooks the point that the markings on the ACK flow are also 
> not only due (solely) to the ACKs themselves. They are measurements of 
> a queue on the path induced by the combined effect of any pure ACKs 
> and any other data in this flow and others. So it is correct to use 
> these measurements when sending data into this queue. Irrespective of 
> whether it controls the rate of the particular packet used to probe 
> for that measurement. And irrespective of whether there is any data at 
> all being sent at the moment.

I agree with Jana that this becomes strange.

If the argument is that the ACKs measure the queue you would also have 
to take all pure ACKs that pass through the queue without getting marked 
as an indication to increase the congestion window. Otherwise your 
measurement will be very biased.

Cheers,
Anna

> I've realized that, in the conversation in tcpm on Monday, we forgot 
> to express the over-arching caveat about congestion responses defined 
> in this ECN++ draft...
>
> specification. So it says "MUST reduce", but it doesn't say by how 
> much. In general that is left to be defined by future CC spec's. 
> Nonetheless, this draft ought to have said what reduction it would 
> expect for existing standardized congestion control(s).
>
> DCTCP), one would consider CE on a pure ACK as one more contribution 
> to the moving average of congestion. And one could go further and 
> factor down the contribution to the moving average proportionate to 
> the bytes in the marked packet (rather like appropriate byte counting 
> [RFC3465], but for decreases as well as increases).
>
> size of the TCP and IP headers that are being added by the sending 
> host - at least those that the TCP CC algo can discover.
>
>
>
>
> Bob
>
>
> {Note 1}: For those who did not have the pleasure of visiting the 
> Kafka museum last night at the IETF social, "Kafka's work is 
> characterized by nightmarish settings in which characters are crushed 
> by nonsensical, blind authority. Thus, the word /Kafkaesque/ is often 
> applied to bizarre and impersonal administrative situations where the 
> individual feels powerless to understand or control what is happening."
>
> -- 
> Bob Briscoehttp://bobbriscoe.net/
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Neal Cardwell <[email-masked]>
Date: Wed, 19 Jul 2017 14:00:45 -0400

> (if any) between ECN and TCP-BBR might be.

Currently there is no defined interaction between BBR and ECN. When
using BBR, we recommend that administrators disable RFC 3168 ECN
signaling.

It is not yet clear to me how one would integrate ECN and BBR, since
ECN schemes typically mandate a particular cwnd response from a
sender. It seems hard for me to imagine wanting to integrate BBR with
RFC 3168 ECN. But IMHO, down the road, there may be ways to fold in
other types of ECN signals into BBR's model or control response (if
the ECN protocol in question is willing to co-exist with a BBR-style
response).

neal

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Thu, 20 Jul 2017 06:17:31 +0000

Hi Neal

I think it is a very interesting discussion about the interaction between BBR and ECN.
You mentioned that " since ECN schemes typically mandate a particular cwnd response from a sender ". Do you mean that the conflict between ECN and BBR is the conflict between cwnd mode and pacing mode? 
In other word, do you think if ECN is used as a signal of modifying pacing rate, these two mechanisms may work together well?

Best Regards

Xuesong

>-----Original Message-----
>From: tcpm [mailto:[email-masked]] On Behalf Of Neal Cardwell
>Sent: Thursday, July 20, 2017 2:01 AM
>To: Jeremy Harris
>Cc: [email-masked]
>Subject: Re: [tcpm] ECN++: Congestion response to CE on Pure ACK
>
>>> In general that is left to be defined by future CC spec's.
>Currently there is no defined interaction between BBR and ECN. When using
>BBR, we recommend that administrators disable RFC 3168 ECN signaling.
>
>It is not yet clear to me how one would integrate ECN and BBR, since ECN
>schemes typically mandate a particular cwnd response from a sender. It seems
>hard for me to imagine wanting to integrate BBR with RFC 3168 ECN. But IMHO,
>down the road, there may be ways to fold in other types of ECN signals into
>BBR's model or control response (if the ECN protocol in question is willing to
>co-exist with a BBR-style response).
>
>neal
>

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 20 Jul 2017 09:44:31 +0100

Anna,

On 19/07/17 15:34, Anna Brunstrom wrote:
>> rate of the data flow in the opposite direction. So it seems 
>> illogical to control the rate of any data mixed in with the ACK flow 
>> by responding to markings on this ACK flow.
>>
>> not only due (solely) to the ACKs themselves. They are measurements 
>> of a queue on the path induced by the combined effect of any pure 
>> ACKs and any other data in this flow and others. So it is correct to 
>> use these measurements when sending data into this queue. 
>> Irrespective of whether it controls the rate of the particular packet 
>> used to probe for that measurement. And irrespective of whether there 
>> is any data at all being sent at the moment.
>
> to take all pure ACKs that pass through the queue without getting 
> marked as an indication to increase the congestion window. Otherwise 
> your measurement will be very biased.
Good point.

And what would be wrong with doing that (using ABC, but adjusted for 
header sizes, as described later below)?

The problem here is that:
* ECN introduces previously unavailable information, so we could ignore 
it to be minimally "the same as TCP without ECN",
* but it would be useful to do something sensible
* I don't feel anything  sophisticated  will get implemented - doesn't 
seem enough interest in CC for app-limited traffic with ECN

Bob
>> If one switches context to the slightly more comfortable world where 
>> a sender reacts to the extent of congestion, not its existence (as in 
>> that - consider tunnels etc. So one might at least include a 
>> 'typical' size of the TCP and IP headers that are being added by the 
>> sending host - at least those that the TCP CC algo can discover.
>>
>>
>>
>>
>> Bob
>>
>>

---

From: Neal Cardwell <[email-masked]>
Date: Thu, 20 Jul 2017 11:11:37 -0400

> In other word, do you think if ECN is used as a signal of modifying pacing rate, these two mechanisms may work together well?

I didn't really mean the distinction between control via cwnd vs
control via pacing rate. I meant the deeper question of whether a
congestion control algorithm should simply have a fixed back-off
response to losses (Reno, CUBIC) or ECN marks (RFC 3168, DCTCP), or
whether the algorithm should try to make an independent estimate of
the capacity available to the flow (BBR).

But if someone wants an extended discussion of BBR and ECN, I'd
suggest that this should move to a separate thread, so that this
thread can stay focused on the original issues Bob raised in this
thread.

thanks,
neal