On 'wan' I see:
18:33:48.124956 IP (tos 0x2,ECT(0), ttl 59, id 22365, offset 0, flags [DF], proto TCP (6), length 789)
server-54-182-171-100.lhr61.r.cloudfront.net.80 > LGwebOSTV.lan.58590: Flags [P.], cksum 0xa847 (incorrect -> 0x4c14), seq 383244:383981, ack 1, win 1702, options [nop,nop,TS val 4254665186 ecr 2188886], length 737: HTTP
...
18:42:31.553362 IP (tos 0x2a,ECT(0), ttl 58, id 14616, offset 0, flags [DF], proto TCP (6), length 1360)
server-54-182-171-105.lhr61.r.cloudfront.net.80 > LGwebOSTV.lan.60942: Flags [.], cksum 0x276d (correct), seq 15697:17005, ack 376, win 2104, options [nop,nop,TS val 4255188707 ecr 2241238], length 1308: HTTP
These ECN bits are certainly getting scrubbed at 'ifb-wan' given my scrubbing code, but this seems to be wreaking havoc in terms of permitting transfer of this video stream.
Any clue why?
Is the answer that scrubbing ECN bits on download breaks the TCP handshake or something? But it's OK on upload?
I'm now no longer sure about this whole idea about scrubbing ECN bits before cake sees the packets. Can we say conclusively whether this will or will not break stuff?
Depending on your answer I'm thinking I should perhaps remove the experimental scrub ECN functionality from cake-qos-simple.