[Ecn-sane] BBRv2 presentation in ICCRG video

[Ecn-sane] BBRv2 presentation in ICCRG video

[Dave Taht]

So, it turns out the BBRv2 team was planning on using a
l4s-style/dctcp-ish ecn response. The video is up here:

 https://www.youtube.com/watch?v=cJ-0Ti8ZlfE

alternatively, here:

http://mail.taht.net/~iccrg/IETF104-ICCRG-20190328-1610.webm

The Q&A session afterward (about 28 minutes in) showed that the BBRv2 team were
not even testing against fully deployed fq_codel's RFC3168 ecn
response and there were all
sorts of other fun questions following. So I think this answers Vint
"Seersucker"' Cerf's ecn-sane's team's
question "is ECN even needed for BBR?"

I'm SO glad we got our SCE alternative ready for publication in time
to reset the clock by a lot. The preso in tsvwg:
https://www.youtube.com/watch?v=JQmWyr0JDJM&t=1h3m50s

Also...

Over the last week, jonathan, pete, and rodney (and jason?) also got a
modified reno-style transport to
respond properly to SCE:
https://github.com/dtaht/bufferbloat-rfcs/tree/master/sce/results/prototype1
was the first one, the current one is even more excellent.

Fun times in the congestion control universe!

-- 

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

Re: [Ecn-sane] BBRv2 presentation in ICCRG video

[Jeremy Harris]

On 01/04/2019 10:58, Dave Taht wrote:
> Over the last week, jonathan, pete, and rodney (and jason?) also got a
> modified reno-style transport to
> respond properly to SCE:
> https://github.com/dtaht/bufferbloat-rfcs/tree/master/sce/results/prototype1
> was the first one

Why are the throughput graphs annotated as "segment length"?
What are we really graphing?
-- 
Cheers,
  Jeremy

Re: [Ecn-sane] BBRv2 presentation in ICCRG video

[Dave Taht]

Yea, that's a mistake on the first set of graphs. look on the right
side for the right numbers.

On Mon, Apr 1, 2019 at 12:13 PM Jeremy Harris <jgh@wizmail.org> wrote:
>
> On 01/04/2019 10:58, Dave Taht wrote:
> > Over the last week, jonathan, pete, and rodney (and jason?) also got a
> > modified reno-style transport to
> > respond properly to SCE:
> > https://github.com/dtaht/bufferbloat-rfcs/tree/master/sce/results/prototype1
> > was the first one
>
> Why are the throughput graphs annotated as "segment length"?
> What are we really graphing?
> --
> Cheers,
>   Jeremy
>
>
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane



-- 

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

Re: [Ecn-sane] BBRv2 presentation in ICCRG video

[Bruno George Moraes]

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

Prototype1 results looking better than BBR-V2!!!

Question:   How the BBR-v2 "degree of aggregation" compares to SCE explicit
signal?


 Morton's presentation QA an L4s slide of RFC6660 -> RFC5559 is shown with
some problems with ECT0/ECT1 marking,  BUT  those RFCs are defining
something called "Pre-Congestion Notification":
" The objective of Pre-Congestion Notification (PCN) is to protect the quality
of service (QoS) of inelastic flows within a Diffserv domain in a simple,
scalable, and robust fashion. Two mechanisms are used:

   admission control, to decide whether to admit or block a new flow
request, and (in abnormal circumstances) flow termination, to decide
whether to terminate

   some of the existing flows.  To achieve this, the overall rate of
PCN-traffic is metered on every link in the
   domain, and PCN packets are appropriately marked when certain
configured rates are exceeded.  These configured rates are below the
   rate of the link, thus providing notification to boundary nodes
about overloads before any congestion occurs.  The level of marking
allows boundary nodes

   to make decisions about whether to admit or terminate."


Even if it is important to manage new flows disturbing QoS in the same
Diffserv. I view it as low priority than fixing ECN for the "network" with
fine-grained info like SCE does.  Where and how a diffserv addmission
control would be better suited ?
Then the question is where this PCN is actually deployed ?

ps. There are many proposals for ECT(1), maybe a ECN-SANE sub objective
would be to document and call out every candidate for a Battle Royale!!!

Relevant RFCs: 6040, 5696, 8311


Em seg, 1 de abr de 2019 às 07:13, Dave Taht <dave.taht@gmail.com> escreveu:

> Yea, that's a mistake on the first set of graphs. look on the right
> side for the right numbers.
>
> On Mon, Apr 1, 2019 at 12:13 PM Jeremy Harris <jgh@wizmail.org> wrote:
> >
> > On 01/04/2019 10:58, Dave Taht wrote:
> > > Over the last week, jonathan, pete, and rodney (and jason?) also got a
> > > modified reno-style transport to
> > > respond properly to SCE:
> > >
> https://github.com/dtaht/bufferbloat-rfcs/tree/master/sce/results/prototype1
> > > was the first one
> >
> > Why are the throughput graphs annotated as "segment length"?
> > What are we really graphing?
> > --
> > Cheers,
> >   Jeremy
> >
> >
> > _______________________________________________
> > Ecn-sane mailing list
> > Ecn-sane@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/ecn-sane
>
>
>
> --
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane
>

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