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
