From owner-freebsd-pf@freebsd.org Tue Jul 30 00:06:11 2019 Return-Path: Delivered-To: freebsd-pf@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 54516BADF2 for ; Tue, 30 Jul 2019 00:06:11 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F089836A1; Tue, 30 Jul 2019 00:06:06 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x6U0621b046602; Mon, 29 Jul 2019 17:06:02 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x6U062pP046601; Mon, 29 Jul 2019 17:06:02 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201907300006.x6U062pP046601@gndrsh.dnsmgr.net> Subject: Re: pf and dummynet In-Reply-To: To: Kristof Provost Date: Mon, 29 Jul 2019 17:06:02 -0700 (PDT) CC: "Rodney W. Grimes" , mike tancsa , freebsd-pf@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 3F089836A1 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.23 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.76)[0.762,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.84)[0.840,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.70)[0.695,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.04)[ip: (0.14), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.05)] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 00:06:11 -0000 > On 29 Jul 2019, at 22:15, Rodney W. Grimes wrote: > >> On 29 Jul 2019, at 20:22, mike tancsa wrote: > >>> On 7/29/2019 1:51 PM, Kristof Provost wrote: > >> In general I?d expect quality of service and bandwidth limits to only > >> be effective in the upstream direction (when going from a fast link to a > >> slow one). There?s no good way to limit how much traffic other > >> machines send to you. > > > > Though dummynet is most effective in on the outbound > > stream (absolute control) it can be used to good effect > > on an incoming stream due to the end-to-end paradigm of > > the internet and the fact that congestion must be dealt > > with. > > > > If dummynet holds packets and parcels them into a box at > > a lower rate for things like TCP you'll end up reducing > > the congestion window and hence the senders rate. Or you > > can get into the ACK clock situation here the sender simply > > does not send any more data until it gets an ack back as > > it already has filled the congestion window. > > > > I have been using dummynet for decades in this way, > > and it more or less "just works." > > > True, with the caveat that that?s only for TCP of course. All protocols transported over the internet should have some form of congestion control, sometimes that is packet loss :-) Most protocols have similiar issues that do lead to self clocking when the above is implemented. If you slow down the packets the protocol slows down overall except for very short lived things. >From our (Some Congestion Experienced developement group) recent letter to the chairs of ietf tsvwg in regards to L4S working group last call we rasied this point: RFC-8311 section 2.1: Effective congestion control is REQUIRED. These principles applies to all traffic transported over the internet and the ietf is not going to approve any thing that ignores congestion. Hence anything that does not respond to the above traffic mettering (congestion) situation is fundemantally broken by standard now. People are now talking about pacing IW10 in TCP (I believe this is already implemented in Linux, iirc Randall explained to me what Netflix does as this burst tends to cause subtle problems. > Regards, > Kristof -- Rod Grimes rgrimes@freebsd.org