[Cake] GSO super-packets, classification (tin) & DSCP washing

[Kevin Darbyshire-Bryant]

On 22/11/15 14:37, Jonathan Morton wrote:
>> On 22 Nov, 2015, at 15:31, Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> wrote:
>>
>> First off, DSCP washing as implemented, only washes the GSO packet..I'm
>> assuming effectively the first contained packet only.  This is unfortunate.
> You seem to misunderstand how GSO works.
There's no 'seem' about it :-)  But I do much better now.  Thank you. 
Again!

So my not problem vanishes and your 'problem' persists.

>
> A GSO aggregate is, by definition, a single packet formed from the contents of several consecutive inbound packets with identical IP headers and “compatible" transport headers, stored and handled with a *single* copy of the IP and transport header, in such a way that a sequence of outbound packets with identical semantics (but not necessarily identical sizes) can be reassembled from them.
>
> Because there is only one IP header, altering that header implicitly alters the headers of the reassembled packets in the same way.  This applies both to DSCP washing and ECN marking.
>
> The more vexing potential problem is where Cake drops a GSO aggregate, resulting in several MTUs at once being dropped.  It was suggested that this might lead to a more aggressive than necessary congestion response from TCP.  However, I’m not convinced that this is really a problem in practice, since a sequence of consecutive drops doesn’t produce any more DupACKs than a single drop, and SACK will immediately and correctly identify which packets to retransmit.  Certainly this won’t be any worse than the typical burst-loss from overflowing a dumb FIFO, so I’d like to see a demonstration before trying to do anything about it.
>
>  - Jonathan Morton
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4816 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20151122/70dee2e5/attachment-0002.bin>