Re: [Int-area] IP parcels

Ease up, Joe - just ease up.

> -----Original Message-----
> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of touch@strayalpha.com
> Sent: Thursday, January 27, 2022 3:44 PM
> To: Tom Herbert <tom@herbertland.com>
> Cc: int-area@ietf.org
> Subject: [EXTERNAL] Re: [Int-area] IP parcels
> 
> EXT email: be mindful of links/attachments.
> 
> 
> 
> Hi, Tom,
> 
> > On Jan 27, 2022, at 2:46 PM, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Thu, Jan 27, 2022 at 2:17 PM touch@strayalpha.com
> > <touch@strayalpha.com> 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
> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area