On Jul 24, 2009, at 1:30 PM, Peter Gutmann wrote:

[I realise this isn't crypto, but it's arguably security-relevant and arguably
interesting :-)].

As long as we think this is interesting, (although I respectfully disagree that there are any inherent security problems with TOE. Maybe there are insecure implementation...).

James Hughes <hugh...@mac.com> writes:

TOEs that are implemented in a slow processor in a NIC card have been shown many times to be ineffective compared to keeping TCP in the fastest CPU
(where it is now).

The problem with statements like this is that they smack of the Linux
religious zealotry against TCP offload support in the kernel, "TOE's are bad because we say they are, and we'll keep asserting this until you go away".

There were a dozen or so protocol offload research projects that the US government funded in the 90s. All failed. Is the people who say "TOE's are bad" because of zealotry or standing on the shoulders of the people that ran those projects. At Network Systems, we partnered with HT Kung of CMU at the time to move TCP out of a really slow Decstation. Result? A accelerator that cost as much as the workstation that was faster until the next processor version was available. Yes, we could have reduced it to a chip but it wasn't. The take away was that improving the software is the gift that keeps on giving. Moore's law means you get a faster TCP every time the clock ticks.
        http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.1138

BTW, I am not a Linux bigot, just someone that got caught up in this issue more than a decade ago. I do not agree with your assertion or the Wikipedia page that this is linux bigotry. I find that page horribly inaccurate and self serving to the TOE manufacturing community.

What I learned from participating in a project that spent $5M of tax payer money was that "The protocol itself is a small fraction of the problem".

A
decade ago, during the Win2K development, Microsoft were measuring a 1/3 reduction in CPU usage just from TCP checksum offload. Given the time frame this was probably on 300MHz PII's, but then again it'd be with late-90s vintage NICs. On the other hand I've seen even more impressive figures with their more recent TCP chimney offload (which just moves more of the NDIS stack
onto the NIC, I think it came out around Server 2003).

Does this mean that MS have figured out (a decade or so ago) how to make TOE work while the OSS community has been too occupied telling everyone it doesn't to do anything about it? There must be some reason for the difference between
the two camps.

Offloading features like checksumming, fragmentation/reassembly (aka Large Segment Offload), packet categorization, slitting flows to different threads, etc. is not TOE.

TOE is offloading of the TCP stack. The thin line that is crossed is "where is the TCP state kept". If the state is kept in the card, then the protocol to get the data reliably to the application is has more corner cases (hence complexity) since the IP layer can be lossy and the socket layer can not. In all the research, this has always been the case.

If there is something windows has not learned could be that processing TCP should be simple and quick. Since the source code is not available, I don't know if their software falls into the "too complicated" camp or not... In the case of Chimney partial stack offload, the state is in both places. Sounds simple straight forward, right?

The case of iSCSI where a complete protocol conversion is done (the card looks like a SCSI card, but the data goes out over TCP/IP) it is a different story (which is also arguably still about solving the OS vendor's lack of software agility with hardware), but that is not the intent of this discussion.

I fully agree that offloading features that makes the TCP processing easier is a good thing.

Back to crypto?

Peter.

Jim

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to