Re: [Cake] [Codel] Proposing COBALT

[Rick Jones <rick.jones2@hpe.com>]

On 05/20/2016 09:35 AM, Jonathan Morton wrote:
>> On 20 May, 2016, at 19:20, Rick Jones <rick.jones2@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 
data path.

happy benchmarking,

rick jones