BBR v2 ECN

[Ingemar Johansson]

Hi

Looking through the v5.2-rc2 code I can see that a parameter 'delivered_ce' is defined in tcp_sock but other than that I don't see any evidence for the support of ECN (L4S) in BBRv2. Do you still plan to include L4S support for BBRv2 ?

Regards

Ingemar

[Neal Cardwell]

On Tue, May 28, 2019 at 8:35 AM Ingemar Johansson <in...@ijdata.com> wrote:

Hi

Looking through the v5.2-rc2 code I can see that a parameter 'delivered_ce' is defined in tcp_sock but other than that I don't see any evidence for the support of ECN (L4S) in BBRv2. Do you still plan to include L4S support for BBRv2 ?

Hi Ingemar,

Yes, we still plan on including L4S support for BBRv2.

BBRv2 is not upstream in the Linux TCP code base yet. We are working on getting the code ready for a pre-release/RFC version that we plan on posting at:

   https://github.com/google/bbr

But indeed tp->delivered and tp->delivered_ce are part of the infrastructure inside the Linux TCP stack that BBRv2 makes use of.

cheers,

neal

[Ingemar Johansson]

OK, thanks for the update, looking forward to try it out.

/Ingemar

[Tao Tse]

Hi, Neal

I've read some materials about ECN, and I want to ask a question here for discussion.

As rfc3168 described:

After a TCP receiver sends an ACK packet with the ECN-Echo bit set,
that TCP receiver continues to set the ECN-Echo flag in all the ACK
packets it sends (whether they acknowledge CE data packets or non-CE
data packets) until it receives a CWR packet (a packet with the CWR
flag set).

I am confused that is CWR really needed(necessary)?

Suppose if there is NO CWR, and can it work like this?:
* Receiever sends ACK packets with ECN-Echo if there's CE packet(s) received before, and without ECN-Echo if there's no CE packet received.
* Sender reduces congestion window (or reduce sending rate) if recieved ACK packet(s) with ECN-Echo (guarentee to reduce once in one RTT).
--
As I described, if congestion continue happening, receiver continue sending ACK packets with ECN-Echo, this makes the sender normally reduce its cwnd (once in one RTT).
But if congestion happen occasionally (just few packets with CE), receiver will send ACK packets with ECN-Echo occasionally, this MAY make the sender reduce its cwnd, if the ACK with ECN-Echo lost, the sender do noting -- I think this OK, because the congestion is disappeared. And this is the simpler way.
Is there any issue with my thoughts?

Thanks!
--
xtao

[Neal Cardwell]

On Mon, Jun 10, 2019 at 12:20 PM Tao Tse <g.xi...@gmail.com> wrote:

Hi, Neal

I've read some materials about ECN, and I want to ask a question here for discussion.

As rfc3168 described:

After a TCP receiver sends an ACK packet with the ECN-Echo bit set,
that TCP receiver continues to set the ECN-Echo flag in all the ACK
packets it sends (whether they acknowledge CE data packets or non-CE
data packets) until it receives a CWR packet (a packet with the CWR
flag set).

I am confused that is CWR really needed(necessary)?

Suppose if there is NO CWR, and can it work like this?:
* Receiever sends ACK packets with ECN-Echo if there's CE packet(s) received before, and without ECN-Echo if there's no CE packet received.
* Sender reduces congestion window (or reduce sending rate) if recieved ACK packet(s) with ECN-Echo (guarentee to reduce once in one RTT).
--
As I described, if congestion continue happening, receiver continue sending ACK packets with ECN-Echo, this makes the sender normally reduce its cwnd (once in one RTT).
But if congestion happen occasionally (just few packets with CE), receiver will send ACK packets with ECN-Echo occasionally, this MAY make the sender reduce its cwnd, if the ACK with ECN-Echo lost, the sender do noting -- I think this OK, because the congestion is disappeared. And this is the simpler way.
Is there any issue with my thoughts?

I suppose the answer would depend on the cost one assigns to the scenarios where an ACK with ECN-echo is lost, and the frequency with which that happens. And that would depend on the network and traffic in the deployment environment. It would seem to depend especially on how common ACK loss is, and whether it would be acceptable to have (a) higher congestion in the data direction due to higher congestion in the ACK direction, or (b) fairness issues between flows with different ACK loss rates.

AFAICT the ECN ACKing design you describe is similar to the ECN ACKing design in DCTCP:

  https://tools.ietf.org/html/rfc8257#section-3.2

best,

neal