[e2e] TCP offload (was part of Protocols breaking the end-to-end argument)
David P. Reed
dpreed at reed.com
Sat Oct 24 07:34:14 PDT 2009
Because I sense this thread might be interesting, and should be
separated from the trolling going on in the original thread, I changed
TCP offload is interesting. We actually addressed this kind of thing is
the "Active Networks" vs. end-to-end paper. Function placement at the
architectural level actually can be discussed with regard to "design
time" and "implementation time" versions of the arguments. For example,
if I am an "end host" but I do some of my functions on "attached support
processors" (excuse the "I" as metaphor for the main OS and CPU), that
may be quite clean architecturally - IF the communication between me and
the attached support processor is one that makes it act as part of
"me". So one could consider it part of the "end", even if it is in a
middlebox: the distinction is that it is under my sole control (so it
acts as a fully controlled module).
The end-to-end argument in the paper says that such acceleration can be
in the network, if indeed it merely accelerates a function that is in
all endpoints. However, the argument asks that we consider whether the
improvement overall is really worth it.
I leave it to the community of architects (not the chip designers, who
have a bias to believe that every "feature" is a differentiating
advantage) to decide whether the benefit of this particular thing is
really worth the potential inflexibility it creates - in particular the
risk that the chip will do the wrong thing on the forwarding path, and
the risk that the TCP spec will change in a way that makes the chip's
popularity a barrier to innovation.
It sounds as if there is a chance that, due to how one of the TOS chips
works, the portion of TCP that it implements is not strictly an "agent"
of the host TCP stack running on the host processor, but instead based
on "pattern recognition" that cannot be turned off. (I haven't read the
spec, so maybe it is more subtle than that).
That would result in a serious bug - if the chip is used by a low-level
forwarding path, perhaps an ethernet bridge or an IP routing layer, the
"optimization" would by accident be applied to TCP segments having
nothing to do with the host. This clearly makes using such chips in
general boxes like Linux boxes, that can perform ethernet bridging, IP
forwarding, etc. QUITE problematic! So perhaps they need to be marked
as *inappropriate* for general use. But that is because they really are
buggy for that use. (again, I haven't read the spec).
More information about the end2end-interest