[Ecn-sane] [Flent-users] [bbr-dev] duplicating the BBRv2 tests at iccrg in flent?
Neal Cardwell
ncardwell at google.com
Tue Apr 9 10:33:55 EDT 2019
On Tue, Apr 9, 2019 at 2:31 AM Sebastian Moeller <moeller0 at gmx.de> wrote:
>
> I guess I was too subtle.... The following is in no way incompatible with
> what I wrote. The point I wanted to make is that redefining CE without also
> introducing an equivalent of 'stop hard, ASAP' is an incomplete solution.
> Once you introduce the missing signal the SCE proposal is a better fit than
> L4S.
> Also both BBR and L4S both aim at basically ignoring drops as immediate
> signals, both for good reasons like better throughput on links with
> spurious drops and some reordering tolerance.
> IMHO it is wonderfully absurd in that light to try to basically shoehorn a
> dctcp style CE-marker into the internet, which does not allow to carry as
> quickly a stop hard signal as tcp-friendly ECN does today. To repeat the
> argument is not against finer-grained load information from the bottleneck,
> but rather against doing only half the job and falling short of solving the
> problem.
> The rationale below would maybe make sense if all the internet's
> bottlenecks would talk dctcp style ECN, but until then the rationale falls
> apart.
OK, I think I now understand what you are suggesting. I can see the
potential value of having both a DCGCP/L4S/SCE-style signal and a
RFC3168-style signal. In your previous e-mail I thought you were arguing
for a pure RFC3168-style approach; but if the proposal is to have both
styles, and that's what gets deployed, that sounds usable AFAICT.
neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/ecn-sane/attachments/20190409/cc6dbbbf/attachment-0001.html>
More information about the Ecn-sane
mailing list