Re: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt]

[Brian E Carpenter <brc@zurich.ibm.com>]

Iljitsch,

From the product people I talk to, if we break offload (including the
more sophisticated forms of offload such as RDDP) the solution won't be
going anywhere. I think that is related to the point we discussed a
couple of weeks ago about virtualized end points - a model that only
works with a traditional software stack in a traditional single host
simply doesn't work in today's world of virtualized server farms
with load balancers and offload devices.

   Brian

Iljitsch van Beijnum wrote:
> 
> On 18-dec-03, at 21:12, Eliot Lear wrote:
> 
> > (hopefully) the document contains some questions that can be used to
> > evaluate such minor issues as deployability, security, performance,
> > and generality.
> 
> :-)
> 
> I found another one: TCP and UDP checksum calculation offloading. It
> seems this is pretty common these days: I have a box with a turn of the
> century NIC and FreeBSD tells me it is offloading both rx and tx
> checksums. (It works too: dire tcpdump warnings when running verbose
> enough as outgoing packets have invalid checksums as seen by BPF.)
> 
> With any multihoming solution that allows rewriting of addresses
> between the moment the checksum calculation is done and the moment the
> packet is transmitted/received, checksum offloading will pretty much
> have to be a thing of the past, unless we want to start doing some
> complex incremental updating in different places.
> 
> So which is preferable? Keep it simple but lose hardware support for
> checksumming, or keep hardware support but add more complexity?
> 
> Note that the processing for the TCP/UDP checksum is simple enough that
> it's probably free when doing a memcopy anyway.