From owner-freebsd-net@freebsd.org Tue Aug 18 22:36:23 2020 Return-Path: Delivered-To: freebsd-net@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 EE27D3A9B03 for ; Tue, 18 Aug 2020 22:36:23 +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 4BWQkG5H1cz3Xf7 for ; Tue, 18 Aug 2020 22:36:22 +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 07IMaBvY067448; Tue, 18 Aug 2020 15:36:11 -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 07IMaAo5067447; Tue, 18 Aug 2020 15:36:10 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202008182236.07IMaAo5067447@gndrsh.dnsmgr.net> Subject: Re: Is anybody using ng_pipe? In-Reply-To: To: Ryan Stone Date: Tue, 18 Aug 2020 15:36:10 -0700 (PDT) CC: Marko Zec , freebsd-net 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: 4BWQkG5H1cz3Xf7 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [2.05 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.15)[0.146]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[gmail.com]; 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]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-net]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 22:36:24 -0000 > On Tue, Aug 18, 2020 at 2:43 PM Eugene Grosbein wrote: > > Sorry, missed that. But why wasn't possible? > > There's a daemon running on the system that handles most network > configuration. It's quite inflexible and will override any manual > configuration changes. It manages firewall rules but is ignorant of > netgraph, so it will remove any dummynet rules but leave netgraph > configuration alone. It was significantly easier to just use ng_pipe, > even after having to fix or work around the bugs, than it was to fight > the daemon. > > On Tue, Aug 18, 2020 at 2:56 PM Marko Zec wrote: > > The probability that a frame is completely unaffected by BER events, > > and thus shouldn't be dropped, is currently computed as > > > > Ppass(BER, plen) = Psingle_bit_unaffected(BER) ^ Nbits(plen) > > The problem is in its calculation of Psingle_bit_unaffected(BER). The > BER is the fraction of bits that are affected, therefore it is the > probability that a bit is affected. But for some reason, > Psingle_bit_unaffected(BER) is calculated as 1 - 1/BER rather than 1 - > BER. This leads to the probability table being wrong. For example, > given a BER of 23500000, the probability that a 1500-byte packet is > not dropped is: Is this a confusion over Bit Error Rate vis Bit Error Ratio? A BER of 23500000 I must assume is 1 bit in 23500000 bits. 1 - 1/BER looks correct to me for a Bit Error Rate 1 - BER looks correct to me for a Bit Error Ratio (usually a percentage) > > (1 - 23500000/2**48)**(1500 * 8), which is approximately 99.00%. > > However, ng_pipe calculates a fixed-point probability value of > 281460603879001. To calculate whether a frame should be dropped, > ng_pipe takes this probability value and shifts it right by 17, > yielding 2147373991. It then calls rand() to generate a random number > in the range [0,2**31-1]; if the random number is larger than the > probability value than it is dropped, otherwise it is kept. The > chances that a packet is kept is therefore 2147373991/(2**31 - 1), or > about 99.99%. This looks like optimization to reduce calculation as it is done for every packet, why not do the calculation more accurately and only for each "error", see below. > It's easy enough to fix this one, but I wasn't sure that it would be > so easy to fix the TSO/LRO issue without significantly increasing the > memory usage, so I wanted to gauge whether it was worth pursuing that > avenue or if a simpler model would be a better use of my time. The > feedback is definitely that a simpler model is *not* warranted, so > let's talk about fixing TSO/LRO. I am not even sure how to deal with TSO/LRO and BER. Your not going to discard the whole segment are you? Are you going to try and packetize it, drop the packet(s) with errors, reassmble it? My method of calculating the future error point would at least allow you to just pass a whole segment without any of that hassle and only have to do that when an error is within some segment. > > On Tue, Aug 18, 2020 at 1:47 PM Rodney W. Grimes > wrote: > > Hum, that sounds like a poor implementation indeed. It seems > > like it would be easy to convert a BER into a packet drop > > probability based on bytes that have passed through the pipe. > > I'm not quite following you; can you elaborate? Would this solution > require us to update some shared state between each packet? One > advantage of the current approach is that there is no mutable state > (except, of course, when configuration changes). You would use the bytes transfered state that is already stored, and compute a "next error" point based on BER and some randomness such that your errors are not clocked at exact BER intervals. Compare the next error point to the bytes transfered + size of this packet/segment to decide if it needs dropped, if you drop then you must calculate a new "next error" point. This should considerable reduce the overhead for error rates that effect less than 50% of packets, and would be the same overhead for BER that effect every packet. And 100x more efficient for things that effect 1% of packets. -- Rod Grimes rgrimes@freebsd.org