[e2e] TCP offload (was part of Protocols breaking the end-to-end argument)

[David P. Reed]

Because I sense this thread might be interesting, and should be 
separated from the trolling going on in the original thread, I changed 
the title.

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).