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

[rick jones]

On Oct 24, 2009, at 7:34 AM, David P. Reed wrote:

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

I don't interact much with "big TOE" functionality (full stateful  
protocol offload - TCP Offload Engine) but the "little toe" stateless  
stuff - ChecKsum Offload (CKO), TSO, LRO.  I have yet to encounter a  
card/chip/NIC where those little toes cannot be cut-off (to spite what  
I'm not sure :)  LRO (distict from GRO perhaps) may be one where it is  
either on or off.  CKO and TSO are ones where they can be on, off, or  
on and ignored by the stack.

rick jones
Wisdom teeth are impacted, people are affected by the effects of events