From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g4t3425.houston.hpe.com (g4t3425.houston.hpe.com [15.241.140.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8B2C33B260; Fri, 20 May 2016 13:01:21 -0400 (EDT) Received: from g4t3433.houston.hpecorp.net (g4t3433.houston.hpecorp.net [16.208.49.245]) by g4t3425.houston.hpe.com (Postfix) with ESMTP id B62665F; Fri, 20 May 2016 17:01:20 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g4t3433.houston.hpecorp.net (Postfix) with ESMTP id 3E57D5D; Fri, 20 May 2016 17:01:20 +0000 (UTC) To: Jonathan Morton References: <22371476-B45C-4E81-93C0-D39A67639EA0@gmx.de> <991C8B50-192E-431A-819F-F1C5954FF64F@gmx.de> <4C5D0005-2CAA-4C90-BF0D-7177874872AC@gmail.com> <573F394B.5060009@hpe.com> <26FFB878-5E6B-47B8-8DFD-A8765421655F@gmail.com> Cc: David Lang , cake@lists.bufferbloat.net, codel@lists.bufferbloat.net From: Rick Jones Message-ID: <573F42DF.9010108@hpe.com> Date: Fri, 20 May 2016 10:01:19 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <26FFB878-5E6B-47B8-8DFD-A8765421655F@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 20 May 2016 13:38:14 -0400 Subject: Re: [Cake] [Codel] Proposing COBALT X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 17:01:21 -0000 On 05/20/2016 09:35 AM, Jonathan Morton wrote: >> On 20 May, 2016, at 19:20, Rick Jones wrote: >> I suppose if said software were to dive below the socket interface >> it could find-out, though that will tend to lack portability. > > I’m a little fuzzy on UDP socket semantics. > > Could the sender set DF on a small proportion of the packets, and > listen for ICMP errors to the effect? These packets could also be > salted with distinguishable data so that the receiver can tell > whether the DF packets, in particular, got through. > The Linux manapge for UDP asserts: > By default, Linux UDP does path MTU (Maximum Transmission Unit) discov‐ > ery. This means the kernel will keep track of the MTU to a specific > target IP address and return EMSGSIZE when a UDP packet write exceeds > it. When this happens, the application should decrease the packet > size. Path MTU discovery can be also turned off using the IP_MTU_DIS‐ > COVER socket option or the /proc/sys/net/ipv4/ip_no_pmtu_disc file; see > ip(7) for details. When turned off, UDP will fragment outgoing UDP > packets that exceed the interface MTU. However, disabling it is not > recommended for performance and reliability reasons. But I haven't seen that EMSGSIZE happen with netperf UDP tests - could be though I've never run them in an environment which triggered PTMUD. I don't have visibility into the assertions for *BSD and other Unices. I'm thinking that modulo not knowing with certainty it was the only thing sending and/or receiving traffic, sampling IP stats about fragments before the test and again after would be a more straightforward way to check instead of complicating the benchmark's data path. happy benchmarking, rick jones