Re: [Codel] [Cake] Proposing COBALT

[Kathleen Nichols <nichols@pollere.com>]

On 5/20/16 7:04 AM, David Lang wrote:
>
> How big a problem is this in the real world? ARe we working on a
> theoretical problem, or something that is actually hurting people?
>

The above seems like it should be the FIRST thing to consider.

The entire thread:
> On Fri, 20 May 2016, moeller0 wrote:
> 
>>> On May 20, 2016, at 15:41 , David Lang <david@lang.hm> wrote:
>>>
>>> On Fri, 20 May 2016, Jonathan Morton wrote:
>>>
>>>> Normal traffic does not include large numbers of fragmented packets
>>>> (I would expect a mere handful from certain one-shot
>>>> request-response protocols which can produce large responses), so it
>>>> is better to shunt them to a single queue per host-pair.
>>>
>>> I don't agree with this.
>>>
>>> Normal traffic on a well setup network should not include large
>>> numbers of fragmented packets. But I have seen too many networks that
>>> fragment almost everything as a result of there being a hop that goes
>>> through one or more tunneling layers that lower the effective MTU
>>> (and no, path mtu discovery does not always work)
>>
>>     True, do you have a cheaper idea of getting the flow identity
>> cheaply from fragmented packets, short of ressembly ;) ?
> 
> How big a problem is this in the real world? ARe we working on a
> theoretical problem, or something that is actually hurting people?
> 
> by default (and it's a fairly hard default to disable in OpenWRT), the
> kernel is doing connection tracking so that NAT (masq) and stateful
> firewalling can work. That process has to solve this problem. The days
> of allowing fragments through the firewall ended over a decade ago, and
> if you don't NAT the fragments correctly, things break.
> 
> So, assuming that we can do as well as conntrack (or ideally use the
> work that it's already doing), then the only case where this starts to
> matter is in places that have a custom kernel with conntrack disabled
> and are still seeing enough fragments to matter.
> 
> I strongly suspect that in the real world, grouping those fragments by
> source/dest IP will spread them into enough buckets to keep them from
> hurting any other systems, while still keeping them concentrated enough
> to keep fragmentation from being a backdoor around limits.
> 
> Remember, perfect is the enemy of good enough. A broken network that is
> fragmenting a lot of traffic is going to have other problems (especially
> if it's the typical "fragment due to tunnel overhead" where you have a
> full packate and minimum size packet pair that you fragment into). Our
> main goal needs to be to keep such systems from hurting others. Keeping
> it from hurting other traffic on the same broken host is a secondary goal.
> 
> Is it possible to get speed testing software to detect that it's
> receiving fragments and warn about that?
> 
> David Lang
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel