Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - BBR

[[e-mail]]

Hi Neal, hi Greg,

Neal, thanks for chiming in and for clarification. Greg, I have no concerns with the BBR statement in draft NQB and withdraw my related comment.

Regards,

Rüdiger

Von: Neal Cardwell <[e-mail]>
Gesendet: Mittwoch, 2. August 2023 15:48
An: Geib, Rüdiger <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - BBR



On Wed, Aug 2, 2023 at 5:19 AM <[e-mail]<mailto:[e-mail]>> wrote:
Hi Roland, hi Greg

thanks. Some questions:
- is BBR "work in progress" and statements referring to it best should mention a version (e.g., BBRv2 and earlier versions...)?
- Roland, could you provide a reference for insertion in draft NQB?

I found https://datatracker.ietf.org/meeting/117/materials/slides-117-ccwg-bbrv3-algorithm-bug-fixes-and-public-internet-deployment-00, contains:
- So most test results for BBRv2 will not apply to BBRv3
- Primary impact of these changes:
  Lower queuing delays and packet loss rates during and shortly after STARTUP

I don't claim that to be true and don't know, whether that has yet been validated independently. If I'm to have trust in Greg's work, I'd have to have trust into this presentation too.

From all that I learned about networking, in the absence of admission control no sender is able to predict whether its initial traffic sent to a destination may cause congestion at the bottleneck. This, I think, holds independent of a DSCP chosen to mark that traffic. It is more important to me to understand, whether a BBR(v3) flow repeatedly causes queue-pressure.

For the question about whether a BBR(v3) flow repeatedly causes queue-pressure, the answer is: in the general case with an arbitrary number of BBR flows, yes, the flows cause repeated/sustained queue pressure.

Regarding the text in the NQB draft that mentions BBR – "Many of the commonly-deployed congestion control algorithms, such as Reno, Cubic or BBR, are designed to seek the available capacity of the end-to-end path (which can frequently be the access network link capacity), and in doing so generally overshoot the available capacity, causing a queue to build up at the bottleneck link." – that text seems fine to me.

Regarding "the design aim of BBR" mentioned at the start of this thread, please note that, as mentioned in the BBR draft – https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control#name-introduction-7 – the design aim of BBR is "low queue pressure", not zero queue pressure. That is, BBR is trying to bound queues at a reasonable/feasible level, not avoid them altogether. That said, when there is a single BBR flow through a bottleneck link with a stable bandwidth, BBR is often able to keep queues quite low for the majority of the time. But when there are N>1 BBR flows the bottleneck queue tends to be in the neighborhood of 1.5*BDP (or whatever will fit in the bottleneck buffer). But if BBR were to try to avoid queues altogether, it would starve in the presence of queue-building CUBIC or Reno flows, and thus would not be usable on the public Internet.

So capacity-seeking (web, video, file transfer) BBR traffic is not the kind of "Non-Queue-Building" traffic covered by the NQB draft, and the NQB draft is correct in noting this.

best regards,
neal


NQB, as Greg emphasized, provides low jitter and loss on a statistical basis *only* (and it *doesn't* provide throughput guarantees). A single, brief period of congestion every such and such minutes won't significantly impact jitter and loss statistics, if these were measured by a number of probes allowing stat-calculation with high confidence.

Roland, I agree, bottleneck buffer size and the number of flows impact buffer dimensioning and the buffer depth impacts the performance experienced by the flows. You mention an 8 BDP buffer, is that 8*60[ms]*100 Mbit/s? If yes, I'm astonished. Is that a standard Internet config - or ,e.g., WiFi specific? 8*20ms@100Mbit/s would be closer to my expectations.

Regards,

Ruediger


-----Ursprüngliche Nachricht-----
Von: Bless, Roland (TM) <[e-mail]<mailto:[e-mail]>>
Gesendet: Mittwoch, 2. August 2023 10:22
An: Geib, Rüdiger <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - BBR

Hi Rüdiger,

On 02.08.23 at 08:25 [e-mail]<mailto:[e-mail]> wrote:
> thanks. My point is, draft-NQB claims BBR to "generally overshoot the available capacity, causing a queue to build up at the bottleneck link". This contradicts the BBR design aim, as formulated by the BBR authors "..without causing excessive queue pressure", and it seems to contradict a statement to be found within an RFC co-authored by Greg too. In the NQB draft, Greg puts down a negative evaluation of BBR, but does neither provide a reference, nor measurement results backing his assessment. A non-informed reader may take that as whatever BBR claims, they failed. I'd expect a reference for statements like that at least. Or removal.
>

It is correct that BBRv1 and BBRv2 may overshoot considerably during their startup phase as other congestion controls would also do during their slow start phase. Although BBRv3 has a changed startup phase, I guess that the behavior is still somewhat similar. In general, BBR's behavior also depends on the bottleneck buffer size and the number of flows present. In larger buffers BBRv2 still caused considerable queueing delays that would not fit NQB's goals (e.g., we measured two flows 20ms and 60ms RTT, 100 Mbit/s bottleneck capacity, 8 BDP buffer caused 40–60ms queuing delay). This was usually better in smaller buffers as inflight_hi was set early due to packet loss >%2.
However, newly starting BBR flows would probably regularly exceed NQB's buffer capacity and thus causing jitter and loss.

Regards,
  Roland

> -----Ursprüngliche Nachricht-----
> Von: Bless, Roland (TM) <[e-mail]<mailto:[e-mail]>>
> Gesendet: Dienstag, 1. August 2023 16:39
> An: Geib, Rüdiger <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>
> Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt - BBR
>
> Hi Rüdiger,
>
> I brought this issue up on 2019/09/13 already (see "Comments on draft-white-tsvwg-nqb-02"
> https://mailarchive.ietf.org/arch/msg/tsvwg/OY6yFWNUGxukDOwvpMP1Fuokiy
> E/ for reference). In general, capacity seeking does not automatically
> mean that it is queue building (e.g., TCP LoLa tries limit its queue to 5ms, but it is capacity seeking). BBR cannot always avoid to build a queue, but tries to limit its length, too.
> As far as I understand the NQB design and draft, NQB flows are application-limited in nature (and thus not capacity seeking), so neither BBR nor LoLa flows are intended to use the NQB PHB.
>
> Regards,
>    Roland
>
> On 01.08.23 at 16:09 [e-mail]<mailto:[e-mail]> wrote:
>> Hi Greg,
>>
>> Your draft NQB characterizes BBR as a capacity seeking protocol...causing a queue to build up at the bottleneck link (see below). This is seemingly in contradiction with the design aim of BBR (see below). Further, RFC9330 lists BBR as a "scalable congestion control" based protocol (see below). I note that the latter is co-authored by you. I take the statement of RFC9330 to contradict the standards track NQB judgement of BBR. Could you provide a reference or text explaining to readers, why your latest standards track RFC judges BBR as Queue Building? Alternatively, you could remove BBR from the statement in draft NQB.
>>
>> Regards,
>>
>> Ruediger
>>
>>
>> https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html#name-int
>> r oduction Many of the commonly-deployed congestion control
>> algorithms, such as ..... BBR, are designed to seek the available
>> capacity of the end-to-end path (which can frequently be the access network link capacity), and in doing so generally overshoot the available capacity, causing a queue to build up at the bottleneck link.
>>
>> https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-conges
>> t
>> ion-control#name-introduction-7 BBR uses recent measurements of a
>> transport connection's delivery rate, round-trip time, and packet loss rate to build an explicit model of the network path, including its estimated available bandwidth, bandwidth-delay product, and the maximum volume of data that the connection can place in-flight in the network without causing excessive queue pressure.
>>
>> https://www.rfc-editor.org/rfc/rfc9330.html#name-l4s-architecture-ove
>> r view Indeed, between the present document being drafted and
>> published, the following Scalable congestion controls were
>> implemented: ...., and the L4S ECN part of Bottleneck Bandwidth and Round-trip propagation time (BBRv2) [BBRv2] intended for TCP and QUIC transports.
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: tsvwg <[e-mail]<mailto:[e-mail]>> Im Auftrag von
>> [e-mail]<mailto:[e-mail]>
>> Gesendet: Mittwoch, 26. Juli 2023 19:08
>> An: [e-mail]<mailto:[e-mail]>
>> Cc: [e-mail]<mailto:[e-mail]>
>> Betreff: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-19.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Transport Area Working Group (TSVWG) WG of the IETF.
>>
>>      Title           : A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services
>>      Authors         : Greg White
>>                        Thomas Fossati
>>      Filename        : draft-ietf-tsvwg-nqb-19.txt
>>      Pages           : 29
>>      Date            : 2023-07-26
>>
>> Abstract:
>>      This document specifies properties and characteristics of a Non-
>>      Queue-Building Per-Hop Behavior (NQB PHB).  The NQB PHB provides a
>>      shallow-buffered, best-effort service as a complement to a Default
>>      deep-buffered best-effort service for Internet services.  The purpose
>>      of this NQB PHB is to provide a separate queue that enables smooth
>>      (i.e. non-bursty), low-data-rate, application-limited traffic
>>      microflows, which would ordinarily share a queue with bursty and
>>      capacity-seeking traffic, to avoid the latency, latency variation and
>>      loss caused by such traffic.  This PHB is implemented without
>>      prioritization and can be implemented without rate policing, making
>>      it suitable for environments where the use of these features is
>>      restricted.  The NQB PHB has been developed primarily for use by
>>      access network segments, where queuing delays and queuing loss caused
>>      by Queue-Building protocols are manifested, but its use is not
>>      limited to such segments.  In particular, applications to cable
>>      broadband links, Wi-Fi links, and mobile network radio and core
>>      segments are discussed.  This document recommends a specific
>>      Differentiated Services Code Point (DSCP) to identify Non-Queue-
>>      Building microflows.
>>
>>      [NOTE (to be removed by RFC-Editor): This document references an ISE
>>      submission draft (I-D.briscoe-docsis-q-protection) that is approved
>>      for publication as an RFC.  This draft should be held for publication
>>      until the queue protection RFC can be referenced.]
>>
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-19.html
>>
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-19
>>
>> Internet-Drafts are also available by rsync at
>> rsync.ietf.org::internet-drafts
>>
>>
>