Subject: [Iccrg] FW: New Version Notification for draft-irtf-iccrg-cc-rfcs-05
From: [email-masked] (Eddy, Wesley M. (GRC-RCN0)[VZ])
Date: Tue Jul 15 08:04:06 2008

Michael and I posted an editorial update to the congestion control
RFCs overview based on an IRSG review by Stephen Farrell.  I've
attached the rfcdiff output.

>-----Original Message-----
>From: IETF I-D Submission Tool [mailto:[email-masked]] 
>Sent: Monday, July 14, 2008 3:14 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: New Version Notification for draft-irtf-iccrg-cc-rfcs-05 
>
>
>A new version of I-D, draft-irtf-iccrg-cc-rfcs-05.txt has been 
>successfuly submitted by Wesley Eddy and posted to the IETF repository.
>
>Filename:	 draft-irtf-iccrg-cc-rfcs
>Revision:	 05
>Title:		 Congestion Control in the RFC Series
>Creation_date:	 2008-07-14
>WG ID:		 Independent Submission
>Number_of_pages: 36
>
>Abstract:
>This document is an informational snapshot produced by the IRTF's
>Internet Congestion Control Research Group (ICCRG).  It provides a
>survey of congestion control topics described by documents in the RFC
>series.  This does not modify or update the specifications or status
>fo the RFC documents that are discussed.  It may be used as a
>reference or starting point for the future work of the research
>group, especially in noting gaps or open issues in the current IETF
>standards.
>                                                               
>                   
>
>
>The IETF Secretariat.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080714/2026fe15/rfcdiff-0001.htm
>From [email-masked]  Mon Jul 28 09:49:21 2008
From: [email-masked] (Eddy, Wesley M. (GRC-RCN0)[VZ])
Date: Mon Jul 28 09:25:24 2008
Subject: [Iccrg] TANA BoF
Message-ID: <[email-masked]>

There is a BoF session at the IETF meeting this week that I think some of the ICCRG will be interested in:
 
http://www.ietf.org/proceedings/08jul/agenda/tana.txt
 
And the problem statement draft is here:
 
http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statement-01.txt
 
Specifically, one of the work items proposed is:
(1) A congestion control algorithm for less-than-best-effort
"background" transmissions, i.e., an algorithm that attempts
to scavenge otherwise idle bandwidth for its transmissions in
a way that minimizes interference with regular best-effort
traffic. Among the desired features of such an algorithm are
the ability to maintain short standing queues, the capability
to quickly yield to regular best-effort traffic that uses
standard congestion control, the ability to utilize explicit
congestion notification (ECN), active queue management (AQM),
and/or end-to-end differentiated services (DiffServ) where
available, as well as effective operation in today's typical
situations where some or all of these mechanisms are not
available. In addition to specifying a congestion control
algorithm, the work may also include specifications of how such an
algorithm is to be used in specific UDP-based protocols.
(Application of the algorithm to other transport protocols is
expected to occur in the working groups that maintain those
protocols.)
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080728/f2427f2d/attachment.html
>From [email-masked]  Mon Jul 28 10:04:54 2008
From: [email-masked] (Eddy, Wesley M. (GRC-RCN0)[VZ])
Date: Mon Jul 28 09:41:12 2008
Subject: [Iccrg] TANA comments
Message-ID: <[email-masked]>

The TANA BoF hasn't happened yet, and I'll be on a plane when it does, but I've looked at the problem statement and have a few short comments:
 
(1) I have no idea what an "advanced networking application" is.  I suggest actually defining this or finding a more precise term.  I assume you don't mean advanced in terms of age :).
 
(2) On "multiple connections" between 2 peers, this only has meaning when talking about TCP applications, with UDP it doesn't matter how many port pairs you use, the sending behavior can be the same.  The only difference is that with multiple UDP sockets you have multiple socket buffers to fill and the kernel may drain them in some different pattern than if you wrote all the packets to the same UDP socket.
 
(3) There is ambiguity about what transport services the targetted applications need; if it's datagram or reliable bitstream, either, both, etc.  It may not actually matter, but it might be useful to know in determining what work is actually needed here.
 
(4) The problem statement mentions that there is already a fielded solution.  Is the purpose of this activity to write up that solution, or to work on creating solutions?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080728/048bda02/attachment.html

From: [email-masked] (Saverio Mascolo)
Date: Thu Jul 10 10:12:00 2008
Subject: [Iccrg] Best congestion avoidance algorithm
Message-ID: <000801c8e270$08efd8d0$723bccc1@HPSM>

On Wed, Jul 9, 2008 at 9:41 PM, Lachlan Andrew <[email-masked]> wrote:

  Greetings Adam,

  2008/7/9 adam maxiaodong <[email-masked]>:

  >
  > But why fairness and friendliness are equally important?
  >
  > I though all those congestion algorithms are already intra-protocol fair
  > (otherwise, it will be a design flaw and won't get implemented)

  Even Reno isn't intra-protocol fair (unless RTTs are equal).
  Algorithms get implemented in Linux because someone takes the effort
  to implement them, not because they have been shown to be good.

  Lars is absolutely right that assessing based only on throughput is
  missing the point of congestion control.

what about measuring queuing delays? it would be another important metric!

best
saverio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080710/62f5d562/attachment.html
>From [email-masked]  Thu Jul 10 17:28:26 2008
From: [email-masked] (Lachlan Andrew)
Date: Thu Jul 10 17:06:48 2008
Subject: [Iccrg] Best congestion avoidance algorithm
In-Reply-To: <000801c8e270$08efd8d0$723bccc1@HPSM>
References: <000801c8e270$08efd8d0$723bccc1@HPSM>
Message-ID: <[email-masked]>

2008/7/10 Saverio Mascolo <[email-masked]>:
>
> what about measuring queuing delays? it would be another important metric!

It certainly is.  I believe it is in RFC 5166, which Lars had pointed to.

Cheers,
Lachlan

-- 
Lachlan Andrew Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603
http://netlab.caltech.edu/lachlan

From: [email-masked] (adam maxiaodong)
Date: Wed Jul  9 17:55:03 2008
Subject: [Iccrg] Best congestion avoidance algorithm
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Thanks for the pointer.

But why fairness and friendliness are equally important?

I though all those congestion algorithms are already intra-protocol fair
(otherwise, it will be a design flaw and won't get implemented)

As to inter-protocol friendliness, looks to me, every TCP congestion
controls are already friendly enough comparing with UDP.
-Adam
On Tue, Jul 8, 2008 at 11:40 PM, Lars Eggert <[email-masked]> wrote:

> Hi,
>
> On 2008-7-8, at 20:26, ext adam maxiaodong wrote:
>
>> In my test, vegas doesn't perform better than others, but I guess vegas
>> will
>> perform better when network path has long queuing.  hope this help!
>>
>
> if you haven't done so, I highly recommend Alejandro and you take a look at
> RFC 5166 ("Metrics for the Evaluation of Congestion Control Mechanisms").
>
> Throughput is one important metric to look at (Section 2.1.1), but there
> are many others that are equally important. Picking a congestion control
> algorithm only on the basis of achievable throughput is missing the bigger
> issues, such as fairness.
>
> Lars
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080709/2ab2e54f/attachment.html
>From [email-masked]  Wed Jul  9 20:41:14 2008
From: [email-masked] (Lachlan Andrew)
Date: Wed Jul  9 20:19:41 2008
Subject: [Iccrg] Best congestion avoidance algorithm
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Greetings Adam,

2008/7/9 adam maxiaodong <[email-masked]>:
>
> But why fairness and friendliness are equally important?
>
> I though all those congestion algorithms are already intra-protocol fair
> (otherwise, it will be a design flaw and won't get implemented)

Even Reno isn't intra-protocol fair (unless RTTs are equal).
Algorithms get implemented in Linux because someone takes the effort
to implement them, not because they have been shown to be good.

Lars is absolutely right that assessing based only on throughput is
missing the point of congestion control.

Cheers,
Lachlan

-- 
Lachlan Andrew Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603
http://netlab.caltech.edu/lachlan

From: [email-masked] (adam maxiaodong)
Date: Tue Jul  8 18:04:48 2008
Subject: [Iccrg] Best congestion avoidance algorithm
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi, Alejandro,

I have some lab test result for your reference.

Test topology:

vista                    linux 2.6.15 (tc)                   Linux 2.6.24
(reno, bic, vegas ....)
Client ---------------- WAN emulator ----------------------- Server

Server acts as sender, transfer a 2MB file.

(1) Simulate wireless connection
tc qdisc add dev eth0 root handle 1: netem limit 50000 delay 200ms 50ms drop
3 50% duplicate 0 corrupt 1 recorder 5 25 gap 1
tc qdisc add dev eth1 root handle 1: netem limit 50000 delay 200ms 50ms drop
3 50% duplicate 0 corrupt 1 recorder 5 25 gap 1
TCP Stack        Rate(KBps)
bic                    25.7
cubic                36.8
highspeed         28.4
htcp                  26.8
hybla                24.7
lp                     22.1
scalable            28.6
vegas               16.2
veno                 26.8
westwood         25.7
illinois              32.5
yeah                33.6
reno                 16.1

(2) Simulate US-ASIA
tc qdisc add dev eth0 root handle 1: netem limit 50000 delay 175ms 50ms drop
2 duplicate 0  gap 0
tc qdisc add dev eth0 root handle 1: netem limit 50000 delay 175ms 50ms drop
2 duplicate 0  gap 0
TCP Stack        Rate(KBps)
bic                   19.8
cubic                28.7
highspeed         19.1
htcp                  23.7
hybla                19.7
lp                     16.2
scalable            26.9
vegas               15.5
veno                 22.8
westwood         27.2
illinois              25.1
yeah                21.1
reno                16.4

(3) Simulate US-US
tc qdisc add dev eth0 root handle 1: netem limit 50000 delay 30ms 5ms drop
0.1 duplicate 0  gap 0
tc qdisc add dev eth0 root handle 1: netem limit 50000 delay 30ms 5ms drop
0.1 duplicate 0  gap 0
TCP Stack        Rate(KBps)
bic                   310
cubic               402
highspeed        308
htcp                 254
hybla               303
lp                    263
scalable           325
vegas               195
veno                 292
westwood         298
illinois              326
yeah                332
reno                 272

In my test, vegas doesn't perform better than others, but I guess vegas will
perform better when network path has long queuing.  hope this help!

-Adam

On Tue, Jul 8, 2008 at 6:57 AM, Alejandro Cabrera Obed <[email-masked]>
wrote:

> Dear all, I have a network scenario with several Windows XP and Linux
> Debian Etch boxes acting as servers and clients, using typical TCP
> traffic like FTP, HTTP, SSH -among others-.
>
> Our boxes mainly have TCP Reno as the TCP congestion avoidance
> algorithm. But we see that TCP Vegas has a better response to
> congestion because it uses round-trip time measure to control the
> transfer rate, opposite to Reno that uses packet loss. And we see
> there are other congestion avoidance algorithm like New Reno, Bic,
> Cubic, etc.
>
> So, what is the best congestion avoidance algorithm nowadays taking
> into account the response time to congestion situations ??? What do
> you recommend to me ???
>
> Special thanks
>
>
> --
> Alejandro Cabrera Obed
> [email-masked]
> www.alejandrocabrera.com.ar
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080708/444cf503/attachment.html
>From [email-masked]  Wed Jul  9 07:40:53 2008
From: [email-masked] (Lars Eggert)
Date: Wed Jul  9 07:20:01 2008
Subject: [Iccrg] Best congestion avoidance algorithm
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi,

On 2008-7-8, at 20:26, ext adam maxiaodong wrote:
> In my test, vegas doesn't perform better than others, but I guess  
> vegas will
> perform better when network path has long queuing.  hope this help!

if you haven't done so, I highly recommend Alejandro and you take a  
look at RFC 5166 ("Metrics for the Evaluation of Congestion Control  
Mechanisms").

Throughput is one important metric to look at (Section 2.1.1), but  
there are many others that are equally important. Picking a congestion  
control algorithm only on the basis of achievable throughput is  
missing the bigger issues, such as fairness.

Lars

From: [email-masked] (Alejandro Cabrera Obed)
Date: Tue Jul  8 14:36:16 2008
Subject: [Iccrg] Best congestion avoidance algorithm
Message-ID: <[email-masked]>

Dear all, I have a network scenario with several Windows XP and Linux
Debian Etch boxes acting as servers and clients, using typical TCP
traffic like FTP, HTTP, SSH -among others-.

Our boxes mainly have TCP Reno as the TCP congestion avoidance
algorithm. But we see that TCP Vegas has a better response to
congestion because it uses round-trip time measure to control the
transfer rate, opposite to Reno that uses packet loss. And we see
there are other congestion avoidance algorithm like New Reno, Bic,
Cubic, etc.

So, what is the best congestion avoidance algorithm nowadays taking
into account the response time to congestion situations ??? What do
you recommend to me ???

Special thanks

-- 
Alejandro Cabrera Obed
[email-masked]
www.alejandrocabrera.com.ar

From: [email-masked] (Lars Eggert)
Date: Tue Jul  8 09:24:32 2008
Subject: [Iccrg] Re: [AVT] Off-Topic: TCP congestion control: Reno vs. Vegas
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

AVT is not the correct list for this topic. I suggest the ICCRG list  
(CC'ed.)

Lars

On 2008-7-7, at 18:30, ext Alejandro Cabrera Obed wrote:

> Dear all,  I'm involved in some congestion control tests using Linux
> boxes which use TCP Reno as the default TCP congestion control.
>
> I read that TCP Vegas is better than Reno because it measures the
> round-trip delay from all the transmitted packets and after that, in
> case of congestion, the data rate decreases faster than measuring the
> packet loss.
>
> What TCP stack do you recommend to avoid congestion control in
> "best-effort" scenarios for TCP traffic ???
>
> Special thanks.
>
>
> -- 
> Alejandro Cabrera Obed
> [email-masked]
> www.alejandrocabrera.com.ar
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt