tunnel upstream is unusably slow

[David Woodhouse]

On Wed, 2014-04-02 at 17:58 +0200, Ortwin Glück wrote:
> I have just noticed that this is a regression in kernel 3.14! Works fine
> in 3.12 and 3.13.
> 
> Sorry to bother you. I will bisect and speak to kernel folks.

Does it go away if you

echo 0 > /proc/sys/net/ipv4/tcp_autocorking


> 
> >> No.     Time     Source                Destination           Protocol    Length Info
> >>    1100 0.214    tun-local             tun-remote            SSHv2    1280   Encrypted request packet len=1228
> >>    1101 0.000    SSL-local             SSL-remote            TLSv1    1126   Application Data
> >>    1102 0.000    SSL-local             SSL-remote            TLSv1    328    Application Data
> > 
> > A packet is 'sent' over the tun interface. OpenConnect immediately sends
> > it. It takes *two* packets to send it, since your MTU inside the tunnel
> > is larger than your MTU outside the tunnel. 
> 
> No matter what value I pass to --mtu I always end up with 2 packets -
> just their sizes change. What do you suggest?

Hm, that's odd. You pass a *much* smaller MTU value and you actually see
smaller packets like 1000 bytes on the tun device? And they're *still*
split into multiple packets on the wire for the public network?

Does that misbehaviour *also* persist with 3.13?

Btw, you mentioned the fact that OpenConnect allocates packets for each
connection and copies data around. That's true only for the SSL
connection; we expect to be using compression there so I don't bother
with the zero-copy on that path. For DTLS the path is a lot more
efficient and *shouldn't* involve data copies. We allocate a buffer in
advance while we're waiting for data to arrive on the tun or dtls
socket, we receive into that buffer and then send from it.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140402/83e238e6/attachment.bin>