[Cake] paper: per flow fairness in a data center network

[Cake] paper: per flow fairness in a data center network

[Dave Taht]

While I strongly agree with their premise:

"Multi-tenant DCNs cannot rely on specialized protocols and mechanisms
that assume single ownership and end-system compliance. It is
necessary rather to implement general, well-understood mechanisms
provided as a network service that require as few assumptions about DC
workload as possible."

... And there's a solid set of links to current work, and a very
interesting comparison to pfabric, their DCTCP emulation is too flawed
to be convincing, and we really should get around to making the ns2
fq_codel emulation fully match reality. This is also a scenario where
I'd like to see cake tried, to demonstrate the effectiveness (or not!)
of 8 way set associative queuing, cobalt, per host/per flow fq, etc,
vs some of the workloads they outline.

https://perso.telecom-paristech.fr/drossi/paper/rossi18hpsr.pdf

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

Re: [Cake] paper: per flow fairness in a data center network

[dario.rossi]

[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]

Ciao Dave (&all)
While I'd love to do a bit more on the topic, I recently joined Huawei, and while I still work on networking,  this one is not so aligned with my current set of activities... 
so I cannot unfortunately help moving forward :/
Best,D.
PS fyi Also I tend to read this email less freqiently than @huawei
Sent from my new-but-still-not-so-smart-phone. Excuse my typos and its random fixes
Oo   Chair holder NewNet@Paris  >    Professor, Telecom ParisTech~     Professor, Ecole Polytechnique 

-------- Original message --------From: Dave Taht <dave.taht@gmail.com> Date: 12/6/18  04:18  (GMT+01:00) To: bloat <bloat@lists.bufferbloat.net>, Cake List <cake@lists.bufferbloat.net>, aqm@ietf.org Subject: paper: per flow fairness in a data center network 
While I strongly agree with their premise:

"Multi-tenant DCNs cannot rely on specialized protocols and mechanisms
that assume single ownership and end-system compliance. It is
necessary rather to implement general, well-understood mechanisms
provided as a network service that require as few assumptions about DC
workload as possible."

... And there's a solid set of links to current work, and a very
interesting comparison to pfabric, their DCTCP emulation is too flawed
to be convincing, and we really should get around to making the ns2
fq_codel emulation fully match reality. This is also a scenario where
I'd like to see cake tried, to demonstrate the effectiveness (or not!)
of 8 way set associative queuing, cobalt, per host/per flow fq, etc,
vs some of the workloads they outline.

https://perso.telecom-paristech.fr/drossi/paper/rossi18hpsr.pdf

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

[-- Attachment #2: Type: text/html, Size: 2642 bytes --]

Re: [Cake] paper: per flow fairness in a data center network

[Luca Muscariello]

[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]

I disagree on the claims that DC switches do not implement anything.
They do, from quite some time now.

https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-738488.html



On Thu, Dec 6, 2018 at 4:19 AM Dave Taht <dave.taht@gmail.com> wrote:

> While I strongly agree with their premise:
>
> "Multi-tenant DCNs cannot rely on specialized protocols and mechanisms
> that assume single ownership and end-system compliance. It is
> necessary rather to implement general, well-understood mechanisms
> provided as a network service that require as few assumptions about DC
> workload as possible."
>
> ... And there's a solid set of links to current work, and a very
> interesting comparison to pfabric, their DCTCP emulation is too flawed
> to be convincing, and we really should get around to making the ns2
> fq_codel emulation fully match reality. This is also a scenario where
> I'd like to see cake tried, to demonstrate the effectiveness (or not!)
> of 8 way set associative queuing, cobalt, per host/per flow fq, etc,
> vs some of the workloads they outline.
>
> https://perso.telecom-paristech.fr/drossi/paper/rossi18hpsr.pdf
>
> --
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>

[-- Attachment #2: Type: text/html, Size: 2336 bytes --]

Re: [Cake] [Bloat] paper: per flow fairness in a data center network

[Dave Taht]

Luca Muscariello <luca.muscariello@gmail.com> writes:

> I disagree on the claims that DC switches do not implement anything.
> They do, from quite some time now.
>
> https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-738488.html

I'm really impressed. I'd have probably heard about it if they'd
mentioned bufferbloat once :/.

The graphs comparing their performance to arista's are far, far, far too
small to read. You can certainly see a huge improvement on mice in this
paper.

is there a better copy of this paper around?

What's the cheapest form of this switch I can buy? (or beg, borrow, or
steal?) I do need a 10GigE-40GigE capable switch in the lab, and BOY oh
boy oh boy would I love to test this one.

Has this tech made it into their routing products?

>
> On Thu, Dec 6, 2018 at 4:19 AM Dave Taht <dave.taht@gmail.com> wrote:
>
>     While I strongly agree with their premise:
>     
>     "Multi-tenant DCNs cannot rely on specialized protocols and
>     mechanisms
>     that assume single ownership and end-system compliance. It is
>     necessary rather to implement general, well-understood mechanisms
>     provided as a network service that require as few assumptions
>     about DC
>     workload as possible."
>     
>     ... And there's a solid set of links to current work, and a very
>     interesting comparison to pfabric, their DCTCP emulation is too
>     flawed
>     to be convincing, and we really should get around to making the
>     ns2
>     fq_codel emulation fully match reality. This is also a scenario
>     where
>     I'd like to see cake tried, to demonstrate the effectiveness (or
>     not!)
>     of 8 way set associative queuing, cobalt, per host/per flow fq,
>     etc,
>     vs some of the workloads they outline.
>     
>     https://perso.telecom-paristech.fr/drossi/paper/rossi18hpsr.pdf
>     
>     -- 
>     
>     Dave Täht
>     CTO, TekLibre, LLC
>     http://www.teklibre.com
>     Tel: 1-831-205-9740
>     _______________________________________________
>     Cake mailing list
>     Cake@lists.bufferbloat.net
>     https://lists.bufferbloat.net/listinfo/cake
>     
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Cake] [Bloat] paper: per flow fairness in a data center network

[Dave Taht]

Found the PDF. Much more readable.

https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-738488.pdf

As much lust as I have in my heart for this switch, it costs as much
as a car! Sigh.

On Sat, Dec 15, 2018 at 9:09 AM Dave Taht <dave@taht.net> wrote:
>
> Luca Muscariello <luca.muscariello@gmail.com> writes:
>
> > I disagree on the claims that DC switches do not implement anything.
> > They do, from quite some time now.
> >
> > https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-738488.html
>
> I'm really impressed. I'd have probably heard about it if they'd
> mentioned bufferbloat once :/.
>
> The graphs comparing their performance to arista's are far, far, far too
> small to read. You can certainly see a huge improvement on mice in this
> paper.
>
> is there a better copy of this paper around?
>
> What's the cheapest form of this switch I can buy? (or beg, borrow, or
> steal?) I do need a 10GigE-40GigE capable switch in the lab, and BOY oh
> boy oh boy would I love to test this one.
>
> Has this tech made it into their routing products?
>
> >
> > On Thu, Dec 6, 2018 at 4:19 AM Dave Taht <dave.taht@gmail.com> wrote:
> >
> >     While I strongly agree with their premise:
> >
> >     "Multi-tenant DCNs cannot rely on specialized protocols and
> >     mechanisms
> >     that assume single ownership and end-system compliance. It is
> >     necessary rather to implement general, well-understood mechanisms
> >     provided as a network service that require as few assumptions
> >     about DC
> >     workload as possible."
> >
> >     ... And there's a solid set of links to current work, and a very
> >     interesting comparison to pfabric, their DCTCP emulation is too
> >     flawed
> >     to be convincing, and we really should get around to making the
> >     ns2
> >     fq_codel emulation fully match reality. This is also a scenario
> >     where
> >     I'd like to see cake tried, to demonstrate the effectiveness (or
> >     not!)
> >     of 8 way set associative queuing, cobalt, per host/per flow fq,
> >     etc,
> >     vs some of the workloads they outline.
> >
> >     https://perso.telecom-paristech.fr/drossi/paper/rossi18hpsr.pdf
> >
> >     --
> >
> >     Dave Täht
> >     CTO, TekLibre, LLC
> >     http://www.teklibre.com
> >     Tel: 1-831-205-9740
> >     _______________________________________________
> >     Cake mailing list
> >     Cake@lists.bufferbloat.net
> >     https://lists.bufferbloat.net/listinfo/cake
> >
> >
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740