[Cake] [Codel] Proposing COBALT
rick.jones2 at hpe.com
Fri May 20 13:01:19 EDT 2016
On 05/20/2016 09:35 AM, Jonathan Morton wrote:
>> On 20 May, 2016, at 19:20, Rick Jones <rick.jones2 at hpe.com> 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
More information about the Cake