Hi =
Jeff,

Ok.

Augmentation is certainly one way to make the binding, =
but may not be the only way. I propose that the TCP model include a =
reference to the keychain model. As modified, there is now a keychain =
reference on a per connection basis that can be used for either TCP-AO =
or MD5. Here is what the modified tree diagram looks like:

=
--Apple-Mail=_61E74A87-7557-4B4C-AB41-378A6B663586--
From nobody Fri Apr 15 08:38:58 2022
Return-Path: On Mar 2, 2022, at 6:04 AM, Jeffrey Haas = <jhaas@pfrc.org> = wrote:

+ The binding between a send-id and = receive-id likely belong in the

keychain. = This likely requires augmenting the keychain model.Did you mean binding between tcp-ao and the = keychain model it is using?

I = mean that send-id/receive-id state likely belongs in an individual = keychain entry. That means the keychain model needs augmenting. = The augmentation can be sourced from the tcpm RFC.

[ms] That solution (used by all known router = implementations) is already explicitly explained in = draft-ietf-tcpm-yang-tcp-06 as follows: =E2=80=9CThe keychain for TCP-AO = can be modeled by the YANG Data Model for Key Chains [RFC8177]. The = groupings defined in this document can be imported and used as part of = such a preconfiguration.=E2=80=9D

I don't find the example clear. = As noted above, configuration state in

existing implementations = requires a binding of a send-id and a receive-id

(TCP-AO configuration state) to = the keychain entry.

[ms] Now, the challenge is that this = solution would require an update to RFC8177, and I don=E2=80=99t know if = and when this would happen. One option would just to define the grouping = in draft-ietf-tcpm-yang-tcp and do not define its use in the keychain, = i.e., to leave that open until a 8177bis document is done. We tried to = find an alternative that can work with the existing RFC8177 model = instead. That does not prevent use of the grouping in a future key-chain = standard.

I will, perhaps unpopularly, argue that its dereliction of = duty to throw

your hands up = and say "we can't get our responsible component to work

because of someone else's = work".

If you own = the YANG model for TCP-AO, you're responsible for figuring out

how it should work.

If you can do it solely within = your module, this is easy and done.

What is far more likely is that TCP-AO state needs to be = coupled in with the

keychain. If this can be done in a way that lets you = satisfy providing a

useful model for TCP-AO by augmenting the keychain model, = that's a

reasonable = path forward. Simply defining a grouping isn't the full = extent

of the work, = defining the augmentation would be.

+--rw tcp!

=
+--rw connections

| +--rw =
connection*

| =
[local-address remote-address local-port =
remote-port]

| +--rw =
local-address inet:ip-address

=
| +--rw remote-address =
inet:ip-address

| =
+--rw local-port =
inet:port-number

| =
+--rw remote-port inet:port-number

=
=E2=80=A6.. <stuff deleted>

=
| +--rw authentication

=
| +--rw keychain?

=
| | =
key-chain:key-chain-ref

| =
+--rw (authentication)?

| =
+--:(ao)

=
| | +--rw enable-ao? =
boolean

=
| | +--rw send-id? =
uint8

=
| | +--rw recv-id? =
uint8

=
| | +--rw =
include-tcp-options? boolean

| =
| +--rw accept-key-mismatch? =
boolean

| =
| +--ro r-next-key-id? =
uint8

| =
+--:(md5)

| =
+--rw enable-md5? =
boolean

The example in the =
draft has been updated to reflect this change. Let me know if this looks =
good. The full set of changes can be found here.

Separately, the =
BGP YANG model can now remove the container for secure-session, leaving =
it up to this model to define how a TCP connection is =
secured.

If your analysis (because you're the group with the = expertise) is that

configuration of TCP-AO does require binding of configuration = state from

TCP-AO into = the keychain, but the keychain has structural issues that

prevent this from being current = viable, IETF as a whole has a problem: The

modules don't inter-work.

What should IETF do when such inter-work issues are = identified? Fix them.

What should tcpm or other Working Groups do about = configuration state if

such inter-work issues are identified? Perhaps hold up = publishing your

model until it can be fixed - the process for fixing YANG = models is painful

even for trivial things much less things that will require = restructuring.

Alternatively, if operational state is fine, perhaps = configuration state is

deferred to a later model while working through the issue = with the other

dependent Working Groups.[ms] I agree that a TCP connection = will typically *not* be set up by configuration state but instead by the = socket APO. Thus the connection list is most likely operational state = only. The unknown is how TCP-AO configuration would be provisioned in = that case. If it is indeed done by the key-chain, we may not require = corresponding configuration state in draft-ietf-tcpm-yang-tcp.

That's a possible way this goes.

But if the answer is that it = belongs in the keychain model and the

configuration state is motivated by TCP-AO, it's reasoanble = this Working

Group = supplies that model. Alternatively, this Working Group initiates = the

inter-working = group discussion to solve the broader problem.

Such inter-work discussions are = effectively why I'm here wearing my BGP YANG

hat. :-)

Hi=C2=A0Markku, Bob,

Sorry f=
or my slow=C2=A0response.=C2=A0

Also, thank=C2=A0you so much for =
the very detailed explanations.

Based on them, I agree that we ca=
n say the model used for Reno-Friendly region is unvalidated for=C2=A0both =
tail drop and AQM cases.

This could be a problem for CUBIC, howev=
er, I have two opinions on this.

1: I think the mo=
del is unvalidated, but at the same time, I haven't seen a solid analys=
is on how bad it is.

=C2=A0 =C2=A0 It appears to be more aggressi=
ve than=C2=A0NewReno, but we would like to understand whether this is a ser=
ious=C2=A0threat or something negligible.=C2=A0

=C2=A0 =C2=A0 I t=
hink we will need detailed=C2=A0packet dynamics analysis for this, which se=
ems to be a long-term research topic to me.

=C2=A0 =C2=A0=C2=A0

2: I am a bit w=
ondering about the=C2=A0impact of the=C2=A0model when=C2=A0Reno and CUBIC c=
ompete.
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649AE3A1EE5; Sun, 17 Apr 2022 22:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ko_NUhOL-tJK; Sun, 17 Apr 2022 22:03:49 -0700 (PDT)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3179E3A1EDF; Sun, 17 Apr 2022 22:03:49 -0700 (PDT)
Received: by mail-ot1-x329.google.com with SMTP id 88-20020a9d0ee1000000b005d0ae4e126fso9220317otj.5; Sun, 17 Apr 2022 22:03:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=MR4yoCGzWKmXkcOQKTZe08/LWU6ms1zG764AOugEhxw=; b=k31XGCB7fOUEtTtTy/RfHqq6qPJN8xtEdqaq5g/ItVA19NYzCmrX7w6BXZMdbMwX1V qXOQScTnGgSTYBywgE+I89TGX/tW9L1lGrjkdH0+E4mB/qxlKEfh1P605VJal/LkBIPF kGdF6DlS32hL9QO6SF9L+gE53FxBFcBf3ZtDcBzgHEp5SHBhkQR7+Wt7wXww/ANuXEyo koPrMkWlQCXW4G9OiMRTIMjkAaQJEMyP+UpZ3ybYZuhoZIoG9Yoe9lo0K7Jb0u86N7tv WGjqbR14yjyx0klwcFhyEUgW94TjVp4v1Fee4c7KpMAV7stvgcYWsnXXRcjwl0IHHhrg R/+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=MR4yoCGzWKmXkcOQKTZe08/LWU6ms1zG764AOugEhxw=; b=jVuWhp74DKx5tVsDtoVGXW1j/p/MZ/rEKdNUG73SzUOMG/24NZMUMkxBng76Xy3Abz 3mIukFch/1O9uUZGMFPp2OyXyz/IzUUEA8JRbkxC6+nUSu6ZEPqOaCCZaSBgC0tjlVoc +2P/gTMRioPK6pBqNbI5jfngi3rO8bp/XvwXRMkkSCdJMbr3zxxcDxODMLXTV+Kx3v1+ hvbhIxsoK83wmgGwHGB7T7hFFbXDMqzzRpDceZAhPFJEg1PLAH/s3ARSVVzW9Ct68IQz 3fcONYiPlywgU4t4yCTzgdy1OwNgdwCY7neMwAKde+7wkMxWDG4QD9fUkdmlVlbit+24 k3Kw==
X-Gm-Message-State: AOAM533jWa2EXJa9hAYv1ngFQr0oHpaaweINutGUZN/grE4ov+Pxk4k9 Kzdbs+L1cplrSZEI68xNxwG8lRLsF96tc/1/9sOeFXsY
X-Google-Smtp-Source: ABdhPJzfXheUM3Qc4OFWNC4mU+XMyBrr9ApdU9AxfzvEhVK8Vb00f/hzYnPqwrD5VbDQJQ2umppYl5khaLEmeeWlw8A=
X-Received: by 2002:a9d:1b68:0:b0:5c9:5da1:3752 with SMTP id l95-20020a9d1b68000000b005c95da13752mr3341642otl.354.1650258227934; Sun, 17 Apr 2022 22:03:47 -0700 (PDT)
MIME-Version: 1.0
From: Yoshifumi Nishida
Date: Sun, 17 Apr 2022 22:03:37 -0700
Message-ID:
To: "tcpm@ietf.org Extensions"
Cc: tcpm-chairs
Content-Type: multipart/alternative; boundary="00000000000076b98d05dce6afce"
Archived-At:
Subject: [tcpm] Proceeding CUBIC draft
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 18 Apr 2022 05:03:56 -0000
--00000000000076b98d05dce6afce
Content-Type: text/plain; charset="UTF-8"
Hi folks,
I think we've seen a solid consensus to publish the CUBIC draft as a PS doc
during the last WG meeting. So, the chairs are thinking about proceeding in
this direction.
It seems to me that the remaining point of the draft is whether we add some
texts to the doc or publish it as it is. In my impression, it seems that
more people prefer to add some texts.
In case of adding some texts, we would like to understand what they will be.
Do we add the discussion points that Markku and Bob raised or we would like
to mention that CUBIC has been deployed without IETF process, or something
else?
We appreciate your feedback on this point or anything related to the doc
and the process.
--
Yoshi
--00000000000076b98d05dce6afce
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=C2=A0 =C2=A0 As CUBIC has already been deployed for years while w=
e haven't seen significant=C2=A0troubles, I think this is not an issue =
that requires immediate actions.

=C2=A0 =C2=A0 So, I think w=
e can just continue discussions and analysis for now and create a solution =
or a remedy once we identify the issue.

=C2=A0 =C2=A0 I think Reno-Friendly=C2=A0region in CUBIC =
will only be used when w_max > cwnd.=C2=A0

=C2=A0 =C2=A0 Howev=
er, I am not sure how much CUBIC's cwnd can grow more than w_max in com=
petitive situations.

=C2=A0 =C2=A0 This might also require detail=
ed packet dynamics analysis, but I think we'll need to think about this=
point while analyzing the validity of CUBIC's logics.=C2=A0 =C2=A0

--000000000000137b9805dce6a93f--
From nobody Sun Apr 17 22:03:57 2022
Return-Path: Thanks,

--

Yoshi

On Tue, Mar 22, 2=
022 at 9:47 AM Markku Kojo <kojo@cs.helsinki.fi> wrote:

Hi Yoshi, Bob, all,

below please find my understanding of and feedback on Bob's report

(https://raw.githubuserconten= t.com/bbriscoe/cubic-reno/main/creno_tr.pdf).

This hopefully also clarifies what I meant when saying that the equation[in the draft] assumes equal drop probability for the different values of <= br> alpha and beta but the drop probability actually changes when these

values are changed from alpha=3D1, beta =3D 0.5. I have also thought this a=

bit more after reading Bob's report and include my understanding of why=

the performance with C-Reno and Reno differ in case of AQM.

In brief, the model for steady state behavior for the Reno-friendly

region in a tail-drop queue indeed is incorrect when the additive

increase factor alpha < 1 is applied for an alternate AIMD(a, b) TCP.This is because the packet dynamics and behavior of TCP that injects more <= br> packets only when cwnd has increased by at least one MSS. This differs

from the assumptions of the model and what Bob has used in his analysis

(see more below). Also the AQM case remains unvalidated, my reasoning

differs, or extends, somewhat the reasoning that Bob gave in his report.

The math itself in the original paper [FHP00] which the CUBIC

TCP-friendly region is based on seems correct, likewise the math in Bob'= ;s

report as well as in Yoshi's explanation below:

>=C2=A0 Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:

>

> Also, in one congestion epoch, (=CE=B1=3D1.0,=C2=A0 =CE=B2 =3D0.5) inc= reases 0.5 W1 while

> (=CE=B1=3DX,=C2=A0 =CE=B2 =3D0.7) increases 0.3 W2

> Now, if=C2=A0we define the congestion epoch as e RTTs, e =3D 0.5 W1 / = 1.0=C2=A0 and

> also e =3D 0.3 W2 / X

> This means, X should satisfy

>=C2=A0 0.5 W1 /1.0=C2=A0 =3D 0.3 * 1.5/1.7 W1/ X

> then we get X =3D 0.529.

> This will mean if we launch (=CE=B1=3D1.0,=C2=A0 =CE=B2 =3D0.5) and (= =CE=B1=3D0.529,=C2=A0 =CE=B2 =3D0.7)

> at the same time and reduce them when the sum of their windows

> becomes Wmax, the throughput of them will mostly be the same.

I'll try to explain the problems with the model separately for a tail-d= rop

and AQM queue.

1. Tail-drop queue (*)

The problem with the use of the formula in the original paper as well asin Bob's and Yoshi's analyses is, like it often easily happens, tha= t the

theoretical model that has been derived in one context using certain

assumptions is reused in another context where the assumptions do not

hold, i.e, the model does not match the reality.

In this case, the correct use of formula presumes that the drop

probability is the same (on the average) for a standard TCP =3D AIMD(1,1/2)=

and AIMD(a,b). That is implicitly assumed also in Bob's report for

synchronized (tail drop) case as Bob's math is derived using the same <= br> number of packets over a cycle (=3D in between drops, which is reciprocal <= br> of drop rate). (Btw, involving RTT in the calculations is unnecessary asall competing flows see the same queue on every RTT, so RTT is the same

for all flows sharing the same queue, assuming the base RTT for the flows <= br> is the same). Also, Yoshi's calculations above effectively make the sam= e

assumption that both flows reduce cwnd at the same time ("when the sum= of

their windows becomes Wmax").

To understand the difference, we need to look at the packet dynamics of

flows competing in a tail drop queue, not just the math. The assumption

of equal drop probability holds for any two (or n) AIMD(1, 1/2) TCPs

competing on a shared bottleneck: when the bottleneck tail drop buffer

becomes full towards the end of a cycle (on RTT n), both TCPs increase

their cwnd by 1 for the RTT n+1 and inject two back-to-back pkts

resulting in a drop of 1 pkt each (the latter pkt of the two back-to-back <= br> pkts =3D the excess pkt according to packet conservation rule becomes

dropped). When an AIMD(1, 1/2) TCP competes with an AIMD(a=3D0.53, b=3D0.7)=

TCP (=3DCUBIC) and the tail drop buffer becomes full on RTT n, the

AIMD(1,1/2) TCP increases its cwnd by 1 on RTT n+1 and gets 1 pkt

dropped. However, AIMD(0.53,0.7) TCP increases its cwnd by 0.53 and

only injects an excess packet on RTT n+1 roughly every second cycle

because a TCP sender does not inject an additional packet until cwnd hasincreased by at least by 1 MSS.

Hence, in a synchronized case the AIMD(0.53, 0.7) TCP avoids a packet

drop and cwnd reduction roughly every second cycle and is able to extendits cycle because the competing AIMD(1, 1/2) TCP reduced its cwnd on RTTn+1 and the bottleneck buffer is not anymore full on RTT n+2 when

AIMD(0.53,0.7) TCP injects its additional packet (and would encounter a

pkt drop only if the queue is full).

Because the cycle is systematically extended in this way for AIMD(0,53,

0.7) (=3DCUBIC in Reno-friendly mode), it increases the average number of <= br> pkts between drops and thereby decreases the drop probility of CUBIC to

be lower than that of the competing AIMD (1, 1/2) TCP. These packet

dynamics breaks the model.

So, the basic problem is that the model used for the Reno-friendly

region obviously is not valid. The results in the original paper [FHP00]do not support the validity of the model either and I am not aware that

the model would have been validated by anyone.

A good, unresolved question is why the simulation results in the

original paper [FHP00] gave lower throughput for AIMD(1/5, 7/8)

(denoted as AIMD(1/5, 1/8) in the original paper) for the AQM case.

Note that the paper did not give lower throughput for AIMD(1/5, 1/8) with <= br> a tail drop bottleneck as the results in the paper were shown only for an <= br> AQM bottleneck and the paper just said the results for tail drop are

similar which is a vague expression; it may also mean that he results

were reversed with similar difference in throughput? Anyway, the resultsobviously did not validate the model.

Bob's explanation for the reason why C-Reno's packet rate decreases= is

correct but what would happen if the buffer was not deep enough and

drained out seems not all correct. The packet rate is the relative shareon a shared bottleneck link with fixed capacity. The cwnd of the C-Reno

flow is larger than that of Reno in the beginning of the cycle, becomes

equal in the middle, and stays increasingly behind for the rest of the

cycle. Therefore, C-Reno's *proportional* share decreases during thecycle; the overall througput is the same all the time and bounded by thelink capacity.

If the buffer was not deep enough and drained out, the relative packet

rate between the two flows still behaves the same even if there is no

queue and also when the link is underutilized for the beginning of the

cycle. When the link is underutilized, the pkt rate increases for both

flows until the link becomes fully utilized (note that RTT does not

change when the link is underutilized). The pkt rate of C-Reno

would increase slower though but it won't change its proportinal share,=

i.e., C-Reno will not suffer more unlike Bob suggests. The overall average =

rate is lower in such a case because the link is underutilized for the

beginning of the cycle.

AQM queue:

Bob's explanation for AQM case seems pretty much being on the correct <= br> track.

In the AQM case the desynchronization of the flows is merely guaranteed

for low level of multiplexing. I agree with Bob that modelling AQM

case is hard and it also depends on the AQM in use. I also agree Bob's =

analysis that towards the end of a cycle a probabilistic AQM is more

likely to hit Reno somewhat more often than C-Reno. On the other hand,

with desynchronized flows the AQM may hit any flow irrespective of its

phase. Therefore, the AQM is more likely to hit C-Reno towards the

beginning of its cycle somewhat more often than Reno because C-Reno's <= br> pkt rate is then higher than that of Reno, and a hit in the beginning ofthe cycle hurts the performance much more than in the end of

the cycle. A hit in the beginning of the cycle results in a cwnd value

that is significantly lower than in the beginning of the previous cycle

while a hit towards the end of cycle results in a cwnd value much closerto that in the beginning of the previous cycle (the behavious the

resembles steady state regular cycle). This might explain, at least in

part, the lower throughput for C-Reno in AQM case.

I think that an additional possible explanation for the discrepancy in

the original paper is that possibly something was wrong with the

simulation implementation, or maybe in the simulation parameters. Not all <= br> parameters were exposed in the paper. The results also seem not to

involve any replications, so we cannot expect statistical validity from

the results, a part of the story may be explained just by random effects.

In addition, the reasons for the discrepancy speculated in the original

paper seem likely to be correct:

=C2=A0 "One factor could be the assumption of regular, deterministic=C2=A0 =C2=A0drops in the deterministic model; another factor could be the<= br> =C2=A0 =C2=A0role played by retransmit timeouts for TCP in regimes with

=C2=A0 =C2=A0high packet drop rates."

The first one above means the incorrect assumption that drop

probabilities are the same. Moreover, the role of RTOs is definitely onepotential reason with the high number of competing flows as the model

considers the regular steady-state only.

So, in summary, the AQM case clearly remains unvalidated as well, or thevalidation in the original paper actually shows that the model is not

correct.

An additional problem with the incorrect model is that it tends to result <= br> is overaggressive CUBIC behaviour regardless of whether the model yieldstoo low or too high throughput (cwnd) for CUBIC sender in the

Reno-frindly region: if the model yields too low throughput, the CUBIC

sender leaves the Reno-friendly region too early and becomes (much) moreaggressive actual Reno sender would; otherwise, if the model yields too

high throughput, the CUBIC sender is too aggressive throughout the

Reno-friendly region.

(*) Note:

The tail drop case in not always synchronized for competing Reno CC

flows either. Flows get more or less randomly desynchronized from time to <= br> time because the total sum of the cwnds for the competing flows at the end =

of the cycle does not necessarily match the buffering capacity of the path.=

This, however, is not a big problem for the model because competing flows <= br> alternate such that each flow encounters a longer cycle more or less

randomly. A flow having a longer cycle is then later pushed towards the

correct awg cwnd. In the long run the cycle lengths (=3D drop probability) =

averages to be the same, and very importantly, there is no systematic

bias.

Thanks,

/Markku

Bob Briscoe wrote:

> Markku, Yoshi,

>

> As promised, I've tried to develop the maths to derive the additiv= e increase factor for the

> Reno-Friendly mode of Cubic. I did it for two cases:

> * synchronized (tail-drop)

> * desynchronized (AQM)

>

> I've written a short LaTeX report and uploaded here:

> =C2=A0=C2=A0=C2=A0 https= ://raw.githubusercontent.com/bbriscoe/cubic-reno/main/creno_tr.pdf

> If Markku and others review it, I'll update it with any correction= s, and once ready, I can publish

> it on ArXiv, so that we have an archival reference.

> Here's a brief summary, but pls read the report before criticizing= anything in the summary.

>

> Tail Drop case

>=C2=A0 *=C2=A0 This turned out to be straightforward, and ended up with= the same formula as in RFC8312 (which

>=C2=A0 =C2=A0 =C2=A0came from [FHP00] which assumed /non/-tail-drop!).<= br> >=C2=A0 *=C2=A0 I believe my derivation is straightforward and rigorous = and it doesn't rely on loss probability,

>=C2=A0 =C2=A0 =C2=A0unlike [FHP00], which was Markku's main concern= .

>=C2=A0 *=C2=A0 I've also included a possible explanation for the re= sult with tail-drop in [FHP00] where the

>=C2=A0 =C2=A0 =C2=A0throughput of CUBIC in Reno-friendly mode was lower= , not the same as Reno:

>=C2=A0 =C2=A0 =C2=A0 +=C2=A0 I've explained why C-Reno would suffer= more than Reno if the buffer was not deep enough to

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0take the combined synchronized decrea= ses without draining out completely.

>=C2=A0 =C2=A0 =C2=A0 +=C2=A0 but I haven't proved this empirically = by trying with a deeper buffer (and I don't intend to

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- someone else can do that if they wa= nt).

> Tail-drop summary: I believe we now have some solid theory for the for= mula in RFC8312, at least for

> tail drop scenarios, which are (sadly) still likely to be prevalent.>

>

> AQM case

>=C2=A0 *=C2=A0 Too hard for me to produce even an approximate derivatio= n of the AI factor.

>=C2=A0 *=C2=A0 I've included a discussion of why the formula in [FH= P00] is incorrect for the AQM case, which is

>=C2=A0 =C2=A0 =C2=A0more deeply thought-through than my earlier emails:=

>=C2=A0 =C2=A0 =C2=A0 +=C2=A0 my critique seems similar to Markku's = and it is possible it's the same, but there's not

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enough explanation in Markku's em= ails to know for sure.

>=C2=A0 =C2=A0 =C2=A0 +=C2=A0 @Markku, perhaps you can see if what I'= ;ve written describes what you meant?

>=C2=A0 *=C2=A0 However, in the AQM case, the simulations in the Floyd r= eport give the opposite results to what

>=C2=A0 =C2=A0 =C2=A0I would expect.

> AQM summary: A formula for the AI factor in the AQM case is still beyo= nd me, and the results in

> [FHP00] are still=C2=A0the opposite of what I'd expect.

>

>

> Bob

>

> On 17/09/2021 10:06, Yoshifumi Nishida wrote:

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Bob,

>

> Thanks for the comments.

> I at least think we both can agree that the draft uses [FHP00] as the = basis of their AIMD or

> NewReno model.

> If you have any suggestions to update the texts to address your concer= ns, please share. (but,

> in this case, using github might be straightforward.)

> =C2=A0

> Unfortunately, I'm not sure about the empirical=C2=A0evidence to s= upport the formula.=C2=A0

> But, given that cubic has been widely deployed for long time and we do= n't see strong voices to

> point out problems for it, I am guessing the=C2=A0issues might not be = too obvious at least.

> If you have any specific concerns in the formula, could you share?=C2= =A0

>

> Thanks,

> --

> Yoshi=C2=A0

>

>

> On Mon, Sep 13, 2021 at 4:17 PM Bob Briscoe <ietf@bobbriscoe.net> wrote:

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Yoshi,

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0On 11/09/2021 22:02, Yoshifumi Nishida wrote= :

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Bob,

>

> Thanks for the very detailed explanation.=C2=A0

> I agree with some of your points. But, I have two comments on this.

>

> The first point is about RTT variation.=C2=A0

> I think you have a point there, but I personally think=C2=A0the paper = presumes very

> shallow queue so that the model can be very simple.

> In this case, we don't have to think about min or max of RTT as th= ey will be

> mostly the same.

>

>

> [BB] The paper gets the same answer as I got under assumption #3 (all = sawtooth vary

> around a set point half-way between max and min).

> I didn't assume shallow queues, so it can't be assuming shallo= w queues.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0I think we can probably argue the accuracy o= f the model, but I think it is

>=C2=A0 =C2=A0 =C2=A0 =C2=A0too broad as a scope of this document. It lo= oks a very deep research topic

>=C2=A0 =C2=A0 =C2=A0 =C2=A0to me.

> I think the model is basically derived=C2=A0from Equation-based Conges= tion Control

> paper in sigcomm 2000. If we want to update or renew it, we might need= another

> RFC5348.

>

>

> [BB] I didn't use Equation-based CC at all and, at least under one= of my three

> assumptions, I got the same result as the [FHP00] paper (with one furt= her assumptions

> about how many drops there are at the top of different sawteeth).

>

> I just wanted to check the outcome wouldn't be different if I used= a model of varying

> RTT, 'cos I'd already recently done this maths for another rea= son - to derive the

> recovery time after a loss. This proved that, given [FHP00] got the sa= me result as one

> of my cases just using basic AIMD sawtooth geometry, at least in this = one case, the

> varying RTT doesn't make any difference.

>

> Nonetheless, I think you're right that deriving the correct formul= a would involve deeper

> research. I don't think publication of the RFC should block on tha= t research.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0So, I think it would be better for this doc = to use the model as it is and

>=C2=A0 =C2=A0 =C2=A0 =C2=A0leave its enhancements for future discussion= s.

>

>

> [BB] That's up to the WG. But I would not refer to that paper, at = least not alone. And I

> don't think the draft should claim that the formula for Reno-frien= dly Cubic that it uses

> from that paper is correct, when it clearly doesn't produce the de= sired result, even in

> the paper that proposed it.

>

>

> The second point is =CE=B1 in the draft might be too big.

>

>

> [BB] How so? The paper's own simulations (exploring a very limited= space) conclude that

> =CE=B1 from the model is more than 2x too small.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0During my WGLC review, I read [FHP00] once a= nd I had similar thoughts.

> But, after I re-read the paper several times, I start having a differe= nt

> interpretation.=C2=A0

>

> First off, it is very clear that =CE=B2=3D0.7 is more aggressive than = =CE=B2 =3D0.5 when there's

> no other traffic.

> As cwnd growth is linear, if there's enough long time for the data= transfer, the

> average cwnd for =CE=B2 =3D0.5 will be (1.0=C2=A0+ 0.5)/2 =3D 0.75 Wma= x and it will be (1.0=C2=A0+

> 0.7)/2 =3D 0.85 Wmax=C2=A0for =CE=B2=3D0.7.

>

>

> [BB] Correct

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0So, it is obvious that this model does not a= im for the cases where there's

>=C2=A0 =C2=A0 =C2=A0 =C2=A0no other traffic.

>

>

> [BB] It is certainly obvious that comparing flow rates is not about si= ngle flows.

>

> But, by the same token, does it mean anything to say a flow is 'mo= re aggressive when

> there's no other traffic'?

> You can have different cwnd for the same throughput, if the avg queue = delay is higher

> and therefore RTT is higher.=C2=A0 But I don't think that says any= thing about aggression. If

> anything, aggression is about shorter recovery time.

>

> Yes, the analysis I used was for each flow on its own. When they are n= ot on their own,

> but competing in the same queue, (obviously) there cannot be two diffe= rent average queue

> delays. But you can think of them as each progressing in parallel, eac= h taking losses

> and each contributing to the queue. I'm not saying my analysis is = the final word by any

> stretch of the imagination. However, if on their own they have differe= nt recovery times,

> then when together A will be pulling B away from its natural recovery = time and towards

> A's recovery time, and vice versa.

>

>

> I believe the choice of (=CE=B1,=C2=A0 =CE=B2) in [FHP00] is designed = to be more or less fair

> only when it competes with (=CE=B1=3D1.0,=C2=A0 =CE=B2 =3D0.5)

> Hence, I think we should not apply the loss rate for no-other-traffic = situation to

> the formula, which can lead to =CE=B13=C2=A0=3D 0.20

> Instead, I am thinking we can think in this way..

>

> (=CE=B1=3D1.0,=C2=A0 =CE=B2 =3D0.5) model oscillates between 0.5 W1 an= d 1.0 W1 in a congestion epoch.

> (=CE=B1=3DX,=C2=A0 =CE=B2 =3D0.7) model oscillates between 0.7 W2 and = 1.0 W2 in the same congestion

> epoch.

> =C2=A0 where W1 is max window for (=CE=B1=3D1.0,=C2=A0 =CE=B2 =3D0.5),= W2 is max window for (=CE=B1=3DX,=C2=A0 =CE=B2 =3D0.7)

> When these two models have the same loss ratio, it should satisfy (1.0= =C2=A0+ 0.5) W1 =3D

> (1.0=C2=A0+ 0.7) W2=C2=A0 =C2=A0

>

> Also, in one congestion epoch, (=CE=B1=3D1.0,=C2=A0 =CE=B2 =3D0.5) inc= reases 0.5 W1 while (=CE=B1=3DX,=C2=A0 =CE=B2

> =3D0.7) increases 0.3 W2

> Now, if=C2=A0we define the congestion epoch as e RTTs, e =3D 0.5 W1 / = 1.0=C2=A0 and also e =3D

> 0.3 W2 / X

> This means, X should satisfy

> =C2=A0 0.5 W1 /1.0=C2=A0 =3D 0.3 * 1.5/1.7 W1/ X

> then we get X =3D 0.529.

>

>

> [BB] This is the same equation as in [FHP00], but with numbers not var= iables. it's also

> the same as the formula in the current Cubic RFC. And it gives the sam= e answer you've

> got when you plug in the numbers. Because you've used the same tec= hnique to compare the

> geometry of the sawteeth.

>

> But is there empirical evidence to support this formula, given the sim= ulations in the

> paper itself don't support it? That's the question.

>

> Also, I'd like to hear Markku's response to your original ques= tion to him. I was only

> trying to second-guess what he was trying to say.

>

>

> Bob

>

>

>

> This will mean if we launch (=CE=B1=3D1.0,=C2=A0 =CE=B2 =3D0.5) and (= =CE=B1=3D0.529,=C2=A0 =CE=B2 =3D0.7) at the same

> time and reduce them when the sum of their windows becomes Wmax, the t= hroughput of

> them will mostly be the same.

> --

> Yoshi

> =C2=A0

> On Tue, Sep 7, 2021 at 5:17 AM Bob Briscoe <ietf@bobbriscoe.net> wrote:

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Yoshi,

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0You recently asked Markku for an explanation= of his point #4.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Coincidentally, a few weeks ago, I was check= ing the formula in RFC8312

>=C2=A0 =C2=A0 =C2=A0 =C2=A0for Cubic in TCP-Friendly mode (called "= ;C-Reno" in this email for

>=C2=A0 =C2=A0 =C2=A0 =C2=A0brevity), and I also checked back on that pr= eliminary paper that

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Markku refers to. I think Markku has a diffe= rent way of explaining the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0flaw in the equation, but below I'll try= to explain what I think the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0problems are. See [BB] inline...

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0If you don't read HTML email, I'm af= raid the maths is probably going

>=C2=A0 =C2=A0 =C2=A0 =C2=A0to look like gobbledygook.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0On 30/08/2021 17:33, Markku Kojo wrote:

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Yoshi, all,

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0On Wed, 18 Aug 2021, Yoshifumi Nishida wrote= :

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A04. Fairness to AIMD congestion control

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 The equation on page 12 to deri= ve increase factor =CE=B1_cubic

>=C2=A0 =C2=A0 =C2=A0 =C2=A0that

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 intends to achieve the same ave= rage window as AIMD TCP seems

>=C2=A0 =C2=A0 =C2=A0 =C2=A0to

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 have its origins in a prelimina= ry paper that states that the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 authors do not have an explanat= ion to the discrepancy between

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 their AIMD model and experiment= al results, which clearly

>=C2=A0 =C2=A0 =C2=A0 =C2=A0deviate.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 It seems to have gone unnoticed= that the equation assumes

>=C2=A0 =C2=A0 =C2=A0 =C2=A0equal

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 drop probability for the differ= ent values of the increase

>=C2=A0 =C2=A0 =C2=A0 =C2=A0factor

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 and multiplicative decrease fac= tor but the drop probability

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 changes when these factors chan= ge.

>

>

> [BB] The source of eqn (4) in RFC8312 is eqn (4) in [FHP00]. This pape= r has

> been cited 250 times but it is not peer reviewed.

>

> Equations (2) & (3) of [FHP00] that lead up to (4) use an RTT (R) = as if it

> doesn't vary. But it does, because the sawteeth vary the queue. Bu= t the real

> problem is that the model (silently) assumes that R is an average RTT<= br> > sitting part-way up the sawteeth, whatever the link rate or base RTT. = This

> overlooks the fact that, if the tips of the sawteeth are always at the= same

> queue depth (as in a tail-drop buffer) the average R will be higher if= the

> sawteeth have smaller amplitude. This sounds picky, but the assumption= on

> whether sawteeth vary about their bottom, top or middle greatly alters= the

> outcome:

>

> I've taken three possible alternative assumptions, with their resu= lting

> additive increase factors for theoretical equality with Reno (I've= given all

> the derivations at the end of this email):

> #1) All sawteeth have the same Rmin: =CE=B1 ~=3D (1/=CE=B22 - 1) / 3;= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Example: =CE=B2

> =3D 0.7; =CE=B1 ~=3D 0.35

> #2) All sawteeth have the same Rmax: =CE=B1 ~=3D 4(1-=CE=B22) / 3;=C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Example: =CE=B2

> =3D 0.7; =CE=B1 ~=3D 0.68

> #3) All sawteeth have the same Ravg: =CE=B1 ~=3D 3(1-=CE=B2) / (1+=CE= =B2);=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Example: =CE=B2

> =3D 0.7; =CE=B1 ~=3D 0.53=C2=A0=C2=A0=C2=A0 <=3D=3D used in [FHP00]= and therefore in RFC8312

>

>

> Which assumption is most applicable?

> #2 models a tail-drop queue.

> #3 (or somewhere between #3 and #2) models a probabilistic AQM, such a= s PIE

> or RED.

> #1 is not applicable to the current Internet, but it would be if a mag= ic AQM

> was invented that minimized the standing queue.

> I don't think any of the assumptions are good models of C-Reno'= ;s interaction

> with CoDel.

>

> So which one should draft-ietf-tcpm-rfc8312bis recommend?

> You might think #2, given one suspects the vast majority of queues are= still

> tail drop...

> However, it may be 'none of the above', 'cos the paper als= o says it assumes

> deterministic marking; i.e. that that each flow experiences just one d= rop or

> mark at the top of each sawtooth. If that applies at all, it only appl= ies to

> AQMs, not to tail-drop buffers that tend to drop more than one packet = at a

> time. Nonetheless, for the purpose of rate comparison, all the flows w= ill

> share the same bottleneck. So if flow rates are equal under a certain = AQM,

> they might be equal under tail-drop too (see {Note 1} at the very end)= .

>

> I would still like to say 'none of the above' because Linux C-= Reno has been

> widely used with =CE=B1=3D1, =CE=B2=3D0.7 for many years now without t= he sky falling. So

> it's questionable whether friendliness should be defined relative = to Reno.

> Otherwise, from day 1, RFC8312bis will be stating the forlorn hope tha= t

> Linux C-Reno should regress to become less aggressive than its former = self,

> just to be friendly to Reno, which apparently barely exists any more> (according to the Great TCP Congestion Control Census of 2019 [MSJ+19]= ).

>

> Nonetheless, we need to bear in mind that BSD variants of Cubic (e.g.<= br> > Apple's) are also widely used and I believe they comply with the = =CE=B1 for

> C-Reno defined in RFC8312.

>

> (FAQ: Why does C-Reno add <1 segment per RTT to be friendly to Reno= , which

> adds 1 segment per RTT?

> C-Reno in the RFC multiplicatively decreases cwnd to 0.7*cwnd on a los= s

> (multiplicative decrease factor =CE=B2=3D0.7), whereas Reno uses =CE= =B2=3D0.5. So, because

> C-Reno reduces less, it's also meant to increase less per round so= that the

> sawteeth don't reach the max window again more quickly than Reno w= ould. That

> is, it's meant to use a smaller AI factor (=CE=B1) than 1 segment.= Using =CE=B1<1

> doesn't necessarily slow down Cubic's acceleration into unused= capacity,

> because it can switch to a convex (hockey stick) Cubic curve once its = slow

> linear increase has made the queue large enough to come out of its

> 'TCP-Friendly' mode.)

>

> Whatever, rfc8312bis certainly shouldn't refer solely to [FHP00] w= ithout

> caveats.

>

> Then we have the problem that none of the above formulae are verified<= br> > against reality.

> Even in the [FHP00] paper, which uses assumption #3, the simulations a= re out

> by about 2x. The paper used =CE=B2=3D7/8. So, from the theory, for eac= h of the

> above three assumptions, the additive increase factor would have had t= o be:

> =CE=B11 =3D 0.10

> =CE=B12 =3D 0.31

> =CE=B13 =3D 0.20

> They used a RED AQM (which should be somewhere between assumption #2 &= amp; #3).

> But they had to configure C-Reno with =CE=B1=3D0.4 to get close to equ= al flow rates

> with Reno

> Using my 'finger in the air' modification to the formulae in {= Note 1}, =CE=B13 =3D

> sqrt(0.20) =3D 0.44, which would have been about right (perhaps only> coincidentally).

>

> The question over what =CE=B1 to put in the RFC could run and run. So = here's a

> suggested path through this quagmire:

> These alternatives throw doubt on the wisdom of using assumption#3. So= we

> could at least pick a new assumption for a theoretical =CE=B1. Assumpt= ion#2 is

> probably the 'most correct', and also happens to give the high= est value of =CE=B1

> for the 'TCP-Friendly' region (=CE=B1=3D0.68 when =CE=B2=3D0.7= ).

> (By my unsubstantiated formula in {Note 1}, =CE=B12 =3D sqrt(0.68) =3D= 0.82.)

>

> If we look for an empirical value of =CE=B1 that gives reasonably equa= l flow

> rates against Reno, I suspect we will get all sorts of different answe= rs

> depending on the conditions, e.g. AQM or not; high or low multiplexing= ; high

> or low RTT (shared by all flows); pacing, burstiness, etc,etc. If you = want

> to take this path, feel free, but if you're still on it in a year&= #39;s time,

> don't say I didn't warn you.

>

>

> Derivations of the above three formulae follow at the end.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0The equations for the drop

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 probability / the # of packets = in one congestion epoch

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 are available in the original p= aper and one can easily verify

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 this. Therefore, the equations = used in CUBIC are not correct

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 and seem to underestimate _W_es= t_ for AIMD TCP, resulting in

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 moving away from AIMD-Friendly = region too early. This gives

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 CUBIC unjustified advantage ove= r AIMD TCP particularly in

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 environments with low level of = statistical multiplexing. With

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 high level of multiplexing, dro= p probability goes higher and

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 differences in the drop probabl= ilities tend to get small. On

>=C2=A0 =C2=A0 =C2=A0 =C2=A0the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 other hand, with such high leve= l of competition, the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0theoretical

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 equations may not be that valid= anymore.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0/Markku

>

>

> [BB] Derivations of the formulae for =CE=B1 under the three different = assumptions

> follow. It's possible/likely that this is all already in a paper s= omewhere,

> but I haven't been able to find one.

>

>=C2=A0 =C2=A00) Preparatory material

>

> Terminology:

> The subscript for C-Reno is omitted given it would be on every term.> The recovery time of an AIMD congestion control is the average time fo= r

> additive increase to recover the window reduction after a multiplicati= ve

> decrease.

>

> The overall approach is:

> A) Find a formula in terms of the AI and MD factors (=CE=B1 & =CE= =B2), for the

> recovery time of C-Reno.

> B) Equate this to the recovery time of Reno, which will produce a form= ula

> for the additive increase factor, =CE=B1.

>

> The recovery time formula for C-Reno is derived by:

> 1) summing up all the round trips in additive increase, which become> increasingly large as the queue grows. This sum is stated in terms of = the

> number of rounds per cycle, J.

> 2) Then J is found by writing two formulae;

> =C2=A0 2a) one for the average sawtooth decrease

> =C2=A0 2b) and the other for the increase.

> Then by assuming a steady state the two can be equated.

> Here goes...

>

> The following formula gives the recovery time, Tr, from one max window= to

> the next, in C-Reno with:

> * additive increase (AI) factor =CE=B1 [segment / RTT]

> * and packet-rate r [packet / s]

> assuming that the minimum window of each sawtooth still fully utilizes= the

> link.

> =C2=A0=C2=A0=C2=A0 Tr =3D =CE=A3J-1j=3D0=C2=A0 =C2=A0 (Rmin + j=CE=B1/= r)

> where j is the index of each round, and J is the number of round trips= of

> additive increase per sawtooth. The rationale for the second term is t= hat

> the queue grows by =CE=B1 fractional packets in each round, and the qu= eue delay

> per packet is 1/r (seconds per packet is reciprocal of packets per sec= ond).

> The sum of all the second terms forms an arithmetic progression, the s= um of

> which is given by the well-known formula, as follows:

> =C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 =3D J.Rmin + J(J-1)=CE=B1/2r

> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 ~=3D J.Rmin + J2=CE=B1/2r.=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=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)

> The approximation holds as long as J>>1. In some implementations= (e.g.

> Linux), cwnd increases continuously, so strictly the limits should be = j=3D1/2

> to J-1/2 (the average half way through the first and last rounds), but=

> details like this are insignificant compared to the approximation.

>

> The difference in RTT due to the additional queue delay between the to= p and

> bottom of the sawtooth can be stated in two ways.

> Either as the sum of all the queue delays of each additive increase:> =C2=A0=C2=A0=C2=A0 (Rmax - Rmin) =3D J=CE=B1/r,=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (2a)

> Or by the multiplicative relationship between the max and min RTTs, by= the

> definition of =CE=B2: Rmin =3D =CE=B2.Rmax.

> =C2=A0=C2=A0=C2=A0 (Rmax - Rmin) =3D (Rmin / =CE=B2) - Rmin

> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 =3D Rmin(1-=CE=B2)/=CE=B2 =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 (2b)

> Equating (2a) and (2b):

> =C2=A0=C2=A0=C2=A0 J =3D r.Rmin(1-=CE=B2) / (=CE=B1=CE=B2) =C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0 =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)

>

> Substituting for J from (2) in (1):

> =C2=A0=C2=A0=C2=A0 Tr =3D r.Rmin2 (1-=CE=B2) / (=CE=B2=CE=B1) + r.Rmin= 2 (1-=CE=B2)2/(2=CE=B22=CE=B1)

> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 =3D r.Rmin2 (1-=CE=B2) / (= =CE=B2=CE=B1) * (1 + (1-=CE=B2)/2=CE=B2 )

> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 =3D r.Rmin2 (1-=CE=B2)(1+= =CE=B2) / (2=CE=B22=CE=B1)

> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 =3D r.Rmin2 (1-=CE=B22) / = (2=CE=B22=CE=B1)=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =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)

> And, because Rmin =3D =CE=B2.Rmax.

> =C2=A0=C2=A0=C2=A0 Tr =3D r.Rmax2 (1-=CE=B22) / (2=CE=B1)=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 (4)

>

> The well-known steady-state Reno formula from [FF99] is:

> =C2=A0=C2=A0=C2=A0 rReno ~=3D (1/Ravg) sqrt(3 / 2p)=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0

> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 (5)

> assuming deterministic marking (which is also assumed for the above mo= del of

> C-Reno).

>

> Assuming a Reno sawtooth is approximately linear, the average RTT of a= Reno

> flow,

> =C2=A0=C2=A0=C2=A0 Ravg ~=3D (Rmax + Rmin)/2

> and

> =C2=A0=C2=A0=C2=A0 Rmin =3D Rmax/2

> Therefore

> =C2=A0=C2=A0=C2=A0 rReno ~=3D (1/Rmin) sqrt(2 / 3p)=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0

> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 (6)

> =C2=A0=C2=A0=C2=A0 rReno ~=3D (1/Rmax) sqrt(8 / 3p)=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0

> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 (7)

>

> With the preparatory material done, next we take each of the three

> assumptions, one at a time.

>

>=C2=A0 =C2=A0#1) All sawteeth have the same Rmin=C2=A0

>

> From Eqn (3):

> =C2=A0=C2=A0=C2=A0 Tr =3D r.Rmin2 (1-=CE=B22) / (2=CE=B22=CE=B1)

> Total packets sent over period Tr is r.Tr during which time assume 1 p= acket

> is lost (or marked) at the sawtooth peak {Note 1}. So loss probability= :

> =C2=A0=C2=A0=C2=A0 p =3D 1 / r.Tr

> Substituting for Tr and rearranging :

> =C2=A0=C2=A0=C2=A0 r2 =3D 2=CE=B22=CE=B1 / Rmin2 (1-=CE=B22)p

> =C2=A0=C2=A0=C2=A0 r =3D (=CE=B2/Rmin) sqrt(2=CE=B1 / (1-=CE=B22)p)

> Equating the Reno packet rate, rReno, from eqn (6) to the C-Reno packe= t

> rate, r, for all =CE=B1 and =CE=B2:

> =C2=A0=C2=A0=C2=A0 r =3D rReno

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D (1/Rmin) sqrt(2 / 3p).

> Therefore,

> =C2=A0=C2=A0=C2=A0 (1/Rmin) sqrt(2 / 3p) ~=3D (=CE=B2/Rmin) sqrt(2=CE= =B1 / (1-=CE=B22)p)

> Rearranging

> =C2=A0=C2=A0=C2=A0 2/3 ~=3D 2=CE=B1=CE=B22 / (1-=CE=B22)

> =C2=A0=C2=A0=C2=A0 =CE=B1 ~=3D (1-=CE=B22)/3=CE=B22

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ~=3D (1/=CE=B22 - 1) / 3=C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0

> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 (8)

>

>=C2=A0 =C2=A0#2) All sawteeth have the same Rmax =3D Rmin / =CE=B2

>

> From Eqn (4):

> =C2=A0=C2=A0=C2=A0 Tr =3D r.Rmax2 (1-=CE=B22) / (2=CE=B1)

> As before, after substituting for Tr and rearranging:

> =C2=A0=C2=A0=C2=A0 p =3D 1 / r.Tr

> =C2=A0=C2=A0=C2=A0 r =3D (1/Rmax) sqrt(2=CE=B1 / (1-=CE=B22)p)

> Equating to rReno from eqn (7) for all =CE=B1 and =CE=B2,

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ~=3D (1/Rmax) sqrt(8 / 3p).

> Rearranging

> =C2=A0=C2=A0=C2=A0 8/3 ~=3D 2=CE=B1 / (1-=CE=B22)

> =C2=A0=C2=A0=C2=A0 =CE=B1 ~=3D 4(1-=CE=B22) / 3 =C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0

> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 (9)

>

>=C2=A0 =C2=A0#3) All sawteeth have the same Ravg

>

> Ravg =3D (Rmax + =CE=B2Rmax )/2

> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 =3D Rmax (1+=CE=B2)/2

> From Eqn (4):

> =C2=A0=C2=A0=C2=A0 Tr =3D r.Rmax2 (1-=CE=B22) / (2=CE=B1)

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 2r.Ravg2 (1-=CE= =B2) / =CE=B1(1+=CE=B2)

> As before, after substituting for Tr and rearranging:

> =C2=A0=C2=A0=C2=A0 p =3D 1 / r.Tr

> =C2=A0=C2=A0=C2=A0 r =3D (1/Ravg) sqrt(=CE=B1 (1+=CE=B2) / 2(1-=CE=B2)= p)

> Equating to rReno from eqn (5) for all =CE=B1 and =CE=B2,

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ~=3D (1/Ravg) sqrt(3 / 2p).

> Rearranging

> =C2=A0=C2=A0=C2=A0 3/2 ~=3D =CE=B1(1+=CE=B2) / 2(1-=CE=B2)

> =C2=A0=C2=A0=C2=A0 =CE=B1 ~=3D 3(1-=CE=B2) / (1+=CE=B2)=C2=A0 =C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0

> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0 (10)

>

> This last formula is same as the equation used for C-Reno in RFC8312 a= nd in

> the RFC8312bis=C2=A0draft.

>

>

> {Note 1}: The assumption in [FHP00] of deterministic marking is suspec= t for

> the Internet (meaning that the spacing between drops or marks is even = and

> there is always 1 packet dropped or marked at the top of each sawtooth= ). The

> actual average dropped (or marked) per sawtooth will depend on whether= the

> buffer uses tail-drop or an AQM, and if so which AQM. It is perhaps be= tter

> not to assume the actual average number dropped (or marked) is known, = but

> instead assume the ratio of the average drops or marks between C-Reno = and

> Reno will be roughly proportional to their AI factors. This would modi= fy the

> formula for C-Reno's drop probability to:

> =C2=A0=C2=A0=C2=A0 p =3D =CE=B1Reno / =CE=B1C-Reno.r.Tr

> Substituting =CE=B1Reno =3D 1:

> =C2=A0=C2=A0=C2=A0 p =3D 1 / =CE=B1C-Reno.r.Tr

> This would modify all the results to:

>

> #1) All sawteeth have the same Rmin: =CE=B1 ~=3D sqrt( (1/=CE=B22 - 1)= / 3 );=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0

> Example: =CE=B2 =3D 0.7; =CE=B1 ~=3D 0.59

> #2) All sawteeth have the same Rmax: =CE=B1 ~=3D sqrt( 4(1-=CE=B22) / = 3 );=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0

> Example: =CE=B2 =3D 0.7; =CE=B1 ~=3D 0.82

> #3) All sawteeth have the same Ravg: =CE=B1 ~=3D sqrt( 3(1-=CE=B2) / (= 1+=CE=B2) );=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

> Example: =CE=B2 =3D 0.7; =CE=B1 ~=3D 0.73

>

> However, these would then be wrong where there really is deterministic=

> marking.

>

> References

> =3D=3D=3D=3D=3D=3D=3D=3D=3D

> [FHP00]=C2=A0=C2=A0=C2=A0 Floyd, S., Handley, M., and J. Padhye, "= ;A Comparison of

> Equation-Based and AIMD Congestion Control", May 2000,=C2=A0

> <https://www.icir.org/tfrc/aimd.pdf>

>

> [MSJ+19] Ayush Mishra, Xiangpeng Sun, Atishya Jain, Sameer Pande, Raj = Joshi,

> and Ben Leong. The Great Internet TCP Congestion Control Census. Proc.= ACM

> on Measurement and Analysis of Computing Systems, 3(3), December 2019<= br> >

> [FF99] Sally Floyd and Kevin Fall, "Promoting the Use of End-to-E= nd

> Congestion Control in the Internet", IEEE/ACM ToN (1999)

>

>

> Bob

>

> --

> ________________________________________________________________

> Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://bobbriscoe.net/=

>

>

> --

> ________________________________________________________________

> Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://bobbriscoe.net/=

>

>

> --

> ________________________________________________________________

> Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://bobbriscoe.net/=

>

>

Hi folks,

--00000000000076b98d05dce6afce--

I think we've seen a solid consensus to =
publish the CUBIC draft as a PS doc during the last WG meeting. So, the cha=
irs are thinking about proceeding in this=C2=A0direction.

It seems to me that the remaining=C2=A0point of the draft is whethe=
r we add some texts to the doc or publish it as it is. In my impression, it=
seems that more people prefer to add some texts.

=
In case of adding some texts, we would like to understand what they will be=
.

Do we add the discussion points that Markku and Bob raised or w=
e would like to mention that CUBIC has been deployed without IETF process, =
or something else?

We appreciate your feedback on =
this point or anything related to the doc and the process.

--

=

=

Yoshi