Subject: [Iccrg] Faresin maÅ¡ine - 3 u 1
From: [email-masked] (Tehnoservis Group)
Date: Fri Jan 20 10:00:18 2012

An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20120120/78f601e6/attachment.html
>From [email-masked]  Fri Jan 20 17:26:45 2012
From: [email-masked] (Tehnoservis Group)
Date: Fri Jan 20 17:23:36 2012
Subject: [Iccrg] Please confirm your unsubscription
Message-ID: <[email-masked]>

Dear ,
 
Please click on the link below to confirm your unsubscription from the folowing mailing list:
- Vilju?kari
 
http://www.mailing-sistem.com/marketing-mail/unsubscribe/?id=19531&active_key=AIrcAfs0DbtDXCy7mGvz
>From [email-masked]  Tue Jan 31 16:22:34 2012
From: [email-masked] (Mirja Kuehlewind)
Date: Tue Jan 31 16:17:00 2012
Subject: [Iccrg] Re: [e2e] Reasons not to deply TCP BIC/Cubic
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

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, [email-masked] 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.
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja K?hlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

From: [email-masked] (Michael Welzl)
Date: Wed Jan 18 11:50:12 2012
Subject: [Iccrg] Paris meeting
Message-ID: <[email-masked]>

Hi all!

After a (too, sorry!) long time without meetings, ICCRG will meet at the 
upcoming Paris IETF. Please send any presentation requests (title, 
estimated time, your name) to Murari and me - thanks!

I hope to see many of you ICCRG'ers at this meeting,
Michael

From: [email-masked] (Eggert, Lars)
Date: Wed Jan  4 11:24:03 2012
Subject: [Iccrg] how fast do modern high-speed TCPs go?
Message-ID: <[email-masked]>

Hi,

pretty basic question: how fast do modern high-speed TCPs go over WAN paths? 

More specifically, can they fill a multi-Gbps or even tens-of-Gbps paths? Under what path conditions (reserved capacity?), using what hardware? Can they still be called fair to regular TCP in case the path has cross or other traffic?

Does anyone have a quick pointer to some recent papers?

Thanks,
Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4361 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20120104/3d1a2a42/smime.bin
>From [email-masked]  Wed Jan  4 17:49:43 2012
From: [email-masked] (Murari Sridharan)
Date: Wed Jan  4 17:47:21 2012
Subject: [Iccrg] RE: how fast do modern high-speed TCPs go?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Very few E2E 10G WAN paths although thats changing, the core mostly is already 10G. I'd say most of the high speed versions can easily fill multi-gpbs on WAN. Anything past 10G i have only played with on LAN using Infiniband NICs. 

The latest comprehensive fairness report came out of NIST a couple of years back. 
http://www.nist.gov/itl/antd/Congestion_Control_Study.cfm
http://www.nist.gov/itl/sed/gsg/jjfmills101410.cfm

Thanks

________________________________________
From: [email-masked] [[email-masked]] on behalf of Eggert, Lars [[email-masked]]
Sent: Wednesday, January 04, 2012 3:25 AM
To: [email-masked]
Subject: [Iccrg] how fast do modern high-speed TCPs go?

Hi,

pretty basic question: how fast do modern high-speed TCPs go over WAN paths?

More specifically, can they fill a multi-Gbps or even tens-of-Gbps paths? Under what path conditions (reserved capacity?), using what hardware? Can they still be called fair to regular TCP in case the path has cross or other traffic?

Does anyone have a quick pointer to some recent papers?

Thanks,
Lars