From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 4A8DB3B29E for ; Fri, 30 Nov 2018 05:32:43 -0500 (EST) Received: by mail-qk1-x742.google.com with SMTP id y16so2847534qki.7 for ; Fri, 30 Nov 2018 02:32:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KDy5nPDFC9klLddNYE5uifWL0jCpHkzRw2ngm/bCQCM=; b=Gh5hIijRaH088i4n92hhK1tAr24Iu9ebCJknjliZkfy2URruAZBdyP/6RYvq7+ib19 g5N+Vtye51mpGDl7v2aQEDUA2uTQLQfnsc6GIHn2y41TCyH10ECtLlzVCaJqc7CHpKn9 RARMsys9KCQrK2Uoa35NHX6J+LyKj5ZNOGHQXye4tWKQSygx9pQREegke4aSahJvWaok yf1yZ/GdtaiHIzVcV4mseilbpDxgIBrKWJPEccDo/hgLnkcr29cqjKHxW4PTt6XGbIbS pU4ichJBC2+Sv/F6Q+LkAYNlFtzDgBZdWZx10tfpGw39Fg7r8b17NA1qOd1TjNQUMp6b sxYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KDy5nPDFC9klLddNYE5uifWL0jCpHkzRw2ngm/bCQCM=; b=YjnX2n04XPEMCaiBYoEPPZne3pns5jNAhDXSkWgGvOvn5SmROIke/rGTTzdvD3dIhL So9CH2RCOyM42/cZkVCZctfX3SnZRyEKnOVAvQzxwlxHGilsDdqh9pgb1Ifa5irbodsP f8c/I/IT6aBGR2pOQap/8huC+2pi6R3w+bo/cgquXnvB2wr28l1HLjOZPZdAlUFM7e8x 1bHyoy0cGuh4oYyhdlThIo6bX6YvDn0vZMwKMpjFqygksByLpOTnqWe095nrMx2FMqIc tKAZxByqOylZWfYK4d42vNUHB8T+1b9uqwd5O1d2LXAFSqEcJS3NXzAlSommMRNencKi Oczg== X-Gm-Message-State: AA+aEWbkiC0REswnvFkiNDwoD+pj8UMiOYiJ0jS3m+O9Fbh/tZKa14Ll 3MnNy1LRVf8twBI4EFQdDDvcKLweqD9FeP2IKOw= X-Google-Smtp-Source: AFSGD/XPBTnaVHd0EmuLBkvkmk94xUVdtB/oMoxFGzV2r1SsHZDayVR71b2dEoiSEpSBb8npoMzHWNsbOAMlSBxpqEs= X-Received: by 2002:a37:9f87:: with SMTP id i129mr4422469qke.255.1543573962598; Fri, 30 Nov 2018 02:32:42 -0800 (PST) MIME-Version: 1.0 References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> <939858e1-eeff-01a3-fd35-fb3d2bbff6f8@kit.edu> In-Reply-To: <939858e1-eeff-01a3-fd35-fb3d2bbff6f8@kit.edu> From: Luca Muscariello Date: Fri, 30 Nov 2018 11:32:30 +0100 Message-ID: To: mario.hock@kit.edu Cc: "Bless, Roland (TM)" , bloat Content-Type: multipart/alternative; boundary="000000000000b9aeb4057bdf517f" Subject: Re: [Bloat] when does the CoDel part of fq_codel help in the real world? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2018 10:32:43 -0000 --000000000000b9aeb4057bdf517f Content-Type: text/plain; charset="UTF-8" Mario, agreed. Two last comments: one should always used fluid approximation with care, because they are approximations, the real model is more complex. Nobody considers that the RTT varies during the connection lifetime and that ACK can be delayed. So CWD increases in a non simple way. This is one paper I wrote some time ago where you can get to an equilibrium with a desired epsilon in the queue. This protocol and LoLa seem to have similar objectives. https://arxiv.org/pdf/1010.5623.pdf Equations and stability conditions are worth a read. Maybe the equations can be reused for LoLa. As you seem doing something similar, even if the X(t) introduces non regularities which cannot be modelled in a simple way. Maybe yes. In another work G. Carofiglio and L. Muscariello, "On the Impact of TCP and Per-Flow Scheduling on Internet Performance," in *IEEE/ACM Transactions on Networking*, vol. 20, no. 2, pp. 620-633, April 2012. https://doi.org/10.1109/TNET.2011.2164553 I, my co-author actually, did the calculations nobody wants to do to obtain the limit cycle which is pretty messy. They are all fluid approximations. So in practice the target queuing latency can be larger or smaller. These models are useful to get a preliminary idea about how the system works and a publication... On Fri, Nov 30, 2018 at 10:55 AM Mario Hock wrote: > Luca, > > I'm not that happy with the theorem either, since it stresses a > limitation that can actually be overcome. However, I quoted it to > demonstrate there is a challenge involved. > > In my point of view there is actually a subtle thing that's often lost > when modeling the queue based on input rates, output rates, and, e.g., > queuing theory. The inflight data (e.g., controlled by the CWnds) and > the resulting standing queue. But this standing queue is (probably) the > major reasoning behind LoLa and CoDel. > > Let's simplify the situation to single sender, to ease the explanation. > (Also holds for multiple senders.) Let the sender have a CWnd-based > congestion control, but let's fix this CWnd for now. Also, let's assume > the CWnd is larger than the BDP (without queuing delay); CWnd = BDP + x. > > In this case, the sending rate will be above the bottleneck rate, as > long as less than x is queued at the bottleneck. This increases the > queue. As soon as x is queued at the bottleneck, the sending rate will > (exactly) approach the bottleneck rate. The reason is, that the BDP > (with buffering) will now be exactly equal to the CWnd (since the RTT is > increased). > > This means, a standing queue will build up. But as soon as it's there, > sending rate will (on average) be equal to the bottleneck rate. > > There is also a stability condition here. If the queuing delay (for some > reason) falls below x/rate (i.e., amount of queuing falls below x), the > sending rate increases. If the queuing delay raises above x/rate, > sending rate is reduced. Note: That this is all with a fixed CWnd. No > interaction of the congestion control algorithms involved here. > > Therefore, there can be a long living standing queue, even if input == > output. Of course during the build up process input > output, however > this build up can e.g. happen in one RTT, while the standing queue can > survive seconds or minutes (in reality, and indefinitely in theory). > Though, I found that this correlation is often not modeled in > queue-theoretical models. > > Best, Mario > > > Am 29.11.18 um 23:30 schrieb Luca Muscariello: > > Mario, > > > > putting aside LoLa for a second, > > I'm not quite sure that the theorem you cite is valid. > > > > According to the model R_i is the sending rate. > > The sum across all flows bottlenecked at the link does not need to be > > equal to the link capacity. > > The input rate can be instantaneously below or above the link capacity. > > Even If the link is never idle and the output rate is always C for all t. > > > > If the sum_i R_i = C is false because of what I said, than p_i which is > > nothing more than > > the shadow price of the link capacity constraint, can be a function of a > > constant delay d, i.e. p_i = cost * d for all i. > > > > This theorem can be valid only if the input rate of a queue is > > instantaneously equal to the output queue. > > We all know that a queue exists just because there is an instantaneous > > difference of input and output rates > > at the link. So to conclude, this theorem if valid iff input == output > > rate then the queue is always zero, i.e. d=0. > > > > The theorem is either an artefact of the model or just wrong. Or I'm > > missing something... > > > > > > > > > > > > > > On Thu, Nov 29, 2018 at 6:07 PM Mario Hock > > wrote: > > > > Hi Luca, > > > > I'm answering on behalf of Roland, since I am a co-author of the > paper. > > > > This is an excellent question, since it goes right at the heart of > how > > LoLa works. > > > > Indeed, the paper is a first of a series. A second one, looking > deeper > > into the fair flow balancing mechanism, is currently under > submission. > > > > Similar as other delay based congestion controls, LoLa tries to > achieve > > fairness by allowing each flow to buffer the same amount of data at > the > > bottleneck. We have this, e.g., in TCP Vegas, and (in a way) also in > > Copa (a recently proposed congestion control) and many others. If > this > > is achieved, we get flow rate fairness independent of a flow's RTT. > > > > Usually (in other congestion controls) this "allowed amount of data" > is > > fixed per flow. We presume that this approach does not scale well to > > high speed networks. Since the queuing delay resulting from this > amount > > of data is reduced with increasing bottleneck rate. Thus, it becomes > > harder to measure it right. This can easily be seen (and proven) for > > TCP > > Vegas. > > > > Note: Just using higher fixed values is not an option, since it would > > not work at lower speeds anymore and also not with a large number of > > flows. > > > > Therefore, LoLa tries to find a suitable value for the "allowed > amount > > of data" dynamically. This is X(t). > > > > Our approach is to grow X(t) over time during the Fair Flow Balancing > > phase. This phase ends when the queuing delay reaches 5ms. Thus, (in > > the > > ideal case) at the end of Fair Flow Balancing, X(t) is just as large > > that all flows at bottleneck create a queuing delay of 5ms, and all > > flows contribute equally to this queue. Hence, flow rate fairness is > > achieved. (Note that LoLa is designed in a way that t is (almost) > > synchronized among the competing flows.) > > > > Generally, other ways of determining a suitable X(t) are > > conceivable. In > > our approach X(t) is a monotonically increasing function, but it is > > regularly reset as LoLa cycles between its states; i.e., after a > > queuing > > delay of 5ms is reached, the queue is drained and everything starts > > again. (Thus, the timespan where X(t) is monotonically increased is > > called a "round of fair flow balancing".) > > > > This way we can overcome the constraint given in [1]: > > > > """ > > THEOREM 6 (FAIRNESS/DELAY TRADEOFF). For congestion control > mechanisms > > that have steady state throughput of the kind R = f(d, p), for some > > function f, delay d and feedback p, if the feedback is based on > purely > > end to end delay measurements, you can either have fairness or a > fixed > > delay, but not both simultaneously > > """ > > > > [1] "ECN or Delay: Lessons Learnt from Analysis of DCQCN and TIMELY" > > Yibo Zhu et al., https://dl.acm.org/citation.cfm?id=2999593 > > > > Best, Mario > > > > > > Am 29.11.18 um 17:09 schrieb Luca Muscariello: > > > Hi Roland, > > > > > > It took me quite a lot of time to find this message in the > thread... > > > I read the paper you sent and I guess this is the first of a > > series as > > > many things stay uncovered. > > > > > > Just a quick question: why is X(t) always increasing with t? > > > > > > > > > On Tue, Nov 27, 2018 at 11:26 AM Bless, Roland (TM) > > > > > >> wrote: > > > > > > Hi Luca, > > > > > > Am 27.11.18 um 10:24 schrieb Luca Muscariello: > > > > A congestion controlled protocol such as TCP or others, > > including > > > QUIC, > > > > LEDBAT and so on > > > > need at least the BDP in the transmission queue to get > > full link > > > > efficiency, i.e. the queue never empties out. > > > > > > This is not true. There are congestion control algorithms > > > (e.g., TCP LoLa [1] or BBRv2) that can fully utilize the > > bottleneck link > > > capacity without filling the buffer to its maximum capacity. > > The BDP > > > rule of thumb basically stems from the older loss-based > > congestion > > > control variants that profit from the standing queue that > > they built > > > over time when they detect a loss: > > > while they back-off and stop sending, the queue keeps the > > bottleneck > > > output busy and you'll not see underutilization of the link. > > Moreover, > > > once you get good loss de-synchronization, the buffer size > > requirement > > > for multiple long-lived flows decreases. > > > > > > > This gives rule of thumbs to size buffers which is also > very > > > practical > > > > and thanks to flow isolation becomes very accurate. > > > > > > The positive effect of buffers is merely their role to absorb > > > short-term bursts (i.e., mismatch in arrival and departure > rates) > > > instead of dropping packets. One does not need a big buffer to > > > fully utilize a link (with perfect knowledge you can keep the > > link > > > saturated even without a single packet waiting in the buffer). > > > Furthermore, large buffers (e.g., using the BDP rule of thumb) > > > are not useful/practical anymore at very high speed such as > > 100 Gbit/s: > > > memory is also quite costly at such high speeds... > > > > > > Regards, > > > Roland > > > > > > [1] M. Hock, F. Neumeister, M. Zitterbart, R. Bless. > > > TCP LoLa: Congestion Control for Low Latencies and High > > Throughput. > > > Local Computer Networks (LCN), 2017 IEEE 42nd Conference on, > pp. > > > 215-218, Singapore, Singapore, October 2017 > > > http://doc.tm.kit.edu/2017-LCN-lola-paper-authors-copy.pdf > > > > > > > Which is: > > > > > > > > 1) find a way to keep the number of backlogged flows at a > > > reasonable value. > > > > This largely depends on the minimum fair rate an > > application may > > > need in > > > > the long term. > > > > We discussed a little bit of available mechanisms to > > achieve that > > > in the > > > > literature. > > > > > > > > 2) fix the largest RTT you want to serve at full > > utilization and size > > > > the buffer using BDP * N_backlogged. > > > > Or the other way round: check how much memory you can use > > > > in the router/line card/device and for a fixed N, compute > > the largest > > > > RTT you can serve at full utilization. > > > > > > > > 3) there is still some memory to dimension for sparse > flows in > > > addition > > > > to that, but this is not based on BDP. > > > > It is just enough to compute the total utilization of > sparse > > > flows and > > > > use the same simple model Toke has used > > > > to compute the (de)prioritization probability. > > > > > > > > This procedure would allow to size FQ_codel but also SFQ. > > > > It would be interesting to compare the two under this > > buffer sizing. > > > > It would also be interesting to compare another mechanism > > that we > > > have > > > > mentioned during the defense > > > > which is AFD + a sparse flow queue. Which is, BTW, already > > > available in > > > > Cisco nexus switches for data centres. > > > > > > > > I think that the the codel part would still provide the > > ECN feature, > > > > that all the others cannot have. > > > > However the others, the last one especially can be > > implemented in > > > > silicon with reasonable cost. > > > > > > > > > _______________________________________________ > > > Bloat mailing list > > > Bloat@lists.bufferbloat.net > > > https://lists.bufferbloat.net/listinfo/bloat > > > > > > --000000000000b9aeb4057bdf517f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ma= rio,=C2=A0

agreed.
Two last comments: on= e should always used fluid approximation with care, because they are approx= imations,=C2=A0
the real model is more complex. Nobody considers = that the RTT varies during the connection lifetime and that ACK can be dela= yed.
So CWD increases in a non simple way.

This is one paper I wrote some time=C2=A0ago where you can get to an equ= ilibrium with a desired epsilon in the queue.
This protocol and L= oLa seem to have similar objectives.


Equations and stability conditions are worth a= read. Maybe the equations can be reused for LoLa. As you seem doing someth= ing similar,
even if the X(t) introduces non regularities which c= annot=C2=A0 be modelled in a simple way. Maybe yes.

In another work

G. Carofiglio and L. Muscariello, "= ;On the Impact of TCP and Per-Flow Scheduling on Internet Performance,"= ;=C2=A0
in=C2=A0IEEE/ACM Transactions on Networking, vol. 20, no. 2, = pp. 620-633, April 2012.=C2=A0

=
I, my co-author actually, did the calculations nobody wants to do to o= btain the limit cycle which is pretty messy.
They are all fluid a= pproximations. So in practice the target queuing latency can be larger or s= maller.
These models are useful to get a preliminary idea abo= ut how the system works and a publication...


<= /div>


=
On Fri, Nov 30, 2018 at 10:55 AM Mario Hock <mario.hock@kit.edu> wrote:
Luca,

I'm not that happy with the theorem either, since it stresses a
limitation that can actually be overcome. However, I quoted it to
demonstrate there is a challenge involved.

In my point of view there is actually a subtle thing that's often lost =
when modeling the queue based on input rates, output rates, and, e.g.,
queuing theory. The inflight data (e.g., controlled by the CWnds) and
the resulting standing queue. But this standing queue is (probably) the major reasoning behind LoLa and CoDel.

Let's simplify the situation to single sender, to ease the explanation.=
(Also holds for multiple senders.) Let the sender have a CWnd-based
congestion control, but let's fix this CWnd for now. Also, let's as= sume
the CWnd is larger than the BDP (without queuing delay); CWnd =3D BDP + x.<= br>
In this case, the sending rate will be above the bottleneck rate, as
long as less than x is queued at the bottleneck. This increases the
queue. As soon as x is queued at the bottleneck, the sending rate will
(exactly) approach the bottleneck rate. The reason is, that the BDP
(with buffering) will now be exactly equal to the CWnd (since the RTT is increased).

This means, a standing queue will build up. But as soon as it's there, =
sending rate will (on average) be equal to the bottleneck rate.

There is also a stability condition here. If the queuing delay (for some reason) falls below x/rate (i.e., amount of queuing falls below x), the sending rate increases. If the queuing delay raises above x/rate,
sending rate is reduced. Note: That this is all with a fixed CWnd. No
interaction of the congestion control algorithms involved here.

Therefore, there can be a long living standing queue, even if input =3D=3D =
output. Of course during the build up process input > output, however this build up can e.g. happen in one RTT, while the standing queue can
survive seconds or minutes (in reality, and indefinitely in theory).
Though, I found that this correlation is often not modeled in
queue-theoretical models.

Best, Mario


Am 29.11.18 um 23:30 schrieb Luca Muscariello:
> Mario,
>
> putting aside LoLa for a second,
> I'm not quite sure that the theorem you cite is valid.
>
> According to the model R_i is the sending rate.
> The sum across all flows bottlenecked at the link does not need to be =
> equal to the link capacity.
> The input rate can be instantaneously below or above the link capacity= .
> Even If the link is never idle and the output rate is always C for all= t.
>
> If the sum_i R_i =3D C is false because of what I said, than p_i which= is
> nothing more than
> the shadow price of the link capacity constraint, can be a function of= a
> constant delay d, i.e. p_i =3D cost * d for all i.
>
> This theorem can be valid only if the input rate of a queue is
> instantaneously equal to the output queue.
> We all know that a queue exists just because there is an instantaneous=
> difference of input and output rates
> at the link. So to conclude,=C2=A0 this theorem if valid iff input =3D= =3D output
> rate then the queue is always zero, i.e.=C2=A0 d=3D0.
>
> The theorem is either an artefact of the model or just wrong. Or I'= ;m
> missing something...
>
>
>
>
>
>
> On Thu, Nov 29, 2018 at 6:07 PM Mario Hock <mario.hock@kit.edu
> <mailto:mar= io.hock@kit.edu>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Luca,
>
>=C2=A0 =C2=A0 =C2=A0I'm answering on behalf of Roland, since I am a= co-author of the paper.
>
>=C2=A0 =C2=A0 =C2=A0This is an excellent question, since it goes right = at the heart of how
>=C2=A0 =C2=A0 =C2=A0LoLa works.
>
>=C2=A0 =C2=A0 =C2=A0Indeed, the paper is a first of a series. A second = one, looking deeper
>=C2=A0 =C2=A0 =C2=A0into the fair flow balancing mechanism, is currentl= y under submission.
>
>=C2=A0 =C2=A0 =C2=A0Similar as other delay based congestion controls, L= oLa tries to achieve
>=C2=A0 =C2=A0 =C2=A0fairness by allowing each flow to buffer the same a= mount of data at the
>=C2=A0 =C2=A0 =C2=A0bottleneck. We have this, e.g., in TCP Vegas, and (= in a way) also in
>=C2=A0 =C2=A0 =C2=A0Copa (a recently proposed congestion control) and m= any others. If this
>=C2=A0 =C2=A0 =C2=A0is achieved, we get flow rate fairness independent = of a flow's RTT.
>
>=C2=A0 =C2=A0 =C2=A0Usually (in other congestion controls) this "a= llowed amount of data" is
>=C2=A0 =C2=A0 =C2=A0fixed per flow. We presume that this approach does = not scale well to
>=C2=A0 =C2=A0 =C2=A0high speed networks. Since the queuing delay result= ing from this amount
>=C2=A0 =C2=A0 =C2=A0of data is reduced with increasing bottleneck rate.= Thus, it becomes
>=C2=A0 =C2=A0 =C2=A0harder to measure it right. This can easily be seen= (and proven) for
>=C2=A0 =C2=A0 =C2=A0TCP
>=C2=A0 =C2=A0 =C2=A0Vegas.
>
>=C2=A0 =C2=A0 =C2=A0Note: Just using higher fixed values is not an opti= on, since it would
>=C2=A0 =C2=A0 =C2=A0not work at lower speeds anymore and also not with = a large number of
>=C2=A0 =C2=A0 =C2=A0flows.
>
>=C2=A0 =C2=A0 =C2=A0Therefore, LoLa tries to find a suitable value for = the "allowed amount
>=C2=A0 =C2=A0 =C2=A0of data" dynamically. This is X(t).
>
>=C2=A0 =C2=A0 =C2=A0Our approach is to grow X(t) over time during the F= air Flow Balancing
>=C2=A0 =C2=A0 =C2=A0phase. This phase ends when the queuing delay reach= es 5ms. Thus, (in
>=C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0ideal case) at the end of Fair Flow Balancing, X(t)= is just as large
>=C2=A0 =C2=A0 =C2=A0that all flows at bottleneck create a queuing delay= of 5ms, and all
>=C2=A0 =C2=A0 =C2=A0flows contribute equally to this queue. Hence, flow= rate fairness is
>=C2=A0 =C2=A0 =C2=A0achieved. (Note that LoLa is designed in a way that= t is (almost)
>=C2=A0 =C2=A0 =C2=A0synchronized among the competing flows.)
>
>=C2=A0 =C2=A0 =C2=A0Generally, other ways of determining a suitable X(t= ) are
>=C2=A0 =C2=A0 =C2=A0conceivable. In
>=C2=A0 =C2=A0 =C2=A0our approach X(t) is a monotonically increasing fun= ction, but it is
>=C2=A0 =C2=A0 =C2=A0regularly reset as LoLa cycles between its states; = i.e., after a
>=C2=A0 =C2=A0 =C2=A0queuing
>=C2=A0 =C2=A0 =C2=A0delay of 5ms is reached, the queue is drained and e= verything starts
>=C2=A0 =C2=A0 =C2=A0again. (Thus, the timespan where X(t) is monotonica= lly increased is
>=C2=A0 =C2=A0 =C2=A0called a "round of fair flow balancing".)=
>
>=C2=A0 =C2=A0 =C2=A0This way we can overcome the constraint given in [1= ]:
>
>=C2=A0 =C2=A0 =C2=A0"""
>=C2=A0 =C2=A0 =C2=A0THEOREM 6 (FAIRNESS/DELAY TRADEOFF). For congestion= control mechanisms
>=C2=A0 =C2=A0 =C2=A0that have steady state throughput of the kind R =3D= f(d, p), for some
>=C2=A0 =C2=A0 =C2=A0function f, delay d and feedback p, if the feedback= is based on purely
>=C2=A0 =C2=A0 =C2=A0end to end delay measurements, you can either have = fairness or a fixed
>=C2=A0 =C2=A0 =C2=A0delay, but not both simultaneously
>=C2=A0 =C2=A0 =C2=A0"""
>
>=C2=A0 =C2=A0 =C2=A0[1] "ECN or Delay: Lessons Learnt from Analysi= s of DCQCN and TIMELY"
>=C2=A0 =C2=A0 =C2=A0Yibo Zhu et al., https://dl.acm.= org/citation.cfm?id=3D2999593
>
>=C2=A0 =C2=A0 =C2=A0Best, Mario
>
>
>=C2=A0 =C2=A0 =C2=A0Am 29.11.18 um 17:09 schrieb Luca Muscariello:
>=C2=A0 =C2=A0 =C2=A0 > Hi Roland,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > It took me quite a lot of time to find this m= essage in the thread...
>=C2=A0 =C2=A0 =C2=A0 > I read the paper you sent and I guess this is= the first of a
>=C2=A0 =C2=A0 =C2=A0series as
>=C2=A0 =C2=A0 =C2=A0 > many things stay uncovered.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Just a quick question: why is X(t) always inc= reasing with=C2=A0 t?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Tue, Nov 27, 2018 at 11:26 AM Bless, Rolan= d (TM)
>=C2=A0 =C2=A0 =C2=A0 > <roland.bless@kit.edu <mailto:roland.bless@kit.edu>
>=C2=A0 =C2=A0 =C2=A0<mailto:roland.bless@kit.edu <mailto:roland.bless@kit.edu>>> w= rote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Hi Luca,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Am 27.11.18 um 10:24 schri= eb Luca Muscariello:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > A congestion control= led protocol such as TCP or others,
>=C2=A0 =C2=A0 =C2=A0including
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0QUIC,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > LEDBAT and so on
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > need at least the BD= P in the transmission queue to get
>=C2=A0 =C2=A0 =C2=A0full link
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > efficiency, i.e. the= queue never empties out.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0This is not true. There ar= e congestion control algorithms
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0(e.g., TCP LoLa [1] or BBR= v2) that can fully utilize the
>=C2=A0 =C2=A0 =C2=A0bottleneck link
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0capacity without filling t= he buffer to its maximum capacity.
>=C2=A0 =C2=A0 =C2=A0The BDP
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0rule of thumb basically st= ems from the older loss-based
>=C2=A0 =C2=A0 =C2=A0congestion
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0control variants that prof= it from the standing queue that
>=C2=A0 =C2=A0 =C2=A0they built
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0over time when they detect= a loss:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0while they back-off and st= op sending, the queue keeps the
>=C2=A0 =C2=A0 =C2=A0bottleneck
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0output busy and you'll= not see underutilization of the link.
>=C2=A0 =C2=A0 =C2=A0Moreover,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0once you get good loss de-= synchronization, the buffer size
>=C2=A0 =C2=A0 =C2=A0requirement
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0for multiple long-lived fl= ows decreases.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > This gives rule of t= humbs to size buffers which is also very
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0practical
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > and thanks to flow i= solation becomes very accurate.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0The positive effect of buf= fers is merely their role to absorb
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0short-term bursts (i.e., m= ismatch in arrival and departure rates)
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0instead of dropping packet= s. One does not need a big buffer to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0fully utilize a link (with= perfect knowledge you can keep the
>=C2=A0 =C2=A0 =C2=A0link
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0saturated even without a s= ingle packet waiting in the buffer).
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Furthermore, large buffers= (e.g., using the BDP rule of thumb)
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0are not useful/practical a= nymore at very high speed such as
>=C2=A0 =C2=A0 =C2=A0100 Gbit/s:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0memory is also quite costl= y at such high speeds...
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0Roland
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0[1] M. Hock, F. Neumeister= , M. Zitterbart, R. Bless.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0TCP LoLa: Congestion Contr= ol for Low Latencies and High
>=C2=A0 =C2=A0 =C2=A0Throughput.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Local Computer Networks (L= CN), 2017 IEEE 42nd Conference on, pp.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0215-218, Singapore, Singap= ore, October 2017
>=C2=A0 =C2=A0 =C2=A0 > http://doc.t= m.kit.edu/2017-LCN-lola-paper-authors-copy.pdf
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Which is:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 1) find a way to kee= p the number of backlogged flows at a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0reasonable value.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > This largely depends= on the minimum fair rate an
>=C2=A0 =C2=A0 =C2=A0application may
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0need in
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > the long term.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > We discussed a littl= e bit of available mechanisms to
>=C2=A0 =C2=A0 =C2=A0achieve that
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0in the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > literature.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 2) fix the largest R= TT you want to serve at full
>=C2=A0 =C2=A0 =C2=A0utilization and size
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > the buffer using BDP= * N_backlogged.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Or the other way rou= nd: check how much memory you can use
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > in the router/line c= ard/device and for a fixed N, compute
>=C2=A0 =C2=A0 =C2=A0the largest
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > RTT you can serve at= full utilization.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 3) there is still so= me memory to dimension for sparse flows in
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0addition
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > to that, but this is= not based on BDP.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > It is just enough to= compute the total utilization of sparse
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0flows and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > use the same simple = model Toke has used
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > to compute the (de)p= rioritization probability.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > This procedure would= allow to size FQ_codel but also SFQ.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > It would be interest= ing to compare the two under this
>=C2=A0 =C2=A0 =C2=A0buffer sizing.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > It would also be int= eresting to compare another mechanism
>=C2=A0 =C2=A0 =C2=A0that we
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0have
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > mentioned during the= defense
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > which is AFD=C2=A0+ = a sparse flow queue. Which is, BTW, already
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0available in
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Cisco nexus switches= for data centres.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > I think that the the= codel part would still provide the
>=C2=A0 =C2=A0 =C2=A0ECN feature,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > that all the others = cannot have.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > However the others, = the last one especially can be
>=C2=A0 =C2=A0 =C2=A0implemented in
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > silicon with reasona= ble cost.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > _____________________________________________= __
>=C2=A0 =C2=A0 =C2=A0 > Bloat mailing list
>=C2=A0 =C2=A0 =C2=A0 > Bloat@lists.bufferbloat.net <mailto:Bloat@lists.bufferbloa= t.net>
>=C2=A0 =C2=A0 =C2=A0 > https://lists.bufferbloat.= net/listinfo/bloat
>=C2=A0 =C2=A0 =C2=A0 >
>
--000000000000b9aeb4057bdf517f--