tunnel upstream is unusably slow

[David Woodhouse]

On Thu, 2014-04-03 at 10:10 +0200, Ortwin Glück wrote:
> 
> 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 :-)

OK, thanks. Time to resort to bisecting then, I suppose. But let's blame
Eric preemptively anyway... and perhaps manually start your bisection
right at commit f54b31114 :)

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

Eric, any ideas on that one? This one is on the public-side network
between VPN client and server. (The other misbehaviour discussed above
with the 200ms delays was on traffic *inside* the VPN, going out through
the tun0 device. Which gets turned into these packets which are
misbehaving differently.)

Ortwin: is TSO definitely still enabled in 3.14? What NIC?

-- 
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/20140403/78e240ee/attachment-0001.bin>