Re: [Cake] Proposing COBALT

[David Lang <david@lang.hm>]

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