tunnel upstream is unusably slow

[Ortwin Glück]

On 02.04.2014 18:17, David Woodhouse wrote:
> 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. That was my first idea too :-)

> 
>>
>>>> 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?

Yes they would be split into one larger and a smaller chunk.

> Does that misbehaviour *also* persist with 3.13?

In 3.13 that looks entirely different. Here I get nice huge frames
(chopped up by the NIC with segmentation offload)

18:31:10.798668 IP SSL-local.40251 > SSL-remote.https: Flags [.], seq
2471220:2475508, ack 84847, win 65535, length 4288


> 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.

OK, nice!