From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 015743B29E for ; Mon, 1 Apr 2019 13:10:56 -0400 (EDT) Received: by mail-yb1-xb32.google.com with SMTP id x84so1255617ybg.9 for ; Mon, 01 Apr 2019 10:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=trED5+w/kto0qxsualMYOIXWJEWBneorOJtC1r4OTv8=; b=Xl1Bi1ye0xTE520RftDLlN6HxAFlr7Ip8JlQpj2vCtHv+NUHPAoPHT1ObLZO+kiiFi KhRGesLRCZszX7hDIvLWim9iQ01fqPm9eOvEKC5L7SRJZi96V18TKRuzsUtg+mJG8RR0 giekqR1NgoIWDPD/axzbomop1ya9txaZm16zfCWaZ1GrwcUPbclTIDFM3FVfgkxjqy91 L65B3VJGkWU8EJ6+83dSgfOpAwNHu4Y4R2UpwWmKHONrac8alxjUzFU932cF7RnhraQE 93US1H4hoaclzaW4KW/FyaLXReOxDdGzbTHWdlTrVszNXFRmCJTDxZQbcM6EUBMOeHJu h6Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=trED5+w/kto0qxsualMYOIXWJEWBneorOJtC1r4OTv8=; b=b+/szxoCq00etripplmHU0Ik1YuO2c4IiMT5+vQbdxrjQz6rEtBeiz2QbjEiNFPEpn Q/cSNiopDwL1sI59IGkWEBiFAULVHh4vvMT6M//jMgPG00/jN+zV0F7+0qv/v3xm5nvY NgBzloBad+AononzwNe0hIWY6cyDEJHHK1WbiXBCrqyJnFAsQVLQiMweLACfurF6qYQP bIc3WVkE1pjzGZUJXIK9JDspfcJ3jRt3UiFH7OudziecPYKciVX96oFcgv3PMibNGl2Z PwytVtyNu/2+uK19u0G0i4NBa1yuhgBm4VmK3JW5vQ6OJ3Vj7vSWyDUFZq4TWfX/A8oz i8ww== X-Gm-Message-State: APjAAAVp2CZLlMce0hUvR/wG5oDHLinKCZI9JpSD2irLiqjT+HgF7dwW qvYt+f+a4iQNOT+sY6laykxF1OTYex3U5L9A3L0= X-Google-Smtp-Source: APXvYqw4toTcGeuUu6zGzWbYr6awoHnwKus0ifxfhV8tXWe2FeJ6gjfcO5KuQaGBuyKGenjWWv7rQDQnsgFen2Fv2SQ= X-Received: by 2002:a25:c042:: with SMTP id c63mr55265499ybf.288.1554138656327; Mon, 01 Apr 2019 10:10:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bruno George Moraes Date: Mon, 1 Apr 2019 14:10:43 -0300 Message-ID: To: Dave Taht Cc: Jeremy Harris , ECN-Sane Content-Type: multipart/alternative; boundary="0000000000008acfd905857b1a07" Subject: Re: [Ecn-sane] BBRv2 presentation in ICCRG video X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 17:10:57 -0000 --0000000000008acfd905857b1a07 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 qual= ity 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 =C3=A0s 07:13, Dave Taht esc= reveu: > 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 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/prototy= pe1 > > > 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=C3=A4ht > 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 > --0000000000008acfd905857b1a07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Prototype1 results looking better than BBR-V2!!!
=C2= =A0 =C2=A0=C2=A0
Question:=C2=A0 =C2=A0How the BBR-v2 "degre= e of aggregation" compares to SCE explicit signal?=C2=A0=C2=A0


=C2=A0Morton's presentation QA an L4s = slide of RFC6660 -> RFC5559 is shown with some problems with ECT0/ECT1 m= arking,=C2=A0 BUT=C2=A0 those RFCs are defining something called "Pre-Congestion Notificatio= n":=C2=A0=C2=A0=C2=A0
" The objective of Pre-Congestion Notif= ication (PCN) is to protect the=C2=A0quality 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 te=
rminate
   some of=
 the existing flows.  To achieve this, the overall rate of PCN-traffic is m=
etered 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 ov=
erloads before any congestion occurs.  The level of marking allows boundary=
 nodes 
   to make=
 decisions about whether to admit or terminate."=C2=A0=

Even if it is important to manage new flow= s disturbing QoS in the same Diffserv. I view it as low priority than fixin= g ECN for the "network" with fine-grained info like SCE does.=C2= =A0 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 Battl= e Royale!!!=C2=A0

Relevant RFCs: 6040, 5696, 8311<= /div>
=C2=A0

Em seg, 1 de abr de 2019 =C3=A0s 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,
>=C2=A0 =C2=A0Jeremy
>
>
> _______________________________________________
> Ecn-sane mailing list
> Ec= n-sane@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane<= /a>



--

Dave T=C3=A4ht
CTO, TekLibre, LLC
ht= tp://www.teklibre.com
Tel: 1-831-205-9740
_______________________________________________
Ecn-sane mailing list
Ecn-san= e@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/ecn-sane
--0000000000008acfd905857b1a07--