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

["Bless, Roland (TM)" <[e-mail]>]

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/OY6yFWNUGxukDOwvpMP1FuokiyE/
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] 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-introduction
> 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-congestion-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-overview
> 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]> Im Auftrag von [e-mail]
> Gesendet: Mittwoch, 26. Juli 2023 19:08
> An: [e-mail]
> Cc: [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
> 
>