[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
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] HotEdge '19 Preliminary Call for Papers Now Available!

[Dave Taht]

Since the impending death of g+, I have been putting up little interesting
links, here. I read *every* paper (1700 now on google scholar!), and have a
weekly search for various bloat related topics, but 90% of it isn't useful,
but
I've rather enjoyed the associated burst in discussion here when I do find
something interesting. I didn't know until one of those papers in the past
week or two, that cell still had a fragmentation problem! I would really
like it if more pointed out more stuff...

I also wish more of those 4000+ authors of bloat related stuff, subscribed
to the bloat list, and that google indexed it better.

It is perhaps too much to hope that the folk behind the 5g rollout and
actively developing products, are paying attention. Certainly AT&T totally
missed the bufferbloat problem on their first devices... :(

https://www.tomsguide.com/us/5g-release-date,review-5063.html

Anyway, of all the conferences we do, I like usenix and their policies the
best. Perhaps we can get something in on cobalt...


On Wed, Dec 5, 2018 at 10:35 AM Irfan Ahmad  wrote:

> Start preparing your paper submissions for HotEdge '19….
> [image: HotEdge '19, July 9, 2019, Renton, WA, USA]
> 
>
> Dear Dave,
>
> We are pleased to announce that the Preliminary Call for Papers
> 
> for the 2019 USENIX Workshop on Hot Topics in Edge Computing is now
> available (HotEdge '19
> ).
> HotEdge '19 will take place on July 9, 2019, in Renton, WA, USA, and will
> be co-located with the 2019 USENIX Annual Technical Conference
> 
> .
>
> HotEdge '19 solicits original ideas on a wide range of edge computing
> topics. We strongly encourage the submission of nascent ideas and position
> papers that describe interesting research directions and work that is in
> its formative stages. HotEdge will emphasize existing and new applications
> of edge computing, not just techniques toward a working edge.
>
> The HotEdge '19 program committee will place a strong emphasis on
> encouraging early-stage ideas. As a workshop, our key role is to provide a
> place where novel ideas at their early stages can see the light of day long
> before they are ready for publication at the various conferences of record
> such as SEC and ICDCS. Hence, we will be looking for papers that generate
> discussion and debate. A good way to think about this is that if you are
> only a few months away from submitting to SEC, ICDCS, INFOCOM, NSDI, OSDI,
> or SOSP, etc., you are probably already past the sweet spot for HotEdge.
>
> Submissions are due by *Thursday, March 14, 2019*. Please read through
> the complete Preliminary Call for Papers
> 
> for additional details, including a list of topics of interest, and
> submission instructions.
>
> We look forward to receiving your submissions!
>
> Irfan Ahmad, *CachePhysics*
> Swaminathan Sundararaman, *ParallelM*
> HotEdge '19 Program Co-Chairs
> hotedge19cha...@usenix.org
>
> *Please use hotedge19cha...@usenix.org  to
> contact Irfan Ahmad and Swaminathan Sundararaman. The email address
> irfan.ah...@usenix.org  is for automated list
> management only.*
>
> About this mailing list:
>
> USENIX
> 
> never shares, sells, rents, or exchanges email addresses of its members,
> conference attendees, and other constituents. Review our privacy policy
> 
> .
>
> We would like to continue sending you occasional email announcements like
> this one. However, if you no longer want to receive emails from USENIX,
> please click here
> 
> to opt out.
>
> If you have any questions about the mailing list, please email
> off...@usenix.org . We
> may also be reached via postal mail:
>
> USENIX Association
> 2560 Ninth St, Suite 215, Berkeley, CA 94710, USA
>


-- 

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

Re: [Cake] COBALT implementation in ns-3 with results under different traffic scenarios

[Jonathan Morton]

> On 5 Dec, 2018, at 2:23 pm, Jendaipou Palmei  
> wrote:
> 
> We have uploaded the corresponding graphs for reference CoDel. 
> 
> Link: https://github.com/Daipu/COBALT/wiki/Drop-Count-Graph

Quite a remarkable difference here - just look at the scales for the 
corresponding graphs!  I'm actually rather surprised to see reference Codel 
reaching such deep activation states, when COBALT stays very shallowly 
activated but is still effective.  It makes me wonder whether there's something 
odd going on with the ns3 version of Codel.

I'm sure more insight will be gained from the actual drop traces.

> We have also plotted the instantaneous throughput for all flows in Light 
> traffic scenario for COBALT and CoDel.
> These graphs are plotted for packet size with 1000 bytes and 1500 bytes.
> 
> Link: https://github.com/Daipu/COBALT/wiki/Throughput-for-Separate-Flow

This isn't quite what I was thinking of, but it's still interesting.  I was 
looking for all flows from a single run plotted on a single graph, perhaps 
stacked so that their sum is visible as overall throughput.  That way, the 
interaction between one flow backing off and others taking over its unused 
capacity becomes clearer, and it is possible to see if more than one flow backs 
off at the same time (indicating that both got hit by AQM).

There are also sampling artefacts apparent in these graphs as rapid 
oscillations around a mean value.  You might want to look into ways to 
eliminate or otherwise account for those.

> We're currently working on the following:
> 
> 1. plots for the actual number of marks/drops per time interval for COBALT, 
> CoDel, and PIE.
> 2. zoomed in plots on small time intervals to show the dynamic behavior of 
> the algorithm.
> 3. a file showing the timestamp of each drop.

I await these with interest.

 - Jonathan Morton

___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] COBALT implementation in ns-3 with results under different traffic scenarios

[Jendaipou Palmei]

Hello Dave and Jonathan,

Thanks for the feedback!

We have uploaded the corresponding graphs for reference CoDel.

Link: https://github.com/Daipu/COBALT/wiki/Drop-Count-Graph

We have also plotted the instantaneous throughput for all flows in Light
traffic scenario for COBALT and CoDel.
These graphs are plotted for packet size with 1000 bytes and 1500 bytes.

Link: https://github.com/Daipu/COBALT/wiki/Throughput-for-Separate-Flow

We're currently working on the following:

1. plots for the actual number of marks/drops per time interval for COBALT,
CoDel, and PIE.
2. zoomed in plots on small time intervals to show the dynamic behavior of
the algorithm.
3. a file showing the timestamp of each drop.

About collaborating for writing a paper on this work: we'd be glad to do so
:) thanks for your guidance and help!

Thanks and regards
Jendaipou Palmei
Shefali Gupta

On Tue, Dec 4, 2018 at 8:51 PM Dave Taht  wrote:

> On Tue, Dec 4, 2018 at 7:02 AM Jonathan Morton 
> wrote:
> >
> > > On 4 Dec, 2018, at 12:31 pm, Jendaipou Palmei <
> jendaipoupal...@gmail.com> wrote:
> > >
> > > We have uploaded the plots for the 'count' variable of COBALT (with a
> segment size of 1500 and 1000 bytes).
> > >
> > > Link: https://github.com/Daipu/COBALT/wiki/Cobalt-Drop-Count
> > >
> > > We have not yet implemented ECN feature in COBALT, so packets are
> currently dropped instead of being marked.
> > >
> > > Are these the plots that you were referring to?
> >
> > More-or-less, yes, though these actually show an internal state variable
> of the Codel algorithm rather than the actual number of marks/drops per
> time interval.  I was hoping to see similar graphs for the reference-Codel
> and PIE runs, since we can gain more insight from that, and PIE doesn't
> have an internal "count" variable that corresponds with Codel.
> Nevertheless, the view into "count" behaviour is interesting in itself, and
> I'd like to see the corresponding graphs from reference Codel.
> >
> > An artefact visible in these graphs is an apparent lack of sampling
> while not in the dropping state.  Thus you seem to have a gradual ramp from
> 0 to 1 count over the several seconds interval between activations, though
> in fact the variable is discrete.  It would be better to show that
> transition more precisely.
> >
> > For study, it is also often helpful to zoom in on small time intervals
> to see the dynamic behaviour of the algorithm, particularly during the
> transition from slow-start to steady-state, where there is seemingly a big
> difference between reference Codel and COBALT.
>
> I'm loving the slow start result.
>
> >
> > Another interesting graph to produce for each algorithm and traffic type
> is the instantaneous throughput of each flow.  This offers insight into the
> relative fairness of each algorithm, and might help to explain the anomaly
> seen with 1000-byte packets and COBALT.  Usually this graph also reveals,
> through the shape of each throughput curve, which CC algorithm is in use -
> currently I'm guessing NewReno.  CUBIC and CTCP, which are also in common
> use, would behave differently.
>
> a file showing the timestamp of each drop would be easier to post process.
>
> >
> >  - Jonathan Morton
> >
>
>
> --
>
> 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