Q:

Memcached and lots of tcpip resets (as shown by netstat AND tcpdump) - Any ideas? 

We use pecl's memcached (note the D, there are 2, memcache AND memcached) extension to connect to a cluster of memcached 1.4.13 boxes. 
We have noticed a LARGE number of tcpip resets occuring:
[root@box ~]# netstat -s | grep unexpected
2078913548 connections reset due to unexpected data

[root@box ~]# tcpdump -n -v 'tcp[tcpflags] & (tcp-rst) ! = 0' -nn
13:30:45.786577 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
LANSUBNET.1.19093 > LANSUBNET.4.999: Flags [R], cksum 0xfad9 (correct), seq 1996582451, win 0, length 0
13:30:45.786697 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
LANSUBNET.1.11540 > LANSUBNET.100.999: Flags [R], cksum 0x904c (correct), seq 2003170685, win 0, length 0
13:30:45.793199 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
LANSUBNET.1.55125 > LANSUBNET.3.999: Flags [R], cksum 0x42c3 (correct), seq 1998297456, win 0, length 0
13:30:45.793389 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
LANSUBNET.1.19112 > LANSUBNET.4.999: Flags [R], cksum 0xa2b5 (correct), seq 1993131641, win 0, length 0
13:30:45.793547 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
LANSUBNET.1.11564 > LANSUBNET.100.999: Flags [R], cksum 0x447c (correct), seq 2003255604, win 0, length 0
13:30:45.817874 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
LANSUBNET.1.55135 > LANSUBNET.3.999: Flags [R], cksum 0x841c (correct), seq 1995200572, win 0, length 0
13:30:45.818549 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
LANSUBNET.1.55141 > LANSUBNET.3.999: Flags [R], cksum 0x385d (correct), seq 1997841357, win 0, length 0

Memcached is bound on port 999 on all of our memcached boxes. 
Are we diagnosing this incorrectly? 
What could be causing this? 
What we know for sure:
A) This is not related to the mecached pecl extension (note the d, there are 2 extensions... memcache AND memcached).  We tried switching to the other, memcache extension and same issue occured. 
B) This is in fact 100% caused by the memcache connections.  We disabled our php -> memcached sessions, and the connections reset due to unexpected data in netstat stoped growing, instantly. 
C) We have this issue occuring on 2 boxes, so I dont think its a server-specific issue.  When I say 2 boxes, I mean 2 different servers, making OUTBOUND connections to our memcached cluster.  They both sit on the same LAN. 
Note: For security we changed our LAN subnet above to 'LANSUBNET'... This was done just prior to posting the message here ;)
Any help would be appreciated! 
Thanks. 

More Data:
[root@box ~]# netstat -s | grep unexpected ; sleep 1 ; netstat -s | grep unexpected ;
2089258664 connections reset due to unexpected data
2089258858 connections reset due to unexpected data

So it would appear, durring a 'not so busy' time, the resets occur at about a 200 / sec rate.  Ouch! 
Also, very much worth mentioning:
We have executed the following:
tcpdump -nn -v 'tcp[tcpflags] & (tcp-rst) ! = 0' and tcp port not 999

Thus filtering port 999 (where our memcached daemons sit on)... And the tcp resets slow to a tiny trickle... Few a minute, which I assume is acceptable on a fairly busy service. 

A:

We have found a complete solution to this issue. 
It is caused by the memcached pecl extensions "Memcached::OPT_BUFFER_WRITES" constant being set to true.