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

[Bruno George Moraes <brunogm0@gmail.com>]

[-- 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 --]