Subject: Re: [iccrg] [gaia] Poor performance of Windows TCP Compound in high delay networks

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 12 Feb 2015 10:38:21 +0000

CC'ing the ICCRG, which may have insights here. Reply-to set to keep the discussion on the GAIA list.

On 2015-2-12, at 10:12, David Johnson <[email-masked]> wrote:
> 
> Has anybody come across the problem of the poor performance of Windows
> using TCP compound vs the better performance of TCP Cubic used by
> Linux / BSD / Apple Mac in networks with high delay - such as those
> connecting over satellites or using multi-hop networks.
> 
> I came across this issue when I was analysing the performance of rural
> networks connecting over satellite links with round trip delays over
> 500 ms. I found that outgoing throughput was three times better in
> Linux Compared to Linux when analyzing the tcpdump traces. If I
> simulated two parallel Linux and Window TCP flows with a 1s round trip
> delay, Linux was 8x faster on the uplink than Windows.
> 
> The effect was most obvious when the local community was using Skype.
> Windows users found that Skype just didn't work whereas Linux users
> were having no problem with Skype. The solution is to use a split TCP
> or TCP proxy at the gateway and I see this has been discussed in 5.2
> of the IETF document but there is no mention of the major difference
> between the TCPs used in Windows and Linux. I think this is quite an
> important issue and I would be happy to work with the author of that
> section to add this analysis. I have published these results in my PhD
> but not at a conference yet - I think I should try and aim to get this
> presented at the next ACMDEV possibly.
> 
> Interestingly one of the students that worked with me at UCSB while I
> was uncovering this problem now works for Microsoft in their
> networking section and says that he will be working to fix this -
> perhaps there will be a release of Windows 10 for  regions with poor /
> high-delay connectivity.
> 
> Regards
> David
> 
> _______________________________________________
> gaia mailing list
> [email-masked]
> https://irtf.org/mailman/listinfo/gaia

---

From: Michael Welzl <[email-masked]>
Date: Thu, 12 Feb 2015 12:33:26 +0100

Thanks Lars!

About the actual problem described:
Well, Cubic being more aggressive than Compound doesn’t surprise me much. However, this:

>> If I

seems to contradict that:

>> were having no problem with Skype.

The more aggressive protocol should be more likely to push Skype aside, not the other way round?!

Sounds like you should test this in a local testbed with artificial influence on capacity and delay to be able to zoom in and see what’s going on…

Cheers,
Michael

---

From: Stefan Hirschmann <[email-masked]>
Date: Thu, 12 Feb 2015 15:54:01 +0100

>>> were having no problem with Skype.
Hm. Skype for windows has the version 7.1.0.105
Skype for Linux has the version 4.3.0.37

The current Skype for windows version does not use any P2P technology
any more (to improve the quality of surveilance). But I don't know if
there is still pieces of P2P code in the Linux code.

> The more aggressive protocol should be more likely to push Skype aside, not the other way round?!
That confuses me a lot. "Local community" sounds like more clients than
server and TCP congestion control is decided by the sender. So I am not
sure if the PC running Skype have enough upload to really influence the
network. It is more likely that the connection behavior is due to the
differences in the Skype versions than it is due to different congestion
control of the Skype running computer.

Cheers, Stefan

---

From: Luca De Cicco <[email-masked]>
Date: Thu, 12 Feb 2015 15:56:26 +0100

Hi all,

another fact to be considered is that Skype tries to use UDP when possible
and falls back on TCP when UDP is blocked.

Best,
Luca
On Thu, Feb 12, 2015 at 3:54 PM, Stefan Hirschmann <[email-masked]> wrote:

> iccrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/iccrg
>

---

From: David Ros <[email-masked]>
Date: Thu, 12 Feb 2015 16:00:03 +0100

Forwarding to the gaia ML.

David

---

From: "wang guodong" <[email-masked]>
Date: Fri, 13 Feb 2015 02:13:54 +0800 (GMT+08:00)

Hi David

Glad to hear researchers are doing performance optimization in Windows. TCP congestion control researches have been conducted for many years and there are great performance improvement in Linux. However, Windows users do not get many benefits from these researches. One of the problems is that Windows is not open sourced, so we can not easily change the TCP variants. Besides increasing the buffer size, is there any other methods to optimize the performance of TCP in Windows? If someone can conclude the methods, it will be beneficial to other researchers as well as Windows users.

Thanks

Guodong wang

> -----原始邮件-----
> 发件人:"David Ros" <[email-masked]>
> 发送时间:2015年2月12日 星期四
> 收件人:[email-masked]
> 抄送:"[email-masked]" <[email-masked]>, "Luca De Cicco" <[email-masked]>, "Stefan Hirschmann" <[email-masked]>
> 主题:Re: [iccrg] [gaia] Poor performance of Windows TCP Compound in high delay networks
> 
> 
> > On Thu, Feb 12, 2015 at 3:54 PM, Stefan Hirschmann <[email-masked]>wrote:
> > 
> > >

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 12 Feb 2015 21:08:44 +0100

Hi,

I would also assume that this effect is rather due to Skype than congestion control.

However, TCP Cubic is more aggressive than Compound. If you run one Cubic flow 
against one Compound flow, the Cubic flow will get a larger share of the capacity.

If you only have Cubic or Compound flows and see different performance that 
might depends on the buffer configuration. If you have one BDP of buffering both 
algos should provide 100% utilization. However, on high delay link one BDP of 
buffering might be quite large, so I can imaging that you'll find less. In this 
case Cubic can provide 100% utilization at least until a buffer size of half a 
BDP (because of a decrease factor of 0.3 instead of halving). While Cubic avoids 
underutilization in this scenario in the first place, Compound has to first 
detect the underutilization and will then try to increase the sending rate more 
and more. Moreover, Compound relies on delay measurements to figure out how 
quickly it can increase. That might also influence the performance. Actually 
I've never done any performance evaluation on Compound, so I can't really tell 
you how big the difference is.

As a side comment: fast is not always better because you have to share the link 
with others and if you get more capacity others might get less. In the case 
where skype is working in one case and not working in the other of course that 
does not seems to be an capacity sharing issue. But as I said I also don't think 
that this a congestion control issue as Skype is doing a lot of smart things.

Mirja

On 12.02.2015 16:00, David Ros wrote:
> On 12 Feb 2015, at 15:56, Luca De Cicco <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> Hi all,
>>
>> On Thu, Feb 12, 2015 at 3:54 PM, Stefan Hirschmann <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>>     [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

-- 
------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland

Room ETZ G93
phone: +41 44 63 26932
email: [email-masked]
------------------------------------------