Re: [tsvwg] [iccrg] CCID5 - BBR for DCCP

[Neal Cardwell <[e-mail]>]

On Tue, Nov 9, 2021 at 10:03 AM <[e-mail]> wrote:

> Dear all,
>
>
>
> As discussed yesterday, at the ICCRG session I would like to bring here 2
> topics to discussion.
>
>
>
> In a first instance, we would like to start the process to bring BBR as a
> new CCID profile for DCCP. As an initial step, we have submitted the draft
> https://www.ietf.org/id/draft-romo-iccrg-ccid5-00.txt and we would be
> happy to receive any feedback or comment on it. It is worth to mention that
> our goal is not to propose definitions related to the Congestion Control
> algorithm itself, which is defined protocol agnostic at
> https://datatracker.ietf.org/doc/draft-cardwell-iccrg-bbr-congestion-control/,
> but to outline the necessary requirements to use it within DCCP.
>

Thanks for this nice work! It's great to see BBR implementations in a wider
variety of transports.

We have proposed to add the following text to the next rev of the BBR draft
to reference your work, alongside the descriptions of TCP and QUIC
implementations:
---
An open source implementation of BBR is also available for DCCP [RFC4340]
[draft-romo-iccrg-ccid5].
...
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <
https://www.rfc-editor.org/info/rfc4340>.
...
[draft-romo-iccrg-ccid5] Romo, N., Kim, J., and M. Amend, "Profile for
Datagram Congestion Control Protocol (DCCP) Congestion Control ID 5", Work
in Progress, Internet-Draft, draft-romo-iccrg-ccid5, 25 October 2021, <
https://tools.ietf.org/html/draft-romo-iccrg-ccid5>.
---
Please let us know if you see any issues with that.

As you note, the intent with the BBR draft is to keep the description of
the algorithm protocol-agnostic. And I think it would be good to keep BBR
protocol-agnostic for as long as possible, to improve the odds of keeping
implementations for various transports in sync.



> The second topic I would like to discuss, is related to the problem found
> during the implementation of BBRv1 for DCCP. To summarize it, BBR requires
> the restoration of the cwnd when leaving the probeRTT phase, that
> restoration implies a big change (from a low to a high value) of the cwnd,
> and therefore a previous synchronization of the DCCP sequence and
> acknowledgement validity windows (RFC4340
> <https://datatracker.ietf.org/doc/html/rfc4340> section 7.5). Such
> synchronization is per DCCP RFC4340 a reliable negotiation to be confirmed
> and therefore takes at least one RTT, increasing the duration of the
> probeRTT phase. In the presentation slides
> <https://datatracker.ietf.org/meeting/112/materials/slides-112-iccrg-ccid5-an-implementation-of-bbr-congestion-control-algorithm-for-dccp-00>
> you can find a more detailed description of the problem as well as the
> temporary solution that has been implemented. Here we would like to bring
> to consideration the possibility of enhancing or modifying the DCCP
> Sequence window negotiation process.
>

Thanks for highlighting this issue. One possible idea for addressing the
interactions between the DCCP Sequence window negotiation process and the
BBR ProbeRTT mechanism would be as follows: instead of basing the sender's
requested DCCP Sequence Number validity window strictly on the cwnd value,
the sender could try to continually maintain a Sequence Number validity
window  big enough to handle the anticipated volume of in-flight data in
the "near future" For BBR in ProbeRTT, this would be something like the
following, which would take into account both the current cwnd and the fact
that upon exiting ProbeRTT the flow will expect to raise its cwnd back to
something in the neighborhood of its previous cwnd before ProbeRTT:

In Internet Draft notation:
   anticipated_volume = max(cwnd, BBR.prior_cwnd)

In Linux TCP notation:
   anticipated_volume = max(tp->snd_cwnd, bbr->prior_cwnd)

That could avoid the approach mentioned in the slides, of a "Pro-active
update of local values even if the confirmation has not been received yet
(feature negotiation not finished)".

Does that sound like a plausible approach?

best regards,
neal