[176881] in North American Network Operators' Group
Re: Cisco AnyConnect speed woes!
daemon@ATHENA.MIT.EDU (James Michael Keller)
Mon Dec 15 21:02:12 2014
X-Original-To: nanog@nanog.org
Date: Mon, 15 Dec 2014 21:01:56 -0500
From: James Michael Keller <jmkeller@houseofzen.org>
To: Roy Hirst <rhirst@xkl.com>, nanog@nanog.org
In-Reply-To: <548A0A0B.4040300@xkl.com>
Errors-To: nanog-bounces@nanog.org
On 12/11/2014 04:18 PM, Roy Hirst wrote:
> Confidently based on no knowledge at all -
>
> *Roy Hirst* | 425-556-5773 | 425-324-0941 cell
> XKL LLC | 12020 113th Ave NE, Suite 100 | Kirkland, WA 98034 | USA
>
>
>>> - We have noticed that in some instances that if a user is on a low
>>> speed connection that their VPN speed gets cut by about 1/3.
>>> This doesn't
>>> seem normal that the VPN would use this much overhead
> No, sure, but are you sure that congestion is not dropping a packet
> somewhere in the end-to-end? If you offend TCP it will likely cut the
> sender's packet transmit rate, even if the "possible" VPN rate is much
> higher.
>>> - We do not have the issue when connecting to VPN directly on
>>> our own
>>> network, only connections from the Internet
> Internet would mean maybe a proxy or firewall then, with too-small
> buffers or an old-time TCP/IP stack? Just a thought.
>>>
>>> If you have any ideas on what we could try net, please let me know!
>>>
>>> - Zachary
>>
>> What OS builds? At one point the code had an 8 packet hard coded
>> window per tcp flow, which capped ssl over tcp window size to about
>> 5mbps depending on RTT. Recent 8 branches raised this to
>> something more reasonable that capped around 20 mbps. DTLS over udp
>> and IPSEC tunnels did not have this issue.
> UDP traffic does not have this problem but TCP does? Hmmm...
>>
UDP transport with DTLS or IPSEC in UDP Encapsulation doesn't need to
deal with tcp window size scaling and the associated packet buffers.
-James
