Re: [Int-area] IP parcels

["[e-mail]" <[e-mail]>]

Hi, Tom,

> On Jan 27, 2022, at 2:46 PM, Tom Herbert <[e-mail]> wrote:
> 
> On Thu, Jan 27, 2022 at 2:17 PM [e-mail]
> <[e-mail]> wrote:
>> 
>> FWIW, GRO/GSO give no end of headaches to the idea of new TCP options, esp. the current ones to extend option space after the SYN (draft-ietf-tcpm-tcp-edo).
> 
> GRO and GSO are software implementations and in most deployments

Ubiquitously deployed Linux kernel software at one point had a bug that failed to lock the inode structure during modification. Uniquity didn’t make that magically correct.

>> Although I appreciate their zeal for optimization, implementers of GRO/GSO still need to play by the rules of TCP and UDP. It’s not clear they are (e.g., coalescing packets with different unknown options), and when they don’t, I want to be clear that it is they that are the problem.
>> 
> Joe,
> 
> GRO and GSO are software implementations in kernel networking stacks
> and in most cases these are open source projects of Linux or FreeBSD.
> If they have flaws or there's areas for improvement, then by all means
> submit patches to the respective project-- that, after all, is the
> whole premise of an open source project.

That’s not how open source works. 

The onus is on those who currently maintain the code to ensure it complies with current protocols. I noted that I and others have experience that it doesn’t.

It is not the responsibility of the user community to fix their bugs or ensure that their approach remains viable.

> The hardware cognates, TSO
> and LRO, do tend to be more closed and for this reason they haven't
> gotten much traction-- TSO has seen a some amount of deployment, but
> LRO hasn't because of the problems of putting fairly complex
> algorithms in hardware. That problem is addressed once we have
> sufficiently programmable hardware so the stack can program things
> like GSO and GRO in hardware as easily in hardware and of course this
> should be done in ubiquitous open source that works across all
> hardware vendors.

None of that has anything to do with the issue I raised.

Both hardware and software implementations of these optimizations MUST strictly comply with protocol specs. When they encounter options they don’t know, it’s not their prerogative to do anything beyond “disable” for that stream. That’s not our experience, though.

Joe