Subject: [Ecn-in-quic] ECN-in-Quic w/ ABE

From: [email-masked]
Date: Thu, 22 Mar 2018 19:47:02 +0100

Just a quick note to those present here:

ABE (Alternative Backoff for ECN) is past WGLC in TCPM, allowing a differntiated CC control between ECN and Loss - to incentivise the deployment of ECN.

Since Quic uses Cubic, the guidance given there for differential reaction between loss and ECN marks would be directly applicable...

Any thoughts?

Best regards,
  Richard

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 22 Mar 2018 18:53:00 +0000

Hi

My opinion is that is that this should follow the guidelines in the ABE draft. The proposed QUIC ECN pseudo code also opens up for this as it specifies a separate back-off factor  kMarkReductionFactor. 
https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#recovery-draft-ecn-ce-reaction 

BR
Ingemar 

> -----Original Message-----
> From: Ecn-in-quic [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: den 22 mars 2018 19:47
> To: [email-masked]
> Subject: [Ecn-in-quic] ECN-in-Quic w/ ABE
> 
> ABE (Alternative Backoff for ECN) is past WGLC in TCPM, allowing a
> differntiated CC control between ECN and Loss - to incentivise the
> deployment of ECN.
> 
> Since Quic uses Cubic, the guidance given there for differential reaction
> between loss and ECN marks would be directly applicable...
> 
> Any thoughts?
> 
> Best regards,
>   Richard
> 
> _______________________________________________
> Ecn-in-quic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecn-in-quic

---

From: Praveen Balasubramanian <[email-masked]>
Date: Thu, 22 Mar 2018 18:55:39 +0000

QUIC as specified in drafts does not use Cubic but I expect most implementations to use it. Winquic is doing Cubic already. Are you proposing that quic cc should do the ABE experiment by default? Has its safety been proven by a wide deployment? I asked this q in tcpm and the answer was no.

________________________________
From: [email-masked]
Sent: Thursday, March 22, 2018 6:47 PM
To: [email-masked]
Subject: [Ecn-in-quic] ECN-in-Quic w/ ABE

Any thoughts?

Best regards,
  Richard

_______________________________________________
Ecn-in-quic mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fecn-in-quic&data=04%7C01%7Cpravb%40microsoft.com%7Cc0bd42e05fcb4b68184d08d5902553ba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636573412355153091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=77SDofa4ECl4rdaA1p%2F72nT0WFDWPhrRtWDu7aCYZFM%3D&reserved=0

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 22 Mar 2018 19:07:00 +0000

OK. Missed that one. I guess my conclusion may then be a bit premature.

/Ingemar

From: Ecn-in-quic [mailto:[email-masked]] On Behalf Of Praveen Balasubramanian
Sent: den 22 mars 2018 19:56
To: [email-masked]; [email-masked]
Subject: Re: [Ecn-in-quic] ECN-in-Quic w/ ABE

________________________________
From: [email-masked]<mailto:[email-masked]>
Sent: Thursday, March 22, 2018 6:47 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Ecn-in-quic] ECN-in-Quic w/ ABE

Any thoughts?

Best regards,
  Richard

_______________________________________________
Ecn-in-quic mailing list
[email-masked]<mailto:[email-masked]>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fecn-in-quic&data=04%7C01%7Cpravb%40microsoft.com%7Cc0bd42e05fcb4b68184d08d5902553ba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636573412355153091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=77SDofa4ECl4rdaA1p%2F72nT0WFDWPhrRtWDu7aCYZFM%3D&reserved=0

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 23 Mar 2018 09:46:26 +0000

So as one of the people who worked on and evaluated ABE....

There has not yet been wide deployment, but the laboratory tests referenced in the ABE draft cover a wide range of scenarios and did include cubic with ABE (and that's mentioned in the ID).  There's kernel code for BSD that tracks the latest draft:https://svnweb.freebsd.org/changeset/base/331214, the patch for linux cubic really was not much different.

I think it is hard to see any real danger arising from the use of ABE. Consider this: Cubic has used a beta (backoff) factor of 0.8 for a long time, in response to loss, before it was tuned down to 0.7. This may not have been an ideal configuration, but neither has the Internet melted, not has Linux become a useless OS in this period.

We recommend 0.8 for standard Reno-like congestion control and 0.85 for Cubic (although, in our experiments, 0.8 also works fine for Cubic)*ONLY*  in response to ECN, i.e. when the queue is normally smaller than when we see loss. This is, altogether, a way less aggressive behavior than what Cubic had for a long time in Linux.

I'd really encourage we use this rather than the loss-equivalent model - mainly because it is a significant step towards making ECN useful and allowing it to work to reduce latency - which is surely important to apps like QUIC.

Happy to say more (if needed).

Gorry

On 22/03/2018, 19:07, Ingemar Johansson S wrote:
> *From:* Ecn-in-quic [mailto:[email-masked]] *On Behalf 
> Of *Praveen Balasubramanian
> *Sent:* den 22 mars 2018 19:56
> *To:* [email-masked]; [email-masked]
> *Subject:* Re: [Ecn-in-quic] ECN-in-Quic w/ ABE
>
> QUIC as specified in drafts does not use Cubic but I expect most 
> implementations to use it. Winquic is doing Cubic already. Are you 
> proposing that quic cc should do the ABE experiment by default? Has 
> its safety been proven by a wide deployment? I asked this q in tcpm 
> and the answer was no.
>
> ------------------------------------------------------------------------
>
> *From:* [email-masked] <mailto:[email-masked]>
> *Sent:* Thursday, March 22, 2018 6:47 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [Ecn-in-quic] ECN-in-Quic w/ ABE
>
> Since Quic uses Cubic, the guidance given there for differential 
> reaction between loss and ECN marks would be directly applicable...
>
> Any thoughts?
>
> Best regards,
>   Richard
>
> [email-masked] <mailto:[email-masked]>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fecn-in-quic&data=04%7C01%7Cpravb%40microsoft.com%7Cc0bd42e05fcb4b68184d08d5902553ba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636573412355153091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=77SDofa4ECl4rdaA1p%2F72nT0WFDWPhrRtWDu7aCYZFM%3D&reserved=0>
>
>
>

---

From: Ian Swett <[email-masked]>
Date: Fri, 23 Mar 2018 10:59:45 +0000

I'd be happy to document ABE in the recovery doc.

Currently QUIC documents Reno, not Cubic, FYI.  When the QUIC WG was
started, the Cubic RFC was not yet complete.  And Cubic is a lot more
complex to describe than Reno, so I'm still happy with that choice,
personally.

On Fri, Mar 23, 2018 at 5:46 AM Gorry Fairhurst <[email-masked]>
wrote:

> There has not yet been wide deployment, but the laboratory tests
> referenced in the ABE draft cover a wide range of scenarios and did include
> cubic with ABE (and that's mentioned in the ID).  There's kernel code for
> BSD that tracks the latest draft:
> https://svnweb.freebsd.org/changeset/base/331214, the patch for linux
> cubic really was not much different.
>
> I think it is hard to see any real danger arising from the use of ABE.
> Consider this: Cubic has used a beta (backoff) factor of 0.8 for a long
> time, in response to loss, before it was tuned down to 0.7. This may not
> have been an ideal configuration, but neither has the Internet melted, not
> has Linux become a useless OS in this period.
>
> We recommend 0.8 for standard Reno-like congestion control and 0.85 for
> Cubic (although, in our experiments, 0.8 also works fine for Cubic)*ONLY*
> in response to ECN, i.e. when the queue is normally smaller than when we
> see loss. This is, altogether, a way less aggressive behavior than what
> Cubic had for a long time in Linux.
>
> I'd really encourage we use this rather than the loss-equivalent model -
> mainly because it is a significant step towards making ECN useful and
> allowing it to work to reduce latency - which is surely important to apps
> like QUIC.
>
> > <