On Mon, Jul 25, 2022 at 10:20:48AM +0200, Michael Welzl wrote:
> > Think of it as that the transport layer controls/avoids the congestion for
> > the application. The symptoms of the congestion are packet loss and/or long
> > queuing delay which *may not* be desirable for the application. If the
> > application works fine with the presence of the congestion, then they do
> > not need the congestion control.
>
> That’s wrong. Such an application can harm everyone else. Even CBR
> applications should at least have a circuit breaker.
And if i remember correctly, our circuit breaker work doesn't even include
the level of complexity to isolate non-congestion loss first. With more
and more radio network links coming up without hop-by-hop FEC to maximize
performance and interest to do FEC at end-to-end layer, this is becoming
more and more an issue.
Thats also a more fundamental question against the scope of this congestion
work: Is it going to include the problem of dealing with non-congestion loss.
Cheers
Toerless
> > Otherwise they need to do something to "control the congestion" because if
> > they don't and send as fast as network interface speed, they will
> > experience congestion in the bottleneck somewhere along the path. And the
> > congestion may also be caused by other bottleneck-sharing flows which sends
> > too fast. The means to control the congestion is adjusting the sending rate
> > in the form of send window or pacing rate. The name congestion control
> > talks about the goal of the algorithm and sending rate control talks about
> > the means to achieve the goal.
>
> But it’s not just “congestion” that this is about - an application which
> never uses feedback about the path will also never learn how fast it *could*
> have sent. Sending as fast as allowed, thereby cutting transfer completion
> time (thereby reducing latency and energy wastage!) is what good CC can give
> to an application, and this is completely hidden by the current name of this
> functionality.
>
> Indeed, CC on the Internet (as opposed to datacenters, e.g. with mechanisms
> such as HPCC!) today doesn’t do very much to give feedback to applications
> before they start exceeding the maximum capacity, but if we want to fix this
> some day, then changing the name might be a good start too. Having a name
> that refers to a mostly non-existent problem makes the whole topic stale.
>
> Cheers,
> Michael
>
>
>
> >
> > Best,
> > Hang Shi
> >
> > -----Original Message-----
> > From: tsv-area <[email protected]> On Behalf Of Michael Welzl
> > Sent: Monday, July 25, 2022 5:30 AM
> > To: Bless, Roland (TM) <[email protected]>
> > Cc: Toerless Eckert <[email protected]>; Stuart Cheshire
> > <[email protected]>; [email protected]
> > Subject: Re: At TSVAREA in Philadelphia: The Future of Congestion Control
> > at IETF (and a new name for it?)
> >
> >
> >
> >> On Jul 24, 2022, at 2:50 PM, Bless, Roland (TM) <[email protected]>
> >> wrote:
> >>
> >> Hi Michael,
> >>
> >> see below.
> >>
> >> On 24.07.22 at 12:12 Michael Welzl wrote:
> >>>> On Jul 24, 2022, at 3:03 AM, Toerless Eckert <[email protected]> wrote:
> >>>>
> >>>> Inline
> >>>>
> >>>> On Sat, Jul 23, 2022 at 08:10:43PM -0400, Stuart Cheshire wrote:
> >>>>> I feel that in retrospect the name “congestion control” was a poor
> >>>>> choice. Too often when I talk to people building their own home-grown
> >>>>> transport protocol on top of UDP, and I ask them what congestion
> >>>>> control algorithm they use, they smile smugly and say, “We don’t need
> >>>>> congestion control.” They explain that their protocol won’t be used on
> >>>>> congested networks.
> >>> I agree SO strongly !!!!!
> >>> The main problem of congestion control these days appears to be that
> >>> networks are mostly underutilized (see the thread on ICCRG I started by
> >>> pointing at our ComMag paper) - the issue is to increase the rate as
> >>> quickly as possible, without producing congestion.
> >>
> >> Now, what is congestion in this context? Packet loss or too high queuing
> >> delay?
> >
> > I’d say both, but -
> >
> >
> >>> It should really be called “rate control”.
> >>> It’s about a sending rate - whether that is indirectly achieved by
> >>> controlling a window or explicitly by changing a rate in bits per second
> >>> doesn’t really matter.
> >>
> >> Yes, one would assume that, but technically it does matter.
> >
> > - you seem to misunderstand. I wasn’t suggesting that “rate control is the
> > only way, window control is just the same thing”. Not at all !
> > I’m saying that if you do it using a window, or an explicit send rate in
> > bits/second or packets per whatever time unit … either way, you’re always
> > in fact controlling a rate, and hence “rate control” is a good term for it.
> > Window based control is just tighter, because:
> >
> >
> >> Typically, you want to control the sending rate _and_ the amount of
> >> inflight data. Window-based approaches have the advantage that they
> >> are kind of self-stabilizing due to the implicit rate feedback by the
> >> growing effective RTT (queueing delay induced).
> >> Moreover, if your congestion window is estimated too large, you just
> >> get a constant amount of excess data in the bottleneck queue, whereas
> >> if your sending rate is too large, you get a growing amount of
> >> inflight data over time and thus increasing excess data in the bottleneck
> >> queue.
> >> Even if a rate-based algorithm would know and pick the perfect rate it
> >> may result in instability at the bottleneck (c.f. queueing theory at
> >> \rho=1). Controlling the sending rate is thus harder and more fragile.
> >> Therefore, I'm a strong proponent of having a window-based approach
> >> that uses pacing in addition to avoid micro-bursts and cope with
> >> unsteady/distorted ACK feedback. The other way around would also work
> >> and that's how BBRv2 currently tries to approach the
> >> problem: using a rate-based sender that also controls the amount of
> >> inflight data.
> >
> > ….yes, yes, of course, all that! But it’s not really what I meant though
> > :)
> >
> > Cheers,
> > Michael
> >
--
---
[email protected]
