mascolo | 30 Nov 12:10 2011
Picon

Reasons not to deply TCP BIC/Cubic

Dear all,

we know that TCP BIC/Cubic is default in Linux and as a consequence  
50% of servers employs TCP BIC/Cubic.

Our measurements say that there could be reasons not to deploy TCP  
BIC/Cubic. These reasons  are in our opinion rooted in its more  
aggressive probing phase. In particular, in common network conditions,  
TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or  
TCP Westwood+; 2. a larger number of retransmission wrt to TCP NewReno  
or TCP Westwood+; 3 larger throughput but same goodput wrt to TCP  
NewReno or Westwood+.

In other terms, it seems that its more aggressive probing increases  
both throughput and retransmissions but leaving unchanged the goodput.  
This is  neutral for the users but negative for the network.

I appreciate your views.

Thanks for the attention and best regards,

Saverio Mascolo

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Michael Welzl | 30 Nov 12:56 2011
Picon
Picon

Re: Reasons not to deply TCP BIC/Cubic

This should really go to ICCRG, I'd say (added to recipients). May I ask 
to continue this (interesting!) discussion there?

On 11/30/11 12:10 PM, mascolo <at> poliba.it wrote:
> Dear all,
>
> we know that TCP BIC/Cubic is default in Linux and as a consequence 
> 50% of servers employs TCP BIC/Cubic.
>
> Our measurements say that there could be reasons not to deploy TCP 
> BIC/Cubic. These reasons  are in our opinion rooted in its more 
> aggressive probing phase. In particular, in common network conditions, 
> TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or 
> TCP Westwood+; 2. a larger number of retransmission wrt to TCP NewReno 
> or TCP Westwood+; 3 larger throughput but same goodput wrt to TCP 
> NewReno or Westwood+.
>
> In other terms, it seems that its more aggressive probing increases 
> both throughput and retransmissions but leaving unchanged the goodput. 
> This is  neutral for the users but negative for the network.
>
> I appreciate your views.
>
> Thanks for the attention and best regards,
>
> Saverio Mascolo
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
(Continue reading)

Mirja Kuehlewind | 31 Jan 17:22 2012
Picon

Re: [Iccrg] Re: Reasons not to deply TCP BIC/Cubic

Hi everybody,

I know I'm quite late to enter this discussion, but I would like to raise 
another question. I guess there was already a lot explanation on the e2e list 
saying (more or less) that Cubic is more aggressive but it is also able to 
react more quickly on network changes (mainly sudden increases in bandwidth). 

With e.g. TCP Reno the time between two loss events is increasing with the 
network capacity. So it might take a long time to actually detect that there 
is more bandwidth available in a network with large capacity. If we want to 
speed up this probing process we would need more frequent loss events causing 
a higher loss rate...? I guess one solution to this problem would be ECN. 
That means having a high probing rate but no losses. I'm wondering if there 
is any other solutions?

Mirja

On Wednesday 30 November 2011 12:56:46 Michael Welzl wrote:
> This should really go to ICCRG, I'd say (added to recipients). May I ask
> to continue this (interesting!) discussion there?
>
> On 11/30/11 12:10 PM, mascolo <at> poliba.it wrote:
> > Dear all,
> >
> > we know that TCP BIC/Cubic is default in Linux and as a consequence
> > 50% of servers employs TCP BIC/Cubic.
> >
> > Our measurements say that there could be reasons not to deploy TCP
> > BIC/Cubic. These reasons  are in our opinion rooted in its more
> > aggressive probing phase. In particular, in common network conditions,
(Continue reading)

Detlef Bosau | 1 Feb 22:24 2012
Picon

Re: [Iccrg] Re: Reasons not to deply TCP BIC/Cubic

On 01/31/2012 05:22 PM, Mirja Kuehlewind wrote:
> Hi everybody,
>
> I know I'm quite late to enter this discussion, but I would like to raise
> another question. I guess there was already a lot explanation on the e2e list
> saying (more or less) that Cubic is more aggressive but it is also able to
> react more quickly on network changes (mainly sudden increases in bandwidth).

First of all, I would really like to avoid the term "bandwidth" in our 
context.

To make a long story short and come to the point: Bandwidth is given in 
Hertz, throughput is given bin bit per second.
At least in papers, I've read so far, this "sloppiness" has lead to much 
confusion and in some cases to simply wrong results.

We should acknowledge the fact, that there are e.g. wireless networks 
around, where this difference is absolutely crucial.
> With e.g. TCP Reno the time between two loss events is increasing with the
> network capacity. So it might take a long time to actually detect that there
> is more bandwidth available in a network with large capacity. If we want to

It is not a bandwidth, what we detect, but it is network capacity. And a 
tcp flow may share this capacity with others. So, at least one issue is 
the coexistence of different TCP schemes.

> speed up this probing process we would need more frequent loss events causing
> a higher loss rate...? I guess one solution to this problem would be ECN.
> That means having a high probing rate but no losses. I'm wondering if there
> is any other solutions?
(Continue reading)

Daniel Havey | 1 Feb 23:20 2012
Picon

Re: [Iccrg] Re: Reasons not to deply TCP BIC/Cubic

Hehe ;^)  I agree with Detlef.  We have to be more careful with our terminology, and we have to be specific about
the network conditions that we are talking about.

For instance we were talking about delay.  Lachlan said, something to the effect of Cubic causes large
delays.  I don't think it does.

We are both right.  Lachlan sees Cubic's delay as larger than Reno.  Therefore it is large.  I see the delay as
insignificant compared to the 30 second playout buffer that I am working with.

Soooo, I have an issue with the term "quickly".  I see TCP as a control system with a delayed feedback loop.  The
feedback is an ACK or a dupAck.  How quickly a TCP reacts is completely dependent on RTT (how long it takes for
the feedback signal to return to the sender).  If I send a packet and it is lost, I will not know it until the ACK
from the next packet reaches me.  If the packet is received, I should know about it slightly sooner.  This is
how quickly a TCP can react to changes in the network.

I think what Mirja is talking about is the aggressiveness of the response to a feedback signal.  This is
determined by the congestion control algorithm.  Cubic tends to be more aggressive than Reno.

...Daniel
PS...It's a lot of work to define the scenario, and the terminology.  However, once we have done that, we
might actually solve a problem ;^)

--- On Wed, 2/1/12, Detlef Bosau <detlef.bosau <at> web.de> wrote:

> From: Detlef Bosau <detlef.bosau <at> web.de>
> Subject: Re: [e2e] [Iccrg] Re:  Reasons not to deply TCP BIC/Cubic
> To: end2end-interest <at> postel.org
> Date: Wednesday, February 1, 2012, 1:24 PM
> On 01/31/2012 05:22 PM, Mirja
> Kuehlewind wrote:
(Continue reading)

Detlef Bosau | 2 Feb 12:51 2012
Picon

Re: [Iccrg] Re: Reasons not to deply TCP BIC/Cubic

On 02/01/2012 11:20 PM, Daniel Havey wrote:
> Hehe ;^)  I agree with Detlef.  We have to be more careful with our terminology, and we have to be specific
about the network conditions that we are talking about.
>
> For instance we were talking about delay.  Lachlan said, something to the effect of Cubic causes large
delays.  I don't think it does.

Unfortunately, I don't see Lachlan's post yet. However, what shall be 
the reason for the delay? It's hardly a propagation delay on the path, 
neither a serialization delay, which may cause grief here. If ever, the 
problem is likely to be caused by queuing delays. Do you agree here?
> Soooo, I have an issue with the term "quickly".

Actually, the term is precisely determined :-)

>   I see TCP as a control system with a delayed feedback loop.

This is an always interesting analogy - however, at least to me, not a 
very helpful one. (And I well expect criticism by Saverio here. IIRC, 
Saverio did quite a lot of work on analytical models for TCP. However, 
all these analytical discussions which are necessary for doing control 
theoretical considerations, did not yet convince me.)

> The feedback is an ACK or a dupAck.  How quickly a TCP reacts is completely dependent on RTT (how long it takes
for the feedback signal to return to the sender).  If I send a packet and it is lost, I will not know it until the
ACK from the next packet reaches me.  If the packet is received, I should know about it slightly sooner.  This
is how quickly a TCP can react to changes in the network.

Exactly. And if you introduce queuing delay into the network, you will 
slow down the reaction significantly.
(Continue reading)

Lachlan Andrew | 2 Feb 23:45 2012
Picon

Re: [Iccrg] Re: Reasons not to deply TCP BIC/Cubic

Greetings Detlef,

On 2 February 2012 22:51, Detlef Bosau <detlef.bosau <at> web.de> wrote:
> On 02/01/2012 11:20 PM, Daniel Havey wrote:
>>
>> For instance we were talking about delay.  Lachlan said, something to the
>> effect of Cubic causes large delays.  I don't think it does.
>
> Unfortunately, I don't see Lachlan's post yet. However, what shall be the
> reason for the delay? It's hardly a propagation delay on the path, neither a
> serialization delay, which may cause grief here. If ever, the problem is
> likely to be caused by queuing delays. Do you agree here?

That post was ages ago, before Mirja reopened the thread.  Yes, it was
saying that CUBIC induces excessive queueing delays.

>>  I see TCP as a control system with a delayed feedback loop.
>
> This is an always interesting analogy - however, at least to me, not a very
> helpful one.

It isn't an analogy.  Congestion control *is* a control system.  It is
just not a simple one, and all tractable analyses have to model it as
something much simpler than it is.

>> The feedback is an ACK or a dupAck.  How quickly a TCP reacts is
>> completely dependent on RTT (how long it takes for the feedback signal to
>> return to the sender).  If I send a packet and it is lost, I will not know
>> it until the ACK from the next packet reaches me.
>
(Continue reading)

Detlef Bosau | 3 Feb 13:12 2012
Picon

Re: [Iccrg] Re: Reasons not to deply TCP BIC/Cubic

On 02/02/2012 11:45 PM, Lachlan Andrew wrote:
>
> That post was ages ago, before Mirja reopened the thread.  Yes, it was
> saying that CUBIC induces excessive queueing delays.
>

Perfect ;-) So I can ask the author himself: Why?
>>>   I see TCP as a control system with a delayed feedback loop.
>> This is an always interesting analogy - however, at least to me, not a very
>> helpful one.
> It isn't an analogy.  Congestion control *is* a control system.  It is
> just not a simple one, and all tractable analyses have to model it as
> something much simpler than it is.
>

O.k., "not a simple one" is the correct view. Obviously, a simple view 
into the congavoid paper will help us here:

Look at the footnote on page 2:
> A conservative flow means that for any given time, the integral of the 
> packet density around the sender–
> receiver–sender loop is a constant. Since packets have to ‘diffuse’ 
> around this loop, the integral is sufficiently
> continuous to be a Lyapunov function for the system. A constant 
> function trivially meets the conditions for
> Lyapunov stability so the system is stable and any superposition of 
> such systems is stable. (See [3], chap. 11–
> 12 or [21], chap. 9 for excellent introductions to system stability 
> theory.)

(Continue reading)

Dave Hart | 3 Feb 19:24 2012
Picon

Re: [Iccrg] Re: Reasons not to deply TCP BIC/Cubic

On Fri, Feb 3, 2012 at 12:12, Detlef Bosau <detlef.bosau <at> web.de> wrote:
> Do you happen to have a paper on Compound? Up to now, I only know Compound
> als "M$ rocket science" - and hardly anyone knows the details.

Using "M$" to refer to Microsoft says more about you than it does
about Microsoft, and it's not flattering.  Let me google that for you:

http://tools.ietf.org/html/draft-sridharan-tcpm-ctcp-02 (expired)
http://research.microsoft.com/apps/pubs/default.aspx?id=70189

If you can't manage to pierce that nonexistent veil of secrecy, it's
only because of your own bias, not for lack of public information.

Cheers,
Dave Hart

Detlef Bosau | 3 Feb 20:22 2012
Picon

Re: [Iccrg] Re: Reasons not to deply TCP BIC/Cubic

On 02/03/2012 07:24 PM, Dave Hart wrote:
> On Fri, Feb 3, 2012 at 12:12, Detlef Bosau<detlef.bosau <at> web.de>  wrote:
>> Do you happen to have a paper on Compound? Up to now, I only know Compound
>> als "M$ rocket science" - and hardly anyone knows the details.
> Using "M$" to refer to Microsoft says more about you than it does
> about Microsoft, and it's not flattering.  Let me google that for you:

Surely.

> http://tools.ietf.org/html/draft-sridharan-tcpm-ctcp-02 (expired)
> http://research.microsoft.com/apps/pubs/default.aspx?id=70189

Thanks.

> If you can't manage to pierce that nonexistent veil of secrecy, it's
> only because of your own bias, not for lack of public information.

It might be very personal experience. But my professional experience 
with Microsoft (and business environment) during the last two decades 
was "somewhat special" on some occasions. Frankly spoken: My impression 
is that the first interest of Microsoft is commercial success. And 
academic research is, if at all, a means to this end.

May be, this is a very personal experience. However, my personal 
interest is research. To make a living is a necessary evil.

 From my experience, for commercial business, the priority is simply the 
other way round.

Detlef
(Continue reading)

Lachlan Andrew | 4 Feb 03:58 2012
Picon

Re: [Iccrg] Re: Reasons not to deply TCP BIC/Cubic

Greetings Detlef,

On 3 February 2012 23:12, Detlef Bosau <detlef.bosau <at> web.de> wrote:
> On 02/02/2012 11:45 PM, Lachlan Andrew wrote:
>>
>> it was saying that CUBIC induces excessive queueing delays.
>
> Perfect ;-) So I can ask the author himself: Why?

CUBIC induces high queueing delay because it aims to increase the
window rapidly until just before the point when the buffer is full,
then increases slowly so that the window stays at that buffer-filling
size for as long as possible.

> O.k., "not a simple one" is the correct view. Obviously, a simple view into
> the congavoid paper will help us here:
>
> Look at the footnote on page 2:
>>
>> A conservative flow means that for any given time, the integral of the
>> packet density around the sender–
>> receiver–sender loop is a constant. Since packets have to ‘diffuse’ around
>> this loop, the integral is sufficiently
>> continuous to be a Lyapunov function for the system. A constant function
>> trivially meets the conditions for
>> Lyapunov stability so the system is stable and any superposition of such
>> systems is stable. (See [3], chap. 11–
>> 12 or [21], chap. 9 for excellent introductions to system stability
>> theory.)
>
(Continue reading)

Detlef Bosau | 4 Feb 14:35 2012
Picon

Re: [Iccrg] Re: Reasons not to deply TCP BIC/Cubic

On 02/04/2012 03:58 AM, Lachlan Andrew wrote:
>>
>> However, it clearly exhibits, which mathematical effort must be done to
>> apply control theory to our problem. And perhaps, the message of this
>> footnote is nothing else then "with sufficient effort, it can be shown that
>> at least VJCC and the well known control theory do not contradict."
> That passage is justifying using window-based rate control.
Only very short, my fridge is empty ;-)

I just talked to Michael Welzl (bcc:) about this passage some months 
ago. And I think, we shared the view that the remark on Lyapunov 
functions (I cannot even spell this....) are an argument for the 
stability of the control system.

VJCC is a pure window based control. Only window based. Nothing said 
about rates. And I'm extremely careful to make a clear difference 
between both.

--

-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30	
70565 Stuttgart                            Tel.:   +49 711 5208031
                                            mobile: +49 172 6819937
                                            skype:     detlef.bosau
                                            ICQ:          566129673
detlef.bosau <at> web.de                     http://www.detlef-bosau.de
------------------------------------------------------------------

(Continue reading)

Lachlan Andrew | 5 Feb 03:40 2012
Picon

Re: [Iccrg] Re: Reasons not to deply TCP BIC/Cubic

On 5 February 2012 00:35, Detlef Bosau <detlef.bosau <at> web.de> wrote:
> On 02/04/2012 03:58 AM, Lachlan Andrew wrote:
>>
>> That passage is justifying using window-based rate control.
>
> I just talked to Michael Welzl (bcc:) about this passage some months ago.
> And I think, we shared the view that the remark on Lyapunov functions (I
> cannot even spell this....) are an argument for the stability of the control
> system.

The line "the integral of the packet density around the sender–
receiver–sender loop is a constant" says that the window is constant.

> VJCC is a pure window based control. Only window based. Nothing said about
> rates. And I'm extremely careful to make a clear difference between both.

"packet density" = rate.

Cheers,
Lachlan

--

-- 
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew>
Ph +61 3 9214 4837

Detlef Bosau | 5 Feb 14:33 2012
Picon

Re: [Iccrg] Re: Reasons not to deply TCP BIC/Cubic

On 02/05/2012 03:40 AM, Lachlan Andrew wrote:
>
> The line "the integral of the packet density around the sender–
> receiver–sender loop is a constant" says that the window is constant.
>
Isn't this a rationale for stability here?

>> VJCC is a pure window based control. Only window based. Nothing said about
>> rates. And I'm extremely careful to make a clear difference between both.
> "packet density" = rate.
>

The "packet density" or "rate" does not even appear explicitly in TCP/Reno.

And actually, it does not make sense here. Anaylitcal work, as far as I 
have seen them, assumes continuous functions here where continuous 
functions even do not exist. The whole thing is done with the only 
purpose to apply the apparatus of differential equations on discrete 
processes. This is not impossible per se, however it is a difficult 
task. And I'm not sure, whether we learn that much new by doing so.

> Cheers,
> Lachlan
>

--

-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30	
70565 Stuttgart                            Tel.:   +49 711 5208031
(Continue reading)

Detlef Bosau | 5 Feb 16:15 2012
Picon

Re: [Iccrg] Re: Reasons not to deply TCP BIC/Cubic

On 02/05/2012 03:40 AM, Lachlan Andrew wrote:
>
> The line "the integral of the packet density around the sender–
> receiver–sender loop is a constant" says that the window is constant.
>
Isn't this a rationale for stability here?

>> VJCC is a pure window based control. Only window based. Nothing said about
>> rates. And I'm extremely careful to make a clear difference between both.
> "packet density" = rate.
>

The "packet density" or "rate" does not even appear explicitly in TCP/Reno.

And actually, it does not make sense here. Anaylitcal work, as far as I 
have seen them, assumes continuous functions here where continuous 
functions even do not exist. The whole thing is done with the only 
purpose to apply the apparatus of differential equations on discrete 
processes. This is not impossible per se, however it is a difficult 
task. And I'm not sure, whether we learn that much new by doing so.

> Cheers,
> Lachlan
>

--

-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30	
70565 Stuttgart                            Tel.:   +49 711 5208031
(Continue reading)

Dave Hart | 2 Feb 05:21 2012
Picon

Re: [Iccrg] Re: Reasons not to deply TCP BIC/Cubic

On Wed, Feb 1, 2012 at 21:24, Detlef Bosau <detlef.bosau <at> web.de> wrote:
> The more I think about BIC and CUBIC, the more I ask for the appropriate
> problem for this nice solution.
> I'm not quite sure whether there exists a suitable problem for just more
> aggressive probing.

Hypothetical:  "I am sharing throughput with others via a network I
don't control.  I am greedy and want all the throughput I can get,
fairness and inefficiency be damned."

Perhaps I'm missing something, or less gracious than I should be, but
I've always assumed this is the motivation for Linux using more
aggressive TCP replacements.

Cheers,
Dave Hart

Daniel Havey | 2 Feb 09:04 2012
Picon

Re: [Iccrg] Re: Reasons not to deply TCP BIC/Cubic

Haha ;^)  Just gracious enough.  Let me add, the pig-hearted service provider who silently drops non-TCP packets.
...No offence to pigs or service providers ;^)

Suppose we have three users, they have RTTs of .01, .1, and 1 seconds.  User 1 can compete fairly and get it's
fair share of the bottleneck capacity.  Users 2 and 3 would have more difficulty.  If there is a little packet
loss from a poor connection then the situation is even worse.

Users 2 and especially 3 would have much improved chances of competing for their fair share if they used
Cubic rather than Reno.

I understand that RTT fairness, and lossy connections aren't part of the TCP design and perhaps they
shouldn't be.  However, I think that Cubic is more fair to disadvantaged users.  These users will get closer
to their fair share of the bottleneck capacity with Cubic than with Reno.

...Daniel

> Hypothetical:  "I am sharing throughput with others via
> a network I
> don't control.  I am greedy and want all the throughput
> I can get,
> fairness and inefficiency be damned."
> 
> Perhaps I'm missing something, or less gracious than I
> should be, but
> I've always assumed this is the motivation for Linux using
> more
> aggressive TCP replacements.
> 
> Cheers,
> Dave Hart
(Continue reading)

Detlef Bosau | 2 Feb 13:13 2012
Picon

Re: [Iccrg] Re: Reasons not to deply TCP BIC/Cubic

On 02/02/2012 05:21 AM, Dave Hart wrote:
>
> Perhaps I'm missing something, or less gracious than I should be, but
> I've always assumed this is the motivation for Linux using more
> aggressive TCP replacements.

I'm Linux user myself. And at the moment, I _USE_ Linux. Therefore, I 
was not amused when I detected that Linux uses TCP/BIC by default.

(Sent to the list in order to salvage the reputation of Linux users.)

--

-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30	
70565 Stuttgart                            Tel.:   +49 711 5208031
                                            mobile: +49 172 6819937
                                            skype:     detlef.bosau
                                            ICQ:          566129673
detlef.bosau <at> web.de                     http://www.detlef-bosau.de
------------------------------------------------------------------

Sergey Gorinsky | 2 Feb 15:16 2012

Re: Reasons not to deply TCP BIC/Cubic


  Arguing about which TCP version is better is mostly irrelevant because
there exists no such thing as an ideal TCP. Different applications have
different transport needs, and no single transport protocol can satisfy
all these needs at the same time.

  For me, an eye-opening illustration of this is the following work on
bulk-data transfers where the main metric is message delay (i.e., delivery
time for the entire message, rather than its individual packets or bits):

    S. Gorinsky, E. J. Friedman, S. Henderson, and C. Jechlitschek,
"Efficient Fair Algorithms for Message Communication", Simulation
Modelling Practice and Theory, 17(3), pp. 513-527, March 2009

    
http://fourier.networks.imdea.org/~sergey_gorinsky/pdf/Fair_Efficiency_SMPT
_2008.pdf

This paper presents algorithms allocating the whole bottleneck capacity to
one message at a time and compares them with the instantaneously fair PS
(Processor Sharing). These algorithms reduce average message delay
significantly (e.g., 2-3 times faster delivery on average) and guarantee
that no individual message experiences a larger delay than under PS. This
result could be intuitively understood through the following simple
analogy: if 10 people want to go through a 1-person door, doing so 1
person at a time is more efficient from both collective and individual
perspectives than trying to fairly squeeze all 10 people through the door
at the same time.

  The moral of the study is that short-term fairness should not be treated
(Continue reading)

Barry Constantine | 30 Nov 13:23 2011

Re: Reasons not to deply TCP BIC/Cubic

Hi Saverio,

Does Windows 7 use this TCP implementation as well?

Thank you,
Barry Constantine

-----Original Message-----
From: end2end-interest-bounces <at> postel.org [mailto:end2end-interest-bounces <at> postel.org] On
Behalf Of mascolo <at> poliba.it
Sent: Wednesday, November 30, 2011 6:11 AM
To: end2end-interest <at> postel.org
Subject: [e2e] Reasons not to deply TCP BIC/Cubic

Dear all,

we know that TCP BIC/Cubic is default in Linux and as a consequence  
50% of servers employs TCP BIC/Cubic.

Our measurements say that there could be reasons not to deploy TCP  
BIC/Cubic. These reasons  are in our opinion rooted in its more  
aggressive probing phase. In particular, in common network conditions,  
TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or  
TCP Westwood+; 2. a larger number of retransmission wrt to TCP NewReno  
or TCP Westwood+; 3 larger throughput but same goodput wrt to TCP  
NewReno or Westwood+.

In other terms, it seems that its more aggressive probing increases  
both throughput and retransmissions but leaving unchanged the goodput.  
This is  neutral for the users but negative for the network.
(Continue reading)

Saverio Mascolo | 30 Nov 13:31 2011
Picon

Re: Reasons not to deply TCP BIC/Cubic

i think windows uses tcp compund (that we have not investigated...)


-sm
On Wed, Nov 30, 2011 at 1:23 PM, Barry Constantine <Barry.Constantine <at> jdsu.com> wrote:
Hi Saverio,

Does Windows 7 use this TCP implementation as well?

Thank you,
Barry Constantine

-----Original Message-----
From: end2end-interest-bounces <at> postel.org [mailto:end2end-interest-bounces <at> postel.org] On Behalf Of mascolo <at> poliba.it
Sent: Wednesday, November 30, 2011 6:11 AM
To: end2end-interest <at> postel.org
Subject: [e2e] Reasons not to deply TCP BIC/Cubic

Dear all,

we know that TCP BIC/Cubic is default in Linux and as a consequence
50% of servers employs TCP BIC/Cubic.

Our measurements say that there could be reasons not to deploy TCP
BIC/Cubic. These reasons  are in our opinion rooted in its more
aggressive probing phase. In particular, in common network conditions,
TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or
TCP Westwood+; 2. a larger number of retransmission wrt to TCP NewReno
or TCP Westwood+; 3 larger throughput but same goodput wrt to TCP
NewReno or Westwood+.

In other terms, it seems that its more aggressive probing increases
both throughput and retransmissions but leaving unchanged the goodput.
This is  neutral for the users but negative for the network.

I appreciate your views.

Thanks for the attention and best regards,

Saverio Mascolo

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




--
Prof. Saverio Mascolo
Dipartimento di Elettrotecnica ed Elettronica
Politecnico di Bari
Via Orabona 4, 70125 Bari Italy
Tel. +39 080 5963621
Fax. +39 080 5963410
email:mascolo <at> poliba.it
 
http://c3lab.poliba.it


=================================
 This message may contain confidential and/or legally privileged information.
  If you are not the intended recipient of the message, please destroy it.
 Any unauthorized dissemination, distribution, or copying of the material in
 this message, and any attachments to the message, is strictly forbidden.
Neil Davies | 30 Nov 15:43 2011

Re: Reasons not to deply TCP BIC/Cubic

Saverio

Do you have an idea of the sensitivity of the implementation to burst  
loss? Is this something that you captured/measured? Is this a  
condition that this implementation of TCP exacerbates?

The reason I ask this is that we have experience of measuring large  
scale networks in some detail (down to the contribution to the loss  
and delay at different components in the system) and we are observing  
that there burst loss is occurring - under some circumstances the loss  
can be a complete window size (which then appears to cause the sender  
to wait for a timeout).

I could understand that more aggression would lead to greater RTT (and  
greater RTT leads to longer recover times from certain events) - it is  
filling the critical bottleneck with more packets, hence more delay.

Although TCP BIC/Cubic may appear neutral when measuring throughput -  
is it neutral when that TCP session is being used for other purposes  
other than simple bulk data transfer? (e.g. a block transfer of video  
content)

Cheers

Neil
On 30 Nov 2011, at 11:10, mascolo <at> poliba.it wrote:

> Dear all,
>
> we know that TCP BIC/Cubic is default in Linux and as a consequence  
> 50% of servers employs TCP BIC/Cubic.
>
> Our measurements say that there could be reasons not to deploy TCP  
> BIC/Cubic. These reasons  are in our opinion rooted in its more  
> aggressive probing phase. In particular, in common network  
> conditions, TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to  
> TCP NewReno or TCP Westwood+; 2. a larger number of retransmission  
> wrt to TCP NewReno or TCP Westwood+; 3 larger throughput but same  
> goodput wrt to TCP NewReno or Westwood+.
>
> In other terms, it seems that its more aggressive probing increases  
> both throughput and retransmissions but leaving unchanged the  
> goodput. This is  neutral for the users but negative for the network.
>
> I appreciate your views.
>
> Thanks for the attention and best regards,
>
> Saverio Mascolo
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>


Gmane