From owner-freebsd-net@freebsd.org Tue Aug 18 21:01:52 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 21BD83C6FE1 for ; Tue, 18 Aug 2020 21:01:52 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BWNdB4rx2z4fSv for ; Tue, 18 Aug 2020 21:01:50 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-ed1-x534.google.com with SMTP id v22so16384709edy.0 for ; Tue, 18 Aug 2020 14:01:50 -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=gYv0wU2plGZaHtWPcVAedk+GPQG8eI2bCJOlFi0vIRg=; b=TXFiQLuYeIIEwrYIe37ejR560l6LKVPUYgV9Y9HyUY5buQ4XD7WAGyA7mi7V8c2Uyd ggwQGLxezy0/Le65YnAK+5n2usKFcu49CdMjGu56IvoYK3Ffqby+WwJtg8CGEhI4WNbe iEV0qBO195pi7S7EVV/ZeQdwTvl6h38KLAYFakNvdkCrWiECaIbXwsb3WDhpKUKynJNS +jMpLWdMqFlGpKyIuqk2cK9KEmTTH/huBCiVByeyZ8/7R81QBoaXJr1LLdUGRN198pUD EvOtFORcguBX7BvFPnJwtDmp27kNcyjC9MonxhSMeIos1TsDYnvzipLT6lQRqtkPbnzH 6TjQ== 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=gYv0wU2plGZaHtWPcVAedk+GPQG8eI2bCJOlFi0vIRg=; b=gSbxwTwArqPsfCujh0fyNxzTtsoXF6aGgtDGBx8lXpX1r0ZMZeDX6hzyWa9h2Y476X wP8x0k/zkafNewGhYtWg5g5tEZOLR4x/PV/t423HioEbZNRdmh9odY1kGkFgO2B++DG1 YuZrxqQLy+Hj1i+2hDR+2tuptpZ6UDxZTkOL55lQtmxoamssLzBpFX39bVRv02SePqnq sgE1q2IwdFiSxcGwtIWA4DXK8Mu17GGzMQmJh8CKy6BWDx9o2tbGfXoP5EvYtkRoG0vH Mb1HDpBoL6/cKqQ9s4ECSwlQyHk5NPcz+q+K0NAU/grWj8JmDtS5T60UQtd68EYxB82b cJzQ== X-Gm-Message-State: AOAM533Sv4IkITJqcHWRaf+oImysu/GJqt8qefZP0LY9yxqlWYm09dxJ MI4T18QzSoVD3pIuM76YiVgYtygo/HtFSVI7rCf/Gy4bi4119A== X-Google-Smtp-Source: ABdhPJwG8dtN49AtlXA8/hLUidacEEVF/dyFO0muHmhI9XjX7T99KwhSXtomU9Ac1xmT0Ei8WgBt8i0hnnETeY7a0hY= X-Received: by 2002:a50:f396:: with SMTP id g22mr21903451edm.220.1597784508216; Tue, 18 Aug 2020 14:01:48 -0700 (PDT) MIME-Version: 1.0 References: <20200818205725.2e03c8cb@x23> In-Reply-To: <20200818205725.2e03c8cb@x23> From: Ryan Stone Date: Tue, 18 Aug 2020 17:01:37 -0400 Message-ID: Subject: Re: Is anybody using ng_pipe? To: Marko Zec Cc: freebsd-net Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4BWNdB4rx2z4fSv X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=TXFiQLuY; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rysto32@gmail.com designates 2a00:1450:4864:20::534 as permitted sender) smtp.mailfrom=rysto32@gmail.com X-Spamd-Result: default: False [-0.09 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::534:from]; NEURAL_HAM_SHORT(-0.09)[-0.089]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MAILMAN_DEST(0.00)[freebsd-net]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] 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 21:01:52 -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: (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%. 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. 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).