From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 4FE173CB35 for ; Mon, 4 Oct 2021 18:45:35 -0400 (EDT) Received: by mail-wm1-x330.google.com with SMTP id o4-20020a05600c510400b0030d55d6449fso1221718wms.5 for ; Mon, 04 Oct 2021 15:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qhaafiRI7lOsMvVsT0S7iQsOy6baMezL2EXc9Fnv6yQ=; b=UNWW3yMsdGMH8mvsidEqfLqEdlNR+ZQwJbgV42NSw+g7ayO6h3G34USUfhFTtl9u1U uNAK36f7FzL1ESoFjFzlc2/ELhal/1KA3ho+hDN4mn7vpop9lD5UgclkjkFhKxcWkP+M 679TBiqhkpphEHsem4Em1tOZ7kBtZ8mX8j7z8Xd8NZA9mt0lKA8k8gyAPTeUskAux/UM 0YoHmwfUV4kGbuKBmcBjPIcCQzvqFKQQpoE5H1//6tch2HQ2z6SvpurKRjQhmjAumS4i CUAty+kEMgPFnXiXpJwmJlEwA+fph+mz6HqwlSyAhX65H5NSP5zSh8TVEit8ovGHEaE/ sAww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qhaafiRI7lOsMvVsT0S7iQsOy6baMezL2EXc9Fnv6yQ=; b=BL1mpxYzg6abXsIlbrGlBEdx+ouAc3PhDcktWIboMoz35x8WlGxWZNHyjr0PnKzgd3 Mh+TtVd7MzmYMF6dk40vhpA9uEddJAhfQua6wcdxRo6Mlr3vS/btpcc9uAdoztNBKyri SbKiuLkHKzcll8B3WF8eTv39CzXX1KdB/vg4J8571HabH7vosaWxYFfjuy7LkKfSVcac lkwccp0uRp1/RQh6lNjxhK1+FfNbLp59zVXOwfKd0xi64KAhMXiL5X5g+mEl5Yp5FWb5 M10TD5MP6F6gH+vTfBNi77gK5zsE/6Aohk7NZryzkGJYZ9q2jMlRz8yZxvoN2qY+HULX AT1g== X-Gm-Message-State: AOAM531nvHECBvc1OfYZ9v9IWoeenssJxdv9pEPSnDkDdaf0AfoqTWgq UC7PxdViKSsblEZn6oUmKBAoPsOHGgEdqookQrgZDA== X-Google-Smtp-Source: ABdhPJyFb2BuiQMH0rb05IpWLpz0DpdlbK+tILOmu51eTZTQM/cJfyPiMpTojlwrgoDUMILkSM00i2a7VOjxmK4DfpY= X-Received: by 2002:a05:600c:1907:: with SMTP id j7mr21017784wmq.184.1633387534134; Mon, 04 Oct 2021 15:45:34 -0700 (PDT) MIME-Version: 1.0 References: <56ef13985bd34834916aabef978db1f1@EX16-05.ad.unipi.it> In-Reply-To: From: Matt Mathis Date: Mon, 4 Oct 2021 15:45:22 -0700 Message-ID: To: Luigi Rizzo Cc: Bob McMahon , Karl Auerbach , "rpm@lists.bufferbloat.net" , Luigi Rizzo , bloat , Ben Greear Content-Type: multipart/alternative; boundary="000000000000c14ac805cd8eab0a" Subject: Re: [Rpm] [Bloat] Relentless congestion control for testing purposes X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2021 22:45:35 -0000 --000000000000c14ac805cd8eab0a Content-Type: text/plain; charset="UTF-8" Please don't send this upstream. It would makesTCP into the evil transport from hell. Modern loss recovery is robust enough to run hardcoded cwnd= and persistent losses, Please don't make this too easy for people who are intent on getting their "fair" share of the network before the greedy people. Dave overlooked an important detail in relentless TCP: It reduced the window by exactly the losses, such that the presented load was exactly the quantity of data successfully delivered on the previous RTT. I have forgotten the details of the increase function, but it was something Reno like but only on loss less RTTs. If you want to adapt TCP Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay We must not tolerate intolerance; however our response must be carefully measured: too strong would be hypocritical and risks spiraling out of control; too weak risks being mistaken for tacit approval. On Fri, Oct 1, 2021 at 11:02 AM Luigi Rizzo via Rpm < rpm@lists.bufferbloat.net> wrote: > On Fri, Oct 1, 2021 at 6:33 PM Bob McMahon > wrote: > > > > hmm, this looks interesting to a test & measurement guy. Can it be done > with a setsockopt? I might want to add this as an iperf2 option, > particularly if it's broadly available, > > > I would be happy to submit it as one or two upstream patches -- > perhaps one to implement > the basic "ignore_holes" + setsockopt(), and another mechanism (if > there isn't one > already) to override defaults sockopts on certain sockets. > > I do think we need more readily available testing tool, > > cheers > luigi > _______________________________________________ > Rpm mailing list > Rpm@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/rpm > --000000000000c14ac805cd8eab0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please don't send this upstream.=C2=A0 =C2=A0It would = makesTCP into the evil=C2=A0transport=C2=A0from hell.=C2=A0 =C2=A0 Modern l= oss recovery is robust enough to run hardcoded cwnd=3D<blat> and pers= istent losses, Please don't make this too easy for people who are inten= t on getting their "fair" share of the network before the greedy= =C2=A0people.

Dave overlooked an important detail in rel= entless TCP: It reduced the window by exactly the losses, such that the pre= sented=C2=A0load was exactly the quantity of data successfully delivered on= the previous RTT.=C2=A0 =C2=A0I have forgotten the details of the increase= function, but it was something=C2=A0Reno like but only on loss less RTTs.<= /div>



If you want to adapt= TCP=C2=A0
Thanks,
--MM--
The best way to predict the future is= to create it. =C2=A0- Alan Kay

We must not tolerate intolerance;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however our response must be= carefully measured:=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 too strong would be hypocritical and risks spiraling out of control;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks being mist= aken for tacit approval.


On Fr= i, Oct 1, 2021 at 11:02 AM Luigi Rizzo via Rpm <rpm@lists.bufferbloat.net> wrote:
On Fri, Oct 1, 2021 at 6:33 P= M Bob McMahon <bob.mcmahon@broadcom.com> wrote:
>
> hmm, this looks interesting to a test & measurement guy. Can it be= done with a setsockopt? I might want to add this as an iperf2 option, part= icularly if it's broadly available,


I would be happy to submit it as one or two upstream patches --
perhaps one to implement
the basic "ignore_holes" + setsockopt(), and another mechanism (i= f
there isn't one
already) to override defaults sockopts on certain sockets.

I do think we need more readily available testing tool,

cheers
luigi
_______________________________________________
Rpm mailing list
Rpm@lists.bu= fferbloat.net
https://lists.bufferbloat.net/listinfo/rpm
--000000000000c14ac805cd8eab0a--