BBRv2 TCP-Prague complaint

[Carl Klatsky]

Hi BBR Team,

Reviewing the current BBRv2 status and the mailing list discussions brought to mind this question -- is BBRv2 intended to be a TCP-Prague compliant TCP implementation?  IIRC there was a comment from Neal that it supports DCTCP-like ECN response, which seems to align with TCP Prague requirement "Negotiate altered feedback semantics", meeting at least one of the requirements.  Would like to get the BBR team's input on this comment.

Thanks & Regards,

Carl Klatsky

[Neal Cardwell]

On Fri, Apr 12, 2019 at 9:46 AM Carl Klatsky <carl_k...@comcast.com> wrote:

Hi BBR Team,

Reviewing the current BBRv2 status and the mailing list discussions brought to mind this question -- is BBRv2 intended to be a TCP-Prague compliant TCP implementation?  IIRC there was a comment from Neal that it supports DCTCP-like ECN response, which seems to align with TCP Prague requirement "Negotiate altered feedback semantics", meeting at least one of the requirements.  Would like to get the BBR team's input on this comment.

Hi Carl,

Thus far, BBR v2 has support for using DCTCP-style ECN signals. Since the use of DCTCP-style ECN signals is a major aspect of L4S, my sense is that it should be possible, in principle, to evolve BBR to be compatible with L4S.

I can't speak for our whole team, but personally I would like to see BBR evolve to be L4S-compatible, so that it can use the ECT(1) code point and, in cases where the bottleneck is using an L4S AQM, a BBR flow is able to use L4S ECN signals and keep queues short enough to travel happily in the L4S queue of a dual-queue AQM.

best,

neal

[Carl Klatsky]

Understood. Thanks for the reply Neal.