There is a key to try some kind of better understanding on tunnel latency problem we are discussing about in this thread. And I found it.
Suppose a network composed by 3 wireless hops and 1 bridge @ 1st hp and 1 router @ 2nd hop (RouterA-AP->CPE-bridge-AP->CPE-router-AP->CPE-RouterB).
You ping RouterB from RouterA directly or inside an Eoip tunnel between A and B.
If you ping with less than 1500 bytes packet size, you notice some big difference between inside and outside Eoip (avg 4ms out, avg 40ms in).
if you ping with 1510 bytes packet size (something little more than 1500), you can see very similar latency inside and outside Eoip tunnel (avg 50-60ms).
if you ping with 10000 bytes backet size (something big), you can see even better result inside Eoip (90-100ms) than outside it (110-120ms).
So, the problem, according to me, is that if you use ICMP and wireless gear can see it is ICMP simple traffic (less than 1500 bytes size), they doesn't make anything; they only forward packets without lose time in making decisions.
If you ping inside tunnel (and so wireless device see it as normal tcp traffic, not icmp), or if you send packets so big to require ethernet fragmentation (with headers to indicate fragments), it seems that wireless devices lose time checking packets and making some kind of decision before forwarding it.
And this time lost is for every kind of traffic different form simple ICMP little unfragmented packets!
I think this is the behavior of every kind of tunnel, included VPLS. Every time packets are something different from simple little ICMPs, wireless multiple hops create high latency.
SL1 Systems srl MTCNA MTCRE