[tcpm] BBR and ECN/drop

Hi,

I renamed the subject to start that new thread.

As BBR is not controlling its window based on a drop or mark signal, it will be difficult to define a reduction of the window, as that window is later overwritten by a value calculated from other non-related parameters. What I think could work is a cap on the max(BtlBw) rate that is used in combination with the min(RTT) to calculate the window. The BtlBw could be min-ed with a Bw derived from the average drop/mark probability over some (sliding) time-interval (order of max to support RTT, 100ms?). The exact drop_bw = f(p) function f needs to be determined and is preferably improved over how Reno and Cubic respond to a similar probability but then based on its AIMD. 

For Cubic in Reno mode: drop_bw = 1.68/sqrt(p)/RTT.

For small BDPs this will be very aggressive, and a "big" queue will usually limit the drop probability (in this case also Cubic falls back to the Reno behavior, though with a higher constant, due to its reduction of 30% only).

For high BDPs drop probability will be too low (even for Cubic) and a high drop probability due to bursty traffic on top of a standing queue or due to competing traffic with a small RTT, will reduce the throughput for the long RTT flows.

BBR uses the other extreme, by not responding to drop/ECN signal unless it persists for a long time above 20%. This has many consequences, and I think better would be to respond just more aggressive to it, with a corrected f(p) equation.

The discussion should be what a good equation could be. Preferably the same equation could be used for all use cases (both inside datacenters, DC interconnect and internet).

I presented in ICCRG a first proposal for this equation, that could be used to start the discussion whether it would cover all problem cases sufficiently, or is too aggressive:
Drop_bw = min( 1.68 / sqrt(p) , x / p ) / max( RTT , RTT_ref )
with:
x = 1.68 sqrt(p_o) = 0.168
p_o = 1%
RTT_ref = 5ms

If p < p_o the CC becomes proportional to 1/p (scalable) instead of 1/sqrt(p).
If RTT > RTT_ref, the CC becomes RTT independent.
This will also help to define TCP-Prague behavior.

Any alternatives for this equation or the cut-over parameters?

Koen.

> -----Original Message-----
> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Neal Cardwell
> Sent: donderdag 20 juli 2017 17:12
> To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] ECN++: Congestion response to CE on Pure ACK
> 
> On Thu, Jul 20, 2017 at 2:17 AM, Gengxuesong (Geng Xuesong)
> <gengxuesong@huawei.com> wrote:
> > 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?
> 
> 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
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm