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

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

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]

Hiya,

Whilst I was mixing some football (soccer for those across the pond)
last night, a naughty question popped into my head related to GSO
packets.  From what I understand a GSO packet is actually a collection
of packets, in essence passed to the NIC (or through the stack) as a
'lump' of data which is then pulled apart as late in the process as
possible.  This led to the following questions.

First off, DSCP washing as implemented, only washes the GSO packet..I'm
assuming effectively the first contained packet only.  This is unfortunate.

That question led to the implied observation that 'tin classification'
based on DSCP is also decided upon by the GSO packet and not the packets
contained therein.  Even if cake decides to peel the GSO because it will
affect flow isolation, it still doesn't individually classify each
packet and potentially puts some of them in the wrong queue.  I
appreciate this has some unfortunate CPU usage implications.

I also pondered if there's a small cpu advantage to wash on de-queue
rather than enqueue, especially if the wash procedure is enhanced to
traverse a GSO aggregate.







[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

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

[Jonathan Morton]

> On 22 Nov, 2015, at 15:31, Kevin Darbyshire-Bryant <kevin@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.

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

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

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 1750 bytes --]

On 22/11/15 14:37, Jonathan Morton wrote:
>> On 22 Nov, 2015, at 15:31, Kevin Darbyshire-Bryant <kevin@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
>



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]