Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-alternativebackoff-ecn-06

From: "Richard Scheffenegger" <[email-masked]>
Date: Thu, 1 Mar 2018 11:13:59 +0100

Hi,

Some of the I-D references are already RFCs;

Reading the FreeBSD modular cubic code, using a beta value of 0.8 (vs. 0.7 
reportedy in Linux), I'm wondering if some generic rules-of-thumb, as to 
what a reasonable beta_loss vs. beta_ecn adjustment would be in this RFC 
might be in order (although I agree, that CCs should come up with reasonable 
guidance there).

Other than this, I like this draft, as it also gives some additional 
incouragement to deploy ECN.

Best regards,
  Richard

----- Original Message ----- 
From: "Michael Tuexen" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, February 28, 2018 9:12 PM
Subject: [tcpm] WGLC for draft-ietf-tcpm-alternativebackoff-ecn-06

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
>

---

From: Michael Welzl <[email-masked]>
Date: Tue, 13 Mar 2018 18:25:34 +0100

Hi,

> On Mar 1, 2018, at 11:13 AM, Richard Scheffenegger <[email-masked]> wrote:
> 
> Hi,
> 
> Reading the FreeBSD modular cubic code, using a beta value of 0.8 (vs. 0.7 reportedy in Linux), I'm wondering if some generic rules-of-thumb, as to what a reasonable beta_loss vs. beta_ecn adjustment would be in this RFC might be in order (although I agree, that CCs should come up with reasonable guidance there).

Yes, we found the choice of value to depend on the algorithm.

> Other than this, I like this draft, as it also gives some additional incouragement to deploy ECN.

Thanks - we hope so too!

Cheers,
Michael

PS: When I just tried to answer this email with reply-to-all, my Apple Mail client offered the alias:
"[email-masked]" <[email-masked]> 
which it had stored as an address, as a result of the previous conversation. To avoid continuing the nonsense of wrongly sending to the list instead of the chairs in the future as this alias gets stored in email clients, I recommend that folks check this address carefully when sending replies.
Although, maybe don’t: it would be kind of funny to see these things happen more often   :-)   this certainly gave me a good laugh today.

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 16 Mar 2018 23:09:57 +0000

> On 28. Feb 2018, at 20:12, Michael Tuexen <[email-masked]> wrote:
> 
> Dear all,
> 
> this e-mail starts the working group last call for draft-ietf-tcpm-alternativebackoff-ecn-06.
> 
> This WGLC runs until Friday, March 16th 2018. Please send any comments, including indications
> to support this document, to the TCMP mailing list by then.
> 
> The ID is available at
> https://tools.ietf.org/html/draft-ietf-tcpm-alternativebackoff-ecn-06
Dear all,

the references need some updates:

* I-D.ECN-exp should be RFC8311
* I-D.CoDel should be RFC8289
* I-D.CUBIC should be RRC 8312

Best regards
Michael (as an individual)
> 
> Best regards
> Michael_______________________________________________
> tcpm mailing list
> [email-masked]

---

From: Markku Kojo <[email-masked]>
Date: Sat, 17 Mar 2018 02:52:18 +0200 (EET)

Hi all,

Maybe slightly late wg last call review of 
draft-ietf-tcpm-alternativebackoff-ecn-06.

The draft is mostly well written and clear, and it is also improved since 
version -00 or -01 I last read it.

I believe the intention of the draft is just to allow and propose 
experimentation using a larger multiplicative decrease factor when 
responding to ECN indication than when responding to packet loss.

There is, however, a significant change that seem to have occured from 
version -04 to -05 that does much more than this and is therefore crucial 
to address properly. The text and reads now in -06 as follows:

   It updates the following text in section 6.1.2 of the ECN
   specification [RFC3168] :

      The indication of congestion should be treated just as a
      congestion loss in non-ECN-Capable TCP.  That is, the TCP source
      halves the congestion window "cwnd" and reduces the slow start
      threshold "ssthresh".

   Replacing this with:

      Receipt of a packet with the ECN-Echo flag SHOULD trigger the TCP
      source to set the slow start threshold (ssthresh) to 0.8 times the
      FlightSize, with a lower bound of 2 * SMSS applied to the result.
      As in [RFC5681], the TCP sender also reduces the cwnd value to no
      more than the new ssthresh value.

And is further clarified in Section 4.3:

  and in response to an indication of an ECN-signalled congestion:

        ssthresh = max (FlightSize * beta_{ecn}, 2 * SMSS)

        and

        cwnd = ssthresh

In my reading this text above sets a lower bound of 2 MSS for cwnd which 
is incorrect and dangerous modification and maybe not intended to modify 
RFC 3168.

The lower bound for cwnd is 1 MSS. The lower bound of 2 MSS for cwnd

1) is not specified in any (standards track) RFC,
2) is against the congestion control principles for avoiding
    congestion collapse as it effectively disables a full back
    off that is a crucial requirement for all congestion control
    algorithms,
3) is in conflict with the basic principle set in Sally's ECN papers
    and in RFC 3168 itself (the original text above from RFC 3168):

    "The indication of congestion should be treated just as a
     congestion loss in non-ECN-Capable TCP."

    When Flightsize (and cwnd) is 2 MSS in non-ECN-Capable TCP and loss
    signals congestion, cwnd effectively becomes 1 MSS. That is why RFC
    3168 formulates the text: "the TCP source halves the congestion
    window "cwnd" ..."

    Note: the majority of the work and text in RFC 3168, including
    the text in RFC 2482, predates RFC 2581 that first introduced
    FlightSize. Prior to RFC 2581 all TCP CC text "halved cwnd"
    which literally meant cwnd=cwnd/2.

Instead of the above text in the draft, the draft should explicitly state 
that when FlightSize/2 would result in ssthresh below its lower bound of 2 
MSS, a TCP sender must not stop decreasing cwnd. And, if more 
ECN-signalled congestion indications arrive, the TCP sender must continue 
reducing sending rate further (plus refer to RFC 3168 how to proceed 
reducing the sending rate, if further ECE signals arrive).

Furthermore, the draft should be very specific on how the TCP sender 
should act when cwnd=ssthresh and ECE arrives. Currently the draft 
specifies the way how the TCP sender reduces ssthresh (and cwnd) in 
Congestion Avoidance. According to RFC 5681, when cwnd = ssthresh, TCP is 
not in Slow Start nor in Congestion Avoidance. Therefore, the draft 
should be explicit on how cwnd is reduced, when cwnd=ssthresh.

It is true that there is (at least) one (widely deployed) incorrect 
implementation of RFC 3168 that incorrectly sets lower bound of 2 MSS 
for cwnd when congestion is ECN-signaled. This, however, must not be used 
as any kind of justification for changíng IETF-specified congestion 
control principles and requirements. Instead, this draft should carefully 
instruct implementors and those who intend to experiment with the ECN 
modification set in this draft to ensure the TCP stack used for 
experiments correctly implements RFC 3168 in this respect. Otherwise, 
such experimental results are mostly void.

In addition, there is an incorrect statement in Sec 4.1:

  According to
  [RFC5681], when a TCP sender detects segment loss using the
  retransmission timer and the given segment has not yet been resent by
  way of the retransmission timer, the value of ssthresh must be set to
  no more of the maximum of half of the FlightSize and 2*SMSS.  The
  same equation is also used during Fast Retransmit/Fast Recovery
  [RFC5681].  As a result, the TCP congestion control only allows one
  BDP of packets in flight.  This is just sufficient to maintain 100%
  utilisation of the bottleneck on the network path.

What the text says about setting ssthresh is correct. However, if the 
segment loss is detected using the retransmission timer, the TCP
congestion control does not allow one BDP of packets in flight (unless 
BDP=1 MSS). Instead, cwnd is set to 1 MSS, allowing only 1 pkt in flight.

I suggest removing the text that discusses detecting segment loss using 
the retransmission timer.

Best regards,

/Markku

---

From: Michael Welzl <[email-masked]>
Date: Sat, 17 Mar 2018 08:17:12 +0100

Dear Markku,

Thank you very much for reading this!
Answers in line below:

> On Mar 17, 2018, at 1:52 AM, Markku Kojo <[email-masked]> wrote:
> 
> Hi all,
> 
> Maybe slightly late wg last call review of draft-ietf-tcpm-alternativebackoff-ecn-06.
> 
> The draft is mostly well written and clear, and it is also improved since version -00 or -01 I last read it.
> 
> I believe the intention of the draft is just to allow and propose experimentation using a larger multiplicative decrease factor when responding to ECN indication than when responding to packet loss.
> 
> There is, however, a significant change that seem to have occured from version -04 to -05 that does much more than this and is therefore crucial to address properly. The text and reads now in -06 as follows:
> 
> 
> In my reading this text above sets a lower bound of 2 MSS for cwnd which is incorrect and dangerous modification and maybe not intended to modify RFC 3168.

Just to be clear, indeed we absolutely did not intend to change the spec here - however we thought we need to be clearer.

Consider the original text:
***
    The indication of congestion should be treated just as a
    congestion loss in non-ECN-Capable TCP.  That is, the TCP source
    halves the congestion window "cwnd" and reduces the slow start
    threshold "ssthresh”. 
***

Because this simply says “reduces” about ssthresh without specifying in detail how to reduce it, it would seem obvious (due to the first sentence) that this refers to eqn. 4 in RFC 5681. However, if we say “...set the slow start threshold (ssthresh) to 0.8 times the FlightSize”, then we lose the lower bound. This is why we introduced it for ssthresh.

As for cwnd, I find the original text to be contradictory in this respect (unless I’m missing something). “The indication of congestion should be treated just as a congestion loss in non-ECN-Capable TCP. “ => this, to me, means doing the same as specified in RFC 5681 - but in RFC 5681, I couldn’t see any text that allows cwnd to go below 2 MSS upon a “congestion loss” (assuming this is not a timeout - where you’re right, our text wrongly quoted RFC 5681 there, but that’s a separate issue further below).

( Maybe you mean *during*, not after fast recovery? But that would be confusing, as cwnd is also “inflated” in this phase in RFC 5681, which I hope we don’t do in response to ECE. )

However, RFC 3168, in the second sentence, beginning with “That is, “ (indicating that this is just a clarification), states that the TCP sources halves cwnd.

>   window "cwnd" …"

See above, regarding this text. We certainly don’t want to change these principles but tried to be correct about what should happen, and found the quoted text here to be contradictory.

>   which literally meant cwnd=cwnd/2.

I know that, and I thought that this is the reason for the problem with this text (due to updates of the non-ECN CC text).

> Instead of the above text in the draft, the draft should explicitly state that when FlightSize/2 would result in ssthresh below its lower bound of 2 MSS, a TCP sender must not stop decreasing cwnd. And, if more ECN-signalled congestion indications arrive, the TCP sender must continue reducing sending rate further (plus refer to RFC 3168 how to proceed reducing the sending rate, if further ECE signals arrive).

Technically this makes sense to me, but I’m not currently reading RFC 3168 this way.

> Furthermore, the draft should be very specific on how the TCP sender should act when cwnd=ssthresh and ECE arrives. Currently the draft specifies the way how the TCP sender reduces ssthresh (and cwnd) in Congestion Avoidance. According to RFC 5681, when cwnd = ssthresh, TCP is not in Slow Start nor in Congestion Avoidance. Therefore, the draft should be explicit on how cwnd is reduced, when cwnd=ssthresh.

Why? RFC 5681 states “When cwnd and ssthresh are equal, the sender may use either slow start or congestion avoidance.” - so if you're an implementer, this basically tells you that you have to make a decision on your own for the cwnd == sthresh case. We specify how to behave when you’re in congestion avoidance - thus it depends on the decision you’ve taken for this case.

> It is true that there is (at least) one (widely deployed) incorrect implementation of RFC 3168 that incorrectly sets lower bound of 2 MSS for cwnd when congestion is ECN-signaled. This, however, must not be used as any kind of justification for changíng IETF-specified congestion control principles and requirements. Instead, this draft should carefully instruct implementors and those who intend to experiment with the ECN modification set in this draft to ensure the TCP stack used for experiments correctly implements RFC 3168 in this respect. Otherwise, such experimental results are mostly void.

Maybe the person behind this implementation was as confused by the RFC 3168 as I am … clearly we didn’t intend to change the principles.

> What the text says about setting ssthresh is correct. However, if the segment loss is detected using the retransmission timer, the TCP
> congestion control does not allow one BDP of packets in flight (unless BDP=1 MSS). Instead, cwnd is set to 1 MSS, allowing only 1 pkt in flight.
> 
> I suggest removing the text that discusses detecting segment loss using the retransmission timer.

Good catch, thanks!

Cheers,
Michael

---

From: Markku Kojo <[email-masked]>
Date: Sat, 17 Mar 2018 16:32:00 +0200 (EET)

Hi Michael,

see inline.

> Because this simply says “reduces” about ssthresh without specifying in detail how to reduce it, it would seem obvious (due to the first sentence) that this refers to eqn. 4 in RFC 5681. However, i…

Clarifying ssthresh reduction is all welcome and fine.

> As for cwnd, I find the original text to be contradictory in this respect (unless I’m missing something). “The indication of congestion should be treated just as a congestion loss in non-ECN-Capabl…

With loss-based CC a crucial part of inferring congestion is via timeout 
and that takes cwnd to 1 MSS. ECN response must follow the similar way of 
reducing in the same situation (see below).

> ( Maybe you mean *during*, not after fast recovery? But that would be confusing, as cwnd is also “inflated” in this phase in RFC 5681, which I hope we don’t do in response to ECE. )

I'm not saying anything about "during" fast recovery. It's another story 
and not subject to this draft, I believe.

> However, RFC 3168, in the second sentence, beginning with “That is, “ (indicating that this is just a clarification), states that the TCP sources halves cwnd.

Yes, meaning that cwnd is halved until it reaches 1 MSS (i.e., also when 
cwnd=2) after which further rate reduction is via timer.
> See above, regarding this text. We certainly don’t want to change these principles but tried to be correct about what should happen, and found the quoted text here to be contradictory.

The original text from RFC 3168 could admittedly be more clearer in how to 
reach cwnd = 1 MSS. It is very clear on what to do when cwnd = 1 MSS is 
reached. So, why to discuss it, if we don't ever allow reaching cwnd=1? 
When ECN is operating ideally we'll never see RTO, so we would never reach 
cwnd = 1 MSS if cwnd is lower bounded to 2 MSS (except in case we start 
with IW = 1 MSS and immediately receive ECE).

I don't see the quoted text here being contradictory if we think what 
happens in loss-based CC, when cwnd = 2 MSS and either or both 
of the pkts in flight are dropped. In such case congestion
is signalled via timeout (*) and cwnd is reduced to 1 MSS as the TCP 
sender is unable to get three dupacks but at most one dupack.

(*) Limited Transmit introduces an exception to this but it was carefully 
designed not to modify congestion control principles. If cwnd = 2 MSS and 
one segment is dropped, Limited Transmit transmits one segment per RTT 
over the period of two following RTTs, i.e., it effectively reduces 
sending rate to 1 MSS / RTT even though cwnd is not reduced to 1 MSS. 
This is allowed because the Limited Transmit triggered dupacks 
indicate that there is no heavy congestion and rate reduction 
realizes implicitly.

> I know that, and I thought that this is the reason for the problem with this text (due to updates of the non-ECN CC text).
Yes, unfortunately RFC 3168 did not get aligned with RFC 2581 introduction 
of FlightSize when they both were finalized around the same time.

> Technically this makes sense to me, but I’m not currently reading RFC 3168 this way.

We might then disagree here ;)

In case we want continue with the lower bound for cwnd being 2 MSS, it 
must be justified, I think. However, I find it dangerous as it would lead 
to huge delays in a setting where the physical buffer of a bottleneck 
AQM-enabled router is large or huge (quite typical today) and the offered 
load goes very high such that the share per flow at the bottleneck router 
becomes less than 2 MSS. When offered load is further increased, none of 
the ECN senders will respond to ECN signals and queue builds high. This 
is also very bad for any non-ECT flows that share the same bottleneck as 
they will be locked-out totally and the non-ECT flows will encounter 
unfair, "selective" congestion collapse.

I know Sally has been very careful in designing ECN response and therefore 
I have no doubt how to intepret RFC 3168 in this regard.

> Why? RFC 5681 states “When cwnd and ssthresh are equal, the sender may use either slow start or congestion avoidance.” - so if you're an implementer, this basically tells you that you have to make…

Yes, but RFC 5681 does not make any difference in how to decrease cwnd in 
Slow Start and CA but ABE does. RFC 5681 only discusses that it is 
implementors choice how to *increase* cwnd in this case but here we 
discuss how to decrease cwnd that is more crucial decision and the 
decision what to do maybe should be considered more carefully as 
RFC 5681 does not give any recommendation in this respect.

I have not given much thinking to this, so not sure if it makes much 
difference, but discussing it is in place to judge whether or not it 
matters, I think.

E.g, in an (ideal) ECN-enabled environment we don't expect to see loss, 
but if it occurs due to congestion it is possibly an indication of 
heavy congestion (it may also be that there are non-ECN capable routers on 
the path that get congested). Now, if we have loss and Fast Recovery 
repairs the loss, we set cwnd=ssthresh when Fast Recovery completes. If 
ECE arrives immediately after Fast Recovery, the implementor needs to 
decide whether to use ABE factor of 0.8 or be more conservative. In this 
case we may want to be more conservative to avoid further loss, if we 
think that the loss event was due to heavy congestion. I don't know.

This is potentially also something we may want to explore in the upcoming 
experimentations, so it would be worth of a few sentences in the draft to 
clarify what to do in this "gray area" (like RFC 5681 clarifies the "gray 
area").

> Maybe the person behind this implementation was as confused by the RFC 3168 as I am … clearly we didn’t intend to change the principles.

Quite likely so. Unharmonized RFC 3168 and RFC 2581 (and later RFC 5681) 
do not help in this.

Cheers,

/Markku

---

From: Michael Welzl <[email-masked]>
Date: Sat, 17 Mar 2018 18:04:46 +0100

Hi,

Answers below:

> On Mar 17, 2018, at 3:32 PM, Markku Kojo <[email-masked]> wrote:
> 
> Hi Michael,
> 
> see inline.
> 
> With loss-based CC a crucial part of inferring congestion is via timeout and that takes cwnd to 1 MSS. ECN response must follow the similar way of reducing in the same situation (see below).
> 
> I'm not saying anything about "during" fast recovery. It's another story and not subject to this draft, I believe.
> 
> Yes, meaning that cwnd is halved until it reaches 1 MSS (i.e., also when cwnd=2) after which further rate reduction is via timer.
>> 
> The original text from RFC 3168 could admittedly be more clearer in how to reach cwnd = 1 MSS. It is very clear on what to do when cwnd = 1 MSS is reached. So, why to discuss it, if we don't ever allow reaching cwnd=1? When ECN is operating ideally we'll never see RTO, so we would never reach cwnd = 1 MSS if cwnd is lower bounded to 2 MSS (except in case we start with IW = 1 MSS and immediately receive ECE).

Sorry, I overlooked this discussion -

> I don't see the quoted text here being contradictory if we think what happens in loss-based CC, when cwnd = 2 MSS and either or both of the pkts in flight are dropped. In such case congestion
> is signalled via timeout (*) and cwnd is reduced to 1 MSS as the TCP sender is unable to get three dupacks but at most one dupack.
> 
> (*) Limited Transmit introduces an exception to this but it was carefully designed not to modify congestion control principles. If cwnd = 2 MSS and one segment is dropped, Limited Transmit transmits one segment per RTT over the period of two following RTTs, i.e., it effectively reduces sending rate to 1 MSS / RTT even though cwnd is not reduced to 1 MSS. This is allowed because the Limited Transmit triggered dupacks indicate that there is no heavy congestion and rate reduction realizes implicitly.
> 
> Yes, unfortunately RFC 3168 did not get aligned with RFC 2581 introduction of FlightSize when they both were finalized around the same time.
> 
> In case we want continue with the lower bound for cwnd being 2 MSS, it must be justified, I think. However, I find it dangerous as it would lead to huge delays in a setting where the physical buffer of a bottleneck AQM-enabled router is large or huge (quite typical today) and the offered load goes very high such that the share per flow at the bottleneck router becomes less than 2 MSS. When offered load is further increased, none of the ECN senders will respond to ECN signals and queue builds high. This is also very bad for any non-ECT flows that share the same bottleneck as they will be locked-out totally and the non-ECT flows will encounter unfair, "selective" congestion collapse.
> 
> I know Sally has been very careful in designing ECN response and therefore I have no doubt how to intepret RFC 3168 in this regard.

I’ll repeat that we never intended to change anything else but the backoff factor.
The wording change was the result of having to be more explicit (because we can’t simply say “similar to loss”, which automatically refers back to RFC 5681 rules). Thus, I think we agree that this is just an editorial fix.

> Yes, but RFC 5681 does not make any difference in how to decrease cwnd in Slow Start and CA but ABE does. RFC 5681 only discusses that it is implementors choice how to *increase* cwnd in this case but here we discuss how to decrease cwnd that is more crucial decision and the decision what to do maybe should be considered more carefully as RFC 5681 does not give any recommendation in this respect.
> 
> I have not given much thinking to this, so not sure if it makes much difference, but discussing it is in place to judge whether or not it matters, I think.
> 
> E.g, in an (ideal) ECN-enabled environment we don't expect to see loss, but if it occurs due to congestion it is possibly an indication of heavy congestion (it may also be that there are non-ECN capable routers on the path that get congested). Now, if we have loss and Fast Recovery repairs the loss, we set cwnd=ssthresh when Fast Recovery completes. If ECE arrives immediately after Fast Recovery, the implementor needs to decide whether to use ABE factor of 0.8 or be more conservative. In this case we may want to be more conservative to avoid further loss, if we think that the loss event was due to heavy congestion. I don't know.
> 
> This is potentially also something we may want to explore in the upcoming experimentations, so it would be worth of a few sentences in the draft to clarify what to do in this "gray area" (like RFC 5681 clarifies the "gray area”).

OK, I agree

Cheers,
Michael

> Quite likely so. Unharmonized RFC 3168 and RFC 2581 (and later RFC 5681) do not help in this.
> 
> Cheers,
> 
> /Markku
>

---

From: Markku Kojo <[email-masked]>
Date: Mon, 19 Mar 2018 13:26:17 +0200 (EET)

Hi,

[snip]

> The wording change was the result of having to be more explicit (because we can’t simply say
> “similar to loss”, which automatically refers back to RFC 5681 rules). Thus, I think we agree
> that this is just an editorial fix.

Sure, it was also my understanding that the draft is intended just to 
modify the backoff factor.

As we have incorrect implementation(s) of this deployed and a 
misconception that TCP cwnd has a lower bound of 2*MSS has been around
there (e.g., several iccrg / transport area wg presentations have 
misleadingly stated this), I find it very important that the draft is 
precise and explicit on describing this.

Cheers,

/Markku

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 19 Mar 2018 13:39:24 +0000

Dear all,

this mail closes the working group last call draft-ietf-tcpm-alternativebackoff-ecn-06.

Thanks to everyone for providing feedback!

I ask the document editors to revise the document according to the feedback they got.
These are all editorial changes in my view.

Best regards
Michael

---

From: "Richard Scheffenegger" <[email-masked]>
Date: Mon, 19 Mar 2018 16:31:35 +0100

Hi Michael,

Just thinking that the difference between loss vs. ECN cwn reduction might 
be defined as a relative value of each other, rather than an absolute; In my 
example, Cubic on FreeBSD used beta 0.8, while Cubic Linux uses 0.7; with 
the research showing a sensible Cubic ECN reaction on Linux being 0.85, 
correct? (~50% closer to 1).

So when using Cubic w/ beta 0.8 (as FreeBSD), would a sensible value for 
Cubic ECN there a value of 0.9?

Best regards,
   Richard

----- Original Message ----- 
From: "Michael Welzl" <[email-masked]>
To: "Richard Scheffenegger" <[email-masked]>
Cc: "Michael Tuexen" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, March 13, 2018 6:25 PM
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-alternativebackoff-ecn-06

Hi,

> might be in order (although I agree, that CCs should come up with 
> reasonable guidance there).

Thanks - we hope so too!

Cheers,
Michael

PS: When I just tried to answer this email with reply-to-all, my Apple Mail 
client offered the alias:
"[email-masked]" <[email-masked]>
which it had stored as an address, as a result of the previous conversation. 
To avoid continuing the nonsense of wrongly sending to the list instead of 
the chairs in the future as this alias gets stored in email clients, I 
recommend that folks check this address carefully when sending replies.
Although, maybe don’t: it would be kind of funny to see these things happen 
more often   :-)   this certainly gave me a good laugh today.

---

---

From: Michael Welzl <[email-masked]>
Date: Mon, 19 Mar 2018 16:34:07 +0000

Hi,

> On Mar 19, 2018, at 3:31 PM, Richard Scheffenegger <[email-masked]> wrote:
> 
> 
> Hi Michael,
> 
> Just thinking that the difference between loss vs. ECN cwn reduction might be defined as a relative value of each other, rather than an absolute;

Ah, got it.

> In my example, Cubic on FreeBSD used beta 0.8, while Cubic Linux uses 0.7; with the research showing a sensible Cubic ECN reaction on Linux being 0.85, correct? (~50% closer to 1).

Correct - though beta_ecn = 0.8 also worked fine for Cubic; 0.85 just seemed to be a slightly better choice in our experiments.

> So when using Cubic w/ beta 0.8 (as FreeBSD), would a sensible value for Cubic ECN there a value of 0.9?

- no, I don’t think it works like this. Whether a value for backoff with ECN is good or bad depends on the overall algorithm behavior, including its increase behavior - not just on its loss backoff factor.

Cheers,
Michael

---

From: G Fairhurst <[email-masked]>
Date: Mon, 19 Mar 2018 16:46:50 +0000

See end.

On 19/03/2018, 16:34, Michael Welzl wrote:
> Hi,
>
>
>> On Mar 19, 2018, at 3:31 PM, Richard Scheffenegger <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>> Hi Michael,
>>
>> Just thinking that the difference between loss vs. ECN cwn reduction 
>> might be defined as a relative value of each other, rather than an 
>> absolute;
>
> Ah, got it.
>
>
>> In my example, Cubic on FreeBSD used beta 0.8, while Cubic Linux uses 
>> 0.7; with the research showing a sensible Cubic ECN reaction on Linux 
>> being 0.85, correct? (~50% closer to 1).
>
> Correct - though beta_ecn = 0.8 also worked fine for Cubic; 0.85 just 
> seemed to be a slightly better choice in our experiments.
>
>
> - no, I don’t think it works like this. Whether a value for backoff 
> with ECN is good or bad depends on the overall algorithm behavior, 
> including its increase behavior - not just on its loss backoff factor.
>
+1

The range we put in the ID is [0.7,0.85]. If you are hunting for a 
suggestion, It would be that 0.85 is reasonable choice for a safe 
reduction for a cubic experiment.

Gorry

---

From: "Richard Scheffenegger" <[email-masked]>
Date: Mon, 19 Mar 2018 18:02:06 +0100

Thanks Gorry, Michael,

so to sum it up - a CC should document a safe range of tunables, and the ABE 
variant would pick values within these intervals that may be slightly more 
agressive, vs. loss based.

The guidance on the safe interval of Cubic is noted, and I'll keep that in 
mind!

Best regards,
   Richard

----- Original Message ----- 
From: "G Fairhurst" <[email-masked]>
To: "Michael Welzl" <[email-masked]>
Cc: "Richard Scheffenegger" <[email-masked]>; <[email-masked]>
Sent: Monday, March 19, 2018 5:46 PM
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-alternativebackoff-ecn-06

See end.

On 19/03/2018, 16:34, Michael Welzl wrote:
> - no, I don’t think it works like this. Whether a value for backoff with 
> ECN is good or bad depends on the overall algorithm behavior, including 
> its increase behavior - not just on its loss backoff factor.
>
+1

Gorry

---