[e2e] Protocols breaking the end-to-end argument

[William Allen Simpson]

rick jones wrote:
> Perhaps he is referring to chips which provide TCP/Transport 
> Segmentation Offload - aka TSO - the functionality that allows the stack 
> to hand the chip a chunk of data > the MTU, along with the initial 
> TCP/IP headers and the connection's on the wire MSS, and then have the 
> chip otherwise statelessly segment that larger chunk of data into 
> MSS-sized segments for transmission on the wire/fibre/etc.
> 
It is indeed.  Since the hardware driver is unaware of many things,
such as path MTU, this is one of its serious impediments.

Sure, there are measurements that show several percentage points less
CPU, but in most cases we're not CPU bound.  I'm not sure what problem
it's solving, other than a checkbox to differentiate commodity products.

Worst of all, this stuff is all implemented in unmodifiable,
proprietary firmware.


> If that is the functionality of which he speaks, it is in virtually 
> every contemporary 1GbE card I can think of (but my thoughts cannot span 
> the entirety of the space I suspect).  Also, virtually every 10G NIC out 
> there offers the same functionality.
> 
Gaah!  I only knew about the Broadcom chips, as discussed on the NetBSD
lists a few years back, and didn't know this disease had spread.


> And if that upsets him, we better not tell him about the 10G NICs also 
> doing receive offload... :)
> 
I'd heard of it, but thought that was pretty uniformly rejected.  Heck,
the most basic TCP decision points would be impossible to implement,
revise, or test.


> BTW, I do not believe that any router actually has TSO happen to TCP 
> segments contained within the IP datagrams passing through it - although 

Only recently trying to decipher the Linux stack, but it all appears to
go through the same queue, routed packets included.  If the box receives
a jumbogram on one interface, it can be re-segmented out another, and
I've not found any support for PMTUD or ECN or anything.


> there have been issues in Linux with LRO (Large Receive Offload, 
> distinct from General Receive Offload) when the system was acting as 
> either a router or a bridge - because TSO doesn't happen in that path :)
> 
Again, I'm not as familiar with Linux-only terminology.  A quick Google
turns up "Generic Receive Offload", and that appears to be explicitly
designed to merge segments in routers, and re-segment out the other side:

   http://lwn.net/Articles/311357/

I'm pretty sure this is contrary to the end-to-end [argument, principle,
what-have-you]....  And covered by a passel of patents.