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

[William Allen Simpson]

rick jones wrote:
> 
> On Oct 24, 2009, at 7:34 AM, David P. Reed wrote:
> 
>> 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.
>>
> 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.
> 
TCP Checksum Offload (shouldn't that be TCO or CSO?) has been done for
years.  I've always been a bit leery of it, as my many experiences with
bus problems indicates that the checksum should be calculated as close to
the CPU as possible....

TCP Segment Offload (TSO) -- large TCP segments are broken into smaller
ones -- wouldn't be a problem where the stack always feeds the chip
properly-sized PMTU segments.  For routing a LAN jumbogram into a WAN,
that's broken!  The drivers had better be smart enough to honor "Don't
Fragment" (DF), even though that technically only applies to IP.  Best to
turn it off for all routed packets.  Does your implementation?

TCP Large Receive Offload (LRO) -- small TCP segments are combined into
larger ones -- is an unmitigated disaster.  The sender has no ability to
turn it off, and no idea that it's happening.  Assuming it leaves
SYN-bearing segments untouched, I'd still think that breaks almost every
existing Ack-bearing TCP option.

In either of the latter cases, I don't see how PAWS Timestamps or the MD5
Authentication Option would ever work.